According to SAP research, over 80% of security attacks target software applications.

To combat that risk, organisations can employ a variety of methods to detect and mitigate vulnerabilities that may be in their code – classically, static code analysis (SAST) at the early stages of the software development lifecycle backed by dynamic application security testing (DAST) can be used to detect security vulnerabilities in an application’s running state.

Yet, neither static or dynamic testing effectively address identifying security vulnerabilities in a major element of modern software: open source code.

With pressure to deliver on time and within budget, development teams are increasingly turning to open source libraries, frameworks and code snippets to supplement their proprietary code. In fact, open source frequently comprises 30-50% of the code in any given enterprise application.

Do you really know what’s in your code?

Open source may enter a codebase when a developer grabs a pre-built component from the internet, perhaps from Github or a similar website. But open source can also get into applications in a number of ways besides developer downloads – including from commercial apps, third-party libraries, and outsourced development.

Commercial components typically include open source that may not be disclosed in documentation. Outsourced development teams are highly motivated to use open source for lowering development costs and speeding time-to-market.

>See also: How open source technologies are transforming the BBC

Black Duck On-Demand’s auditing of 200 commercial applications over the 6 months from October 2015 through March 2016 revealed that most organisations have a lot more open source code in their applications than they know about – double the amount, on average.

Those companies who provided a list of the open source components they expected to be in their applications were typically only aware of 45% of the actual components used. In other words, while they believed they were using an average of 60-70 open source components, they were actually using over 140 components on average. And of those applications reviewed:

• Over 67% contained open source vulnerabilities, with an average of 22.5 per application.
• 40% of those vulnerabilities were rated as “severe” by NIST.
• 10% of the applications reviewed still contained the OpenSSL “Heartbleed” vulnerability reported in 2014.
• The average vulnerability found was over 5 years’ old.

As the Black Duck State of Open Source Security study revealed, while the world is increasingly turning to open source, most companies remain ill-informed about the amount of open source they are actually using and have no insight into the vulnerabilities that may be included in that open source.

Since 2014, the NVD has reported more than 6,000 new open source vulnerabilities.

Creating a comprehensive application security strategy

Obviously, organisations need to treat open source software security management as part of a complete application security program.

In general, most application security testing solutions such as static code analysis and dynamic application security testing are best suited for analysis of the custom code written by the development team and often miss the vulnerabilities that enter the code via open source.

>See also: Rise of the collaborative open bank

To address this gap, development teams need to augment their traditional AppSec approaches with an open source security management solution, one of the reasons why earlier this year both HP Enterprise and IBM extended their security solutions to include open source scanning alongside their application security testing toolset.

A comprehensive open source security management solution should include:

• The ability to select and approve new open source as it enters a code stream.
• Inventorying and tracking the use of open source software within the code base.
• Monitoring for known open source vulnerabilities (like Heartbleed, ShellShock, etc.) associated with open source software.
• Tracking of vulnerability remediation efforts.
• Assessment of intellectual property (IP) risks that can arise with the use of open source.
• Audit of open source license compliance policies.

Security is arguably the most important aspect of open source usage in the enterprise. But other important aspects of open source use are worthy of attention, such as license terms and conditions governing its use and distribution.

Organisations that publicly redistribute open source software outside the terms of its license are at risk of litigation, compromise of intellectual property, and potential delays due to remediation of open source use issues.

The points noted in the last two bullets above are of serious importance to many businesses, especially those involved in or contemplating a merger or acquisition. During an M&A acquirers want to identify problematic open source in the targets’ code before the transaction terms and integration timelines are set.

Savvy acquirers perform open source code audits whenever software assets are a significant part of the deal valuation. Weak open source management practices indicate a higher likelihood of issues in the code, both security and license compliance issues.

>See also: Why open source can save companies from drowning in the data lake

Traditional approaches to applications security, involving only static and dynamic testing, can leave huge yet often unrecognised vulnerabilities.

Limiting AppSec to SAST and DAST can mean that up to 50% or more of the code actually in an application may not be known.

Open source security management completes the picture, providing identification and inventorying of open source software, mapping components to known vulnerabilities, and streamlining and securing development activities.

Incorporating open source security management with SAST and DAST can ensure a comprehensive and in-depth assessment of security across the entire application.
Sourced by Mike Pittenger, vice president of security strategy, Black Duck Software