As an open source security expert, I spend a considerable amount of time working with engineering and security managers to help them build a more productive open source management process. One theme always seems to pop up in our discussions: how come we are using so much open source in our products, but yet my team doesn’t know basic facts about open source security?
So, based on hours of conversations, countless coaching sessions and a dose of good old common sense, here are seven facts your boss wants you to know about open source security.
I’ll start with the most important fact about open source security. All open source components may be vulnerable. Having a large active community behind a certain project does not make it invulnerable. You can chek the latest report showing that 1 in 16 Java components has a security vulnerability.
The risk of vulnerabilities in open source components is usually underappreciated or even ignored by developers. Even experienced developers believe that if certain projects have a large user community, then it must be vulnerability-free.
Unfortunately, this is not true, and there is no shortage of examples proving us that even popular open source projects with a large user community can contain vulnerabilities. Heartbleed is obviously the most famous example. Heartbleed was a small bug in Open SSL’s implementation of the TLS heartbeat mechanism. Although Open SSL has a very active user community, it was discovered two years after being introduced to the project. Another extreme example is Shellshock, which was discovered after almost 25 years (it was introduced to Bash in 1989 and discovered in late 2014).
When it comes to choosing open source components, developers usually check functionality, the popularity of the open source project (forks, commits, stack overflow questions etc.), references and if proper documentation exists. They rarely check if the libraries they are about to integrate into their software are vulnerable or not.
The majority of companies are investing trying to monitor open source vulnerabilities, but only later in the process. The methods vary from manual tracking to automated tools that monitor the build or just a code scan pre-release, but that first stage where components are added in usually neglected. If companies will ensure their developers will check vulnerabilities before integration, many hours of work can be saved. Companies that have provided their developers the right tools to pre-check the components have seen an increase in productivity and security.
Security analysts are running multiple static application security tests (SAST) on the source code and dynamic application security tests (DAST) when the application is running in order to find potential vulnerabilities in your code.
These tools are not effective to find issues in open source components in your software. Besides of the fact you will get an endless hit list, your team will not be able to properly investigate each potential vulnerability alerts as they are not familiar with the source code.
The only way to detect vulnerabilities in your open source components is the match between reported known open source security vulnerability and the open source components you are using.
Whenever a security researcher or any developer finds a security vulnerability, in an open source or a commercial library, he or she request MITRE for a CVE identifier that is added to the CVE database. Once MITRE provides a CVE identifier, this means the vulnerability was checked and verified. It is not a potential issue you may want to check out, but a real security risk that you need to fix. Otherwise, you are leaving your software vulnerable, and you are doing so while all the hackers out there know about this vulnerability and how to exploit it.
This is why all open source users, which is basically every company that develops software, are relying on the open source community to publish CVEs every time security vulnerability is discovered. This also explains the importance of tracking published CVEs and matching it with the open source components in your software.
The CVE database lists all vulnerabilities discovered in open source and commercial libraries, but the CVE itself doesn’t provide any assessment about the risk or information how to patch it.
The NVD (National Vulnerability Database) analyzes CVEs from the CVE database to provide enhanced information for each CVE Identifier such as fix information, severity scores, and impact ratings. The CVSS (Common Vulnerability Scoring System) can be used for prioritization of vulnerability remediation activities and in calculating the severity of vulnerabilities discovered on one’s systems. The CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics. You can see an example of the calculation here.
CVSS score distribution shows us the majority of vulnerabilities are ranked in the middle (4-8) with almost 13% ranked at the top class, which further emphasize the importance of tracking open source vulnerabilities
The open source community is very quick to respond to discoveries of open source vulnerabilities and, in most cases, a fix is released the same day as the vulnerability details are published.
Usually, vulnerability details won’t be released until a fix is available. It is customary that when an open source security vulnerability is discovered, the open source project managers are contacted and informed about the issue and are asked to offer a fix. A grace period is often extended to provide the project managers enough time to fix the bug (mostly 60-90 days). During this grace period, the vulnerability details will not be published to prevent hackers from taking advantage, and the details will be released once the fix is available.
During this grace period, a CVE will be published as RESERVED with no information, as in this example:
The CVE is published only in order to increase awareness that soon a vulnerability (and hopefully a fix) will be available, so users could patch their software as soon as all information is released.
This means there’s a remediation, and usually more than one, for almost all reported security vulnerabilities in open source libraries, you only need to know what it is. Part of WhiteSource security solution is to automatically suggest all possible remediation for each vulnerability when we alert our users so they can take the necessary steps to prevent exploitation.
Open source security vulnerabilities are a great source for hackers. They can get endless information on any open source vulnerability, including detailed videos explaining how to exploit it and find multiple victims. Exploiting opens source vulnerabilities is a more efficient and productive method for them, as they do not need to develop an attack and one vulnerability leads to many victims.
Due to these reasons, hackers are tuned to the open source community and jump on any vulnerability in common open source projects. The fact that most software companies are not properly tracking their open source usage and, as a result, not patching vulnerable open source libraries, provides hackers the upper hand.
Heartbleed has taught our industry an important lesson. After it took two years to discover a bug in one of the most widely used open source projects and understanding that it was maintained by only two guys, many industry leaders understood a change is needed.
It triggered many commercial software companies and academic organization to offer proper funding and resources to improve the maintenance of popular open source projects, and specifically detecting open source security vulnerabilities. However, and this is a critical fact about open source security that you should always keep in mind, the majority of popular open source projects are understaffed and are lacking resources to handle all feedback flowing in and secure the code all contributors continuously add.
The biggest initiative is the CII (Core Infrastructure Initiative), a project managed by The Linux Foundation in collaboration with leading software companies to collaboratively support and fund critical open source projects to improve maintenance and security.
These efforts have significantly increased the number of security vulnerabilities detects in open source components in the past year. Although these efforts are increasing the quality and security of almost all software products out there, it is also increasing pressure on software companies using open source components to keep better track on the open source vulnerabilities in their products and patch it accordingly and immediately.
You cannot do a good job tracking open source security vulnerabilities unless you know exactly what you are using. Having an accurate and comprehensive open source inventory report, including all dependencies, is the first step to better managing your open source usage.
Interested in an automated way to generated a comprehensive and accurate list of your open source components? Try us out!