Commercial application security: 6 facts you didn’t know

Our Open Source Security and Risk Assessment report analyzed 1,000 audits. Here are my top 6 takeaways on open source in commercial application security.

Many people know Black Duck from our security and software license compliance business. However, we also have a very strong On-Demand business. Our On-Demand business performs one-time audits of software, typically as part of due diligence in an M&A transaction. In these engagements, the entities acquiring a software company will “Black Duck” the codebase of the target company to confirm that the code is not hampered by restrictive licenses or unacceptable security risk.

In 2016, we audited over 1,000 codebases, and anonymized and analyzed the results in this year’s Open Source Software Risk Assessment report. I wanted to share the top 6 takeaways from a security standpoint on open source management in commercial applications: 

1. (Virtually) Everyone is using open source

Over 96% of the commercial applications we audited included one or more open source components. It’s easy to understand why; open source provides critical functionality while decreasing development costs and accelerating time to market. Eliminating open source would require organizations to rebuild that functionality, almost certainly introducing delays without any assurances that performance and security benefits would accrue.

Black Duck On-Demand audits found open source components in 96% of applications scanned

Open source was used in every industry vertical we reviewed last year. Healthcare and Life Sciences led the way (46% open source, on average). Even those industries where you would expect a heavy reliance on custom code included a lot of open source. Enterprise software – where you are purchasing proprietary features – was comprised of 37% open source. Even aerospace and aviation have adopted open source, where it comprised 23% of the average code base. 

2. Commercial applications contain more open source than you (and the code owners) think

Last year we found that the owners of the codebases we reviewed had awareness of less than half of the open source they used (45%). We found that to be true again in our 2016 audits. In fact, the number of open source components in the average application grew to 147.

Let’s look at that again. On average, the application development teams believed they were using 60 – 70 discrete open source components, when they were actually using 147. This demonstrates well the problem with relying on the development team’s collective memory when compiling a list of open source. It also helps make explain our next finding…

3. Security issues are prevalent (and avoidable)

If you don’t know what you’re using, you can’t be aware of risks to those components. In 2016, we found fully 2/3 of the codebases we audited included vulnerabilities in open source components— 27 individual vulnerabilities on average!

Some of these were not so bad, and some were really bad — almost 300 vulnerabilities in Linux Kernel v.2.6.27.7 (released in 2008). However, all are avoidable simply through open source management by accurately tracking what is being used and watching for public disclosures of new vulnerabilities. Admittedly, this is difficult to do manually for a single application when you consider the number of components and the number of vulnerabilities (we tracked over 3,600 in 2016) — much less for dozens, hundreds, or thousands of individual applications.

4. We still aren’t past Heartbleed

We recently passed the 3-year anniversary of the Heartbleed disclosure, but we still are seeing applications vulnerable to, arguably, the most well publicized vulnerability of all time. We are seeing improvements, however. Last year we found Heartbleed in over 10% of the codebases we tested. This year it was under 2%, but we see other vulnerabilities that persist over long periods of time. 7% of the codebases we audited included either Heartbleed (2014), Poodle (2014), Freak (2015), or Drown (2016).

For the record, while Heartbleed is well known, it is far from being the only vulnerability in OpenSSL. Overall, 89 additional vulnerabilities have been disclosed in OpenSSL since Heartbleed.

5. Heartbleed is younger than the average vulnerability

When something is as well publicized as Heartbleed, we expect people to react. Lesser known vulnerabilities are also likely to be missed. In 2016, the average vulnerability we found had been publicly disclosed in the National Vulnerability Database (NVD) over 1,500 days prior to our audit of the codebase. That’s right — over four years.

This tells us that organizations are not checking open source for disclosed vulnerabilities prior to including it in their software, and that they are also not checking for new vulnerabilities in the components they use (even those they are aware they use).

6. Open source is NOT the problem

Let’s be clear – open source is not the problem, nor is it any less (or more) secure than commercial code. It’s software, and therefore will have vulnerabilities. In fact, in 2015 NVD reported more vulnerabilities in commercial software than in open source. That’s pretty impressive when you consider that open source is available to everyone, while commercial code vulnerabilities are primarily discovered through black box testing.

There are plenty more interesting facts in the report. Download a copy and let us know what you think.

P.S. I presented a webinar today on open source security in commercial applications and the analysis we performed. Here’s the recording: Audits of 1000 Apps: The Good, the Bad and the Ugly of Open Source Use.