Information on open source vulnerabilities is as distributed as the community

Nothing gets the AppSec / InfoSec community abuzz quite like a good old 0-day vulnerability.

I mean, what’s not to love here? These vulnerabilities involve the thrill of adversaries knowing something we don’t, giving them a path to sail through our defenses to break into that sweet data inside. They are the James Bond of the security space — suave, sexy, and deadly.

However, once we get past the veneer of the 0-day mystique, we are quickly reminded that the far bigger threat to our software comes more from the known vulnerabilities that are floating around in public available for all to see and exploit.

Known security vulnerabilities: hidden in plain sight

While there are always going to be those exploits kicking around in the darker corners of the hackerverse and require an effective threat intelligence solution, the vast majority of vulnerabilities for both commercial and open source products end up on security advisories like the National Vulnerability Database (NVD), the popular U.S. government-backed database that analyzes reported software vulnerabilities (CVE’s).

For years now, we have been seeing a moderate yet steady climb in the number of software vulnerabilities (CVEs) being reported. However, the count for 2017 more than doubled the previous year’s number, spiking from 6,447 to 14,714 CVEs in the books. Hardly a fluke - 2018 recorded 16,555 vulnerabilities.

I have theorized on why we are seeing more of these vulnerabilities coming to light, due in part to bug bounties and corporate sponsorship for research into open source security efforts. Frankly, more money being thrown at the problem is helping to play a positive role in making software safer, but it only tells a part of the story.

Where do software security vulnerabilities go once they are discovered?

While the NVD is generally considered to be the authoritative listing for vulnerabilities and is where many security folk and developers go to search for known vulnerabilities, their details, and their fixes. Not all, but most known vulnerabilities can be found there, and that’s the good news.

The bad news is that the information pertaining to these vulnerabilities is spread out across multiple sources, making the job of keeping track of them considerably more difficult.

Not every vulnerability makes its way directly to the NVD through the standard CVE route. Vulnerabilities reach the CVE, another U.S.-government-backed organization run by the non-profit MITRE Corporation, through reports from security researchers, project maintainers, or companies in the case of commercial software.

When a vulnerability is discovered by a researcher, the common practice is to notify the vendor or project maintainer and then reach out to the CVE to reserve an identification number. Information about what has been found to be vulnerable and how to exploit it is withheld during a grace period, (typically 60-90 days) which is meant to allow the product/project’s team time to develop a fix for the vulnerability. 

Vulnerabilities reported for commercial products like Microsoft’s Windows, Apple’s MacOS and iOS, Cisco products, etc follow the more traditional course of being uncovered by their in-house security team or brought to their attention by a bug bounty hunter. Then there is an update, often delivered with a regularly scheduled update (looking at you Patch Tuesday.) Vulnerabilities discovered in open source components are a different animal.

The wild west of open source security vulnerabilities

At its core, the difference between open source software and commercial software is the kind of license that it’s rocking. However, when it comes to security issues, you need to turn over more rocks in order to stay on top of open source vulnerabilities, as this space is still very much a Wild West.

By now we’re all familiar with Eric S. Raymond’s 1999 essay, The Cathedral and the Bazaar, where he talks about the distributed nature of open source. Truth is that while resources like the above mentioned NVD do a pretty good job of compiling many of the open source vulnerabilities, it is far from complete and comprehensive because of how the community works, eschewing a centralized approach.

For starters, a sizable number of the open source vulnerabilities that we see out there are actually being posted and discussed on a wide range of different security advisories and issue trackers. This means that even for relatively popular projects, these red flags may fly beneath the radar.

From our experience, you need to be looking where the developers who are working on the projects and using the components are. Issue trackers like Apache’s Jira can be invaluable given their large share of the market as it were. Pivotal security is also a good source for a range of product-specific security advisories. Zooming out a bit, Bugzilla should be at the top of everyone’s list, as well as the Linux security advisory.

We should note though that it can sometimes take weeks or more for a vulnerability which has been reported on a project’s issue tracker to make its way to the CVE and then NVD. During that time, a hacker can use the information about what is vulnerable and how to exploit it to target unsuspecting victims who do not know that they are using a risky open source component in their product.

The brunt of this challenge usually falls on the shoulders of developers and their managers, who have to ensure that they are using secure and updated versions of open source components. More often than not, developers are not pulling the most recent version of a component, and are unaware of any vulnerabilities which are hidden away in the component or its dependencies. Fiascos like the late discovery of the Heartbleed vulnerability and the Equifax data breach prove that staying abreast of newly discovered open source security vulnerabilities and updating insecure versions are not exactly a welcome task when you’re racing from one sprint to the next. Concepts like the Software Bill of Material have emerged to help with this problem.

Open source vulnerabilities management: knowing your code

Organizations that are developing software need to actually keep track of all the open source components that they are using, and be able to know when a component that they are using becomes vulnerable if they hope to stay ahead of those who would do them harm.

If companies used to skate by on Excel sheets for tracking open source components, the sheer scale of their usage has rendered this method useless. Seeing as how open source components now comprise between 60-80% of the code base in modern applications, the time has come to adopt automated solutions that can track what is being used and monitor the various resources discussed above for when a new vulnerability is publicized. 

Knowing what your team is using is the start of a conversation that allows you to empower your developers by not burdening them with the task of manual tracking. Staying on top of the open source components in your development products with automated tools allows them to focus not on whether a license is in line with company policy or if there is a vulnerability that could put your product at risk.

Security measures that aren’t easy for developers to include are likely to end up being ignored. Providing developers with an easy way to follow what they are using without taking up their valuable time will make it far easier for them to remediate issues when they do arise, and as we learned from G.I. Joe, knowing is half the battle.