Patrick Carey, Director of Product Marketing, Black Duck Software, discusses what software testers need to know about open source vulnerabilities in application software. 

Building reliable and secure software

In a world that runs on software, we face a big problem: the difficulty of ensuring that the software we build, use, and sell is reliable and secure. This is true of purchased software, custom-developed proprietary software, and software delivered as a service. It is also true of open source, which now often comprises the bulk of the average proprietary application’s code. In fact, Forrester recently reported that most developers use open source components as their foundation for coding, creating applications using only 10% to 20% new code. “Unfortunately, many of these open source components come with liabilities in their license agreements, and one out of every 16 open source download requests is for a component with a known vulnerability,” Forrester also notes in the same report (The Forrester Wave™: Software Composition Analysis, Q1 2017).

The security aspects of open source

While the benefits of faster time to market, lower development costs and access to a global community of developers are clear, the security aspects of open source use are often overlooked. The assumption is that, since many smart people around the world have reviewed the code, it is probably secure – an assumption known as the “many eyeballs” theory. The reality is that over 3,000 open source vulnerabilities are disclosed each year.

Hackers take the easiest path when determining exploits and choose applications that offer the best attack surface opportunities. Those opportunities are generally created by unpatched or outdated software. For example, Heartbleed, a dangerous security flaw, critically exposes OpenSSL, an open source project used in hundreds of thousands applications that need to secure communications over computer networks against eavesdropping. Yet over half of all OpenSSL versions that Cisco Security Research examined in its 2015 security report were still vulnerable to Heartbleed, more than two years after the Heartbleed vulnerability was first disclosed and a patched version issued.

This more illustrates the difficulty organizations have in inventorying and managing open source components rather than a lack of security diligence. It is nearly impossible for any organization to manually identify applications that use vulnerable open source components. Black Duck On-Demand audits of customer codebases consistently show that most organizations are using twice as much open source as they are able to track manually.

A look into software composition analysis

The problem is clear – but what’s the answer? As with most things security, the answer is not a simple one. Many organizations look to either Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), for application security testing. However most SAST and DAST tools are relatively ineffective at spotting and resolving open source vulnerabilities, the reason why a growing number of application security vendors are including some form of Software Composition Analysis (SCA) in their offerings.

SCA identifies open source and third-party components in use in an application and their known security vulnerabilities. According to the latest Gartner Magic Quadrant for Application Security Testing, SCA is becoming a critical feature of application security testing solutions. By 2019, Gartner notes in the same report, 80% of application security testing vendors will include some form of software composition analysis in their offerings.

What should you look for in an SCA tool, either standalone or as part of an overall application security testing solution?

• Deep information. Most SCA solutions will use the U.S. government vulnerability disclosure database, the National Vulnerability Database (NVD – https://nvd.nist.gov/), as their primary source. However, relying on the NVD as the sole source opens an organization to the risk of vulnerabilities that have not yet been vetted by the NVD. An effective SCA tool should gather vulnerability data from multiple sources and mark which ones have been validated. The best SCA vendors will add more information than the NVD provides and even give guidance on remediation.
• Reduced license risk exposure. While ensuring security is arguably the most important aspect of managing open source, another important piece of the puzzle is license compliance; adherence to the terms and conditions governing the open source component’s use and distribution. Organizations that publicly redistribute open source software outside the terms of its license are at risk for litigation, possibly even compromise of intellectual property. The best SCA tools give deep insight into open source licenses, helping companies reduce potentially significant risks hidden in open source license agreements. SCA can also be used to block the use of components with licenses your company has deemed too risky to use.
• Seamless integration into the SDLC. The best SCA tools will integrate seamlessly into the SDLC, and work with code repositories or integrated development environments (IDEs) to warn of a vulnerable or risky component. SCA can also automate review workflows with the proper approver(s) to minimize delays.

An effective approach to addressing application security needs to include a full complement of tools, by examining the source code for vulnerabilities (SAST); by examining the compiled application (DAST), and through the use of software composition analysis (SCA) to look for open source hidden vulnerabilities throughout the SDLC.

Edited for web by Jordan Platt.