By Tunde Ogunkoya, Consulting Partner, Africa, at DeltaGRiC Consulting (Pty) ltd.

Tunde will be hosting the session Open Source; Pathway to Being or Not Being the VulN Victim at (ISC)² SecureJohannesburg 2017 on 5th October, 2017.

The use of Open Source Software (OSS) has come a long way from when developers and organisations tried to avoid it. Today Open Source has become a go-to saving grace within most DevOps teams under pressure to roll out new functionality and features ahead of competition. Unfortunately, levels of vulnerability have grown with the trend as DevOps remain largely unaware of the risks or rely on inadequate testing regimes.  

Legacy Applications written in languages such as Fortran or Cobol are being phased out for more modern languages such as java, python, ruby Go and R, that are used in OSS and cater to mobile devices , IoT, and web applications.  Further, we are finding that many OSS projects are a derivative of one another. For instance, you will find the derivative use of card.io in Uber, PayPal or South Africa’s rave local application – Snapscan. We hardly write code anymore; we live in an era where we simply borrow or re-use code.

This has created a huge dependence on Open Source and the benefits it allows from a flexibility, affordability and exposure to a huge, innovative community point of view. GitHub, for example, houses about 80% of all open source codes today making it is easy for developers to share their work with others around the globe as they work to complete tasks on time and on budget. Unfortunately, a large percentage of developers lack the knowledge and instincts to ensure security in their portfolio of work. The community not only shares the benefits, but also the inherited security vulnerabilities as open source components are copied from one application to another. I should note that many apps, like card.io, are closely monitored for security but there are thousands of other unique and innovative projects and implementations being developed, shared and re-used every day.  Often projects are an amalgamation of various open source components, which call on various other open source components, in some cases to the fourth or fifth degree.

It’s a scenario that offers insight into increasing concerns over software vulnerability, with growing incidents of cyber-attacks happening at the application layer. It has become quite easy for a modern application solving a critical business challenge in an organisation to have vulnerable open source components in it, embedding backdoors into connected systems .

Whilst some DevOps teams have incorporated security testing into their SDLC process, these tend to be limited in scope, inclined towards looking for bugs that allow for SQL injection, XXS or Buffer Overflow in the source code (using SAST tools); and misconfigurations or authentication issues in their finished applications (using DAST tools).  More often than not, the security testing methodology omits many of the open source security vulnerabilities which are on the rise (Y2016 saw about 4000 new Vulns).

SAST and DAST tools often use certain rule-based detection parameters, which are not good enough. For the 74,000 vulnerabilities discovered between 2004 and 2015, only 13 were discovered by SAST and DAST tools, according to Black Duck’s Application Security Report . To develop higher maturity in a DevSecOps programmme, it is imperative to include a more thorough methodology by inserting “Application Composition Analysis” in the SDLC. This assures that the entire Bill of Material of the application is visible at source, binary or manifest level so that all open source components can be seen, controlled and continuously monitored by their unique versions; and replaced when there is an announced vulnerability. This compensates for any security skills gap among the developers, drastically reduces the attack surface of an application, and allows for continued reliance on the benefits of turning to Open Source Software.

“Application Composition Analysis” or Software Composition Analysis as referred to by Forrester, also ensures visibility of licenses and your legal obligations aligned to how you distribute your final application.

There is no denying that Open Source Software is the future of DevOps. Given this, one cannot over emphasise the need to incorporate a holistic, 360-degree security testing approach such as is delivered through Application or Software Composition Analysis to ensure more secure and stable applications— and organisations.