When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
As development teams race to keep up with the competitive pace of software production, open source components have become an integral part of every developer’s toolbox, helping them to create and ship innovative products at the speed of DevOps.
The consistent rise in open source usage, along with headline-grabbing data breaches like the Equifax breach that exploited vulnerabilities in open source components, may finally have organizations ready to manage open source security and address the Wild West of open source vulnerabilities. The question is, though, whether they know where to start. (To learn more, see Qualitative vs Quantitative: Time to Change How We Assess the Severity of Third-Party Vulnerabilities?)
Open Source Everywhere
WhiteSource recently published the State of Open Source Vulnerability Management Report to provide insights to help organizations better understand how to approach open source security. According to the report, which included the results of a survey on open source usage conducted among 650 developers from the U.S. and Western Europe, a whopping 87.4 percent of the developers rely on open source components “very often” or “all of the time.” Another 9.4 percent replied that they “sometimes” use open source components. What stood out was that only 3.2 percent of the participants replied that they never use open source, which was taken to likely be as a result of company policy.
These numbers clearly prove beyond a doubt that a developer working on a software project is most probably leveraging open source components.
Open Source Vulnerabilities: Results Are In
The report also dug deep into the WhiteSource open source database, which is aggregated from the National Vulnerability Database (NVD), security advisories, peer-reviewed vulnerability databases and popular open source issue trackers, to learn about the open source vulnerabilities that development teams need to deal with.
Results showed that the number of known open source vulnerabilities hit an all-time high in 2017 with nearly 3,500 vulnerabilities. That’s a rise of over 60 percent in the number of disclosed open source vulnerabilities as compared to 2016, and the trend shows no sign of slowing down in 2018.
What’s the Most Vulnerable of Them All?
The research also delved into the database to find the most vulnerable open source projects and came up with surprising results. While 7.5 percent of all open source projects are vulnerable, 32 percent of the top 100 most popular open source projects have at least one vulnerability.
While one vulnerability is enough to put multiple libraries at risk, a vulnerable open source project contains an average of eight vulnerabilities. That means that the most popular open source projects are often also the ones that are high on vulnerabilities.
This insight becomes even clearer when we look at the list of top 10 open source projects with the highest number of open source vulnerabilities. The top 10 list includes extremely popular open source projects that many of us are using.
These projects have more than one thing in common: Most of them are internet facing, front-end components with wide attack surfaces that are very exposed, making them relatively easy to exploit. That is why they attract a lot of the open source security research community’s attention.
Another aspect that many of these projects share is that most are backed by commercial companies. Given the stakes and resources behind them, one may ask: How could projects supported by such big players be so vulnerable?
The Wild West of Open Source Vulnerabilities
In the past, the discovery of open source vulnerabilities would awaken a lively debate on whether open source components are maintained well enough to be safe for use. Happily, those days are over, and today we know that the rise in reported open source vulnerabilities demonstrates how rapidly the open source community and the security community are responding to keep up with the threat landscape.
The exponential growth of the open source community along with the late discovery of notorious open source vulnerabilities in wildly popular components, like those that allowed Heartbleed to thrive, have brought about a heightened awareness of open source security, and an army of researchers analyzing open source projects for vulnerabilities, as well as a quick turnaround for fixes.
In fact, the WhiteSource report found that 97 percent of all reported vulnerabilities have at least one suggested fix in the open source community, with security updates usually published within days of the publication of a vulnerability. (For more on open source, check out Open Source: Is It Too Good to Be True?)
The Open Source Community Is on Top of Security — Now Users Need to Catch Up
While the open source community’s collaboration and efforts at improving open source security are definitely showing results in terms of vulnerability discovery, disclosure and quick fixes, it’s hard for users to keep up, due to the decentralized nature of the open source community.
When developers use commercial software components, version updates are a part of the service that they pay for and the vendors can be plenty pushy about making sure that you see it.
That’s not how open source works. WhiteSource data that showed that only 86 percent of reported open source vulnerabilities appear in the CVE database. This is because the collaborative and decentralized nature of the open source community means that the information and updates about open source vulnerabilities are published across hundreds of resources. That kind of information is impossible to track manually, especially when we consider the volume of open source usage.
How to Get Ahead in Open Source Security
The consistent rise in open source vulnerabilities is a challenge that organizations must address head-on, considering how common open source usage has become. While the high number of open source vulnerabilities, including the most popular projects, might seem overwhelming, learning the way that the community manages open source security is a step in the right direction.
The next step is accepting that open source security management comes with a different set of rules, tools and practices than securing commercial or proprietary components. Sticking with the same vulnerability management programs and tools won’t help with open source security management.
Adopting an open source security policy that addresses these differences and incorporating the right technologies to automate their management will help security and development teams face the unique challenges of open source vulnerabilities head-on, allowing them to get back to the business of building great software.
