Open Source security lifecycle: It takes almost 3 years to publicly disclose library vulnerabilities
© Shutterstock / penang
We’ve already dissected Snyk’s State of Software Security Report and we’ve pointed out that about 75% of application code is made up of open source components. What we still haven’t covered is the lifecycle of an open source security vulnerability and the steps that play an essential role in the overall state of security. Let’s proceed.
Snyk‘s latest report titled The State of Open Source Security emphasized the importance of the overall security of open source. We’ve already suggested that you should be mindful about where your code is coming from but this doesn’t mean we don’t love open source. On the contrary — our latest JAX Magazine issue is an ode to open source.
To read more about open source, download the latest issue of JAX Magazine:
Open source skills are a boost for career prospects — if you don’t believe it, it’s time to bring out the big guns.
We invited the Eclipse Foundation, The Apache Software Foundation, Cloud Foundry, Red Hat, Hyperledger and more to show you why open source is important. You’ll surely learn a lot from their experiences!
But don’t take my word for it! Open the magazine and allow their passion to “infect” you.
That said, let’s have a look at Snyk’s findings with regard to the open source security lifecycle.
There are a lot of steps involved in the lifecycle of an open source security vulnerability. From discovery through final adoption of fixes, each part of the process is important in its own way, and ultimately plays a role in the overall state of security.
How long does it take for a vulnerability to be disclosed after it has entered the library? Apparently, almost three years. Furthermore, 75 percent of vulnerabilities are not discovered by the maintainer and nearly 80 percent of maintainers claim they have no public-facing disclosure policy in place.
The “days of risk”, namely the time it takes from disclosure to when a vulnerability is addressed is the second step. Snyk looked at the top nine npm package vulnerabilities that impacted the most applications this year.
According to their results, it usually takes around 2.5 years (the maximum is up to six years!) for a vulnerability to be disclosed and roughly 16 days from disclosure to fix. 34 percent of maintainers said they could respond to a security issue within a day of learning about it, and 60 percent said they could respond within a week.
Once a vulnerability has been addressed, users must be informed as soon as possible so they know what steps to take to secure their applications. Almost 90 percent of authors inform users via release notes, 34 percent choose to deprecate the version and 25 percent don’t tell users about security issues.
Adopting published fixes
Last but not least, it’s important to look at how quickly users adopt fixes once they’ve been published. However, this may take some time since users have to be notified of the fix and then make sure the new version does not break their application.
When asked how they keep dependencies up to date, 47 percent of users said they occasionally do a sweep to bump versions while 42 percent use tools to alert them to vulnerable dependencies. 37 percent use tools to update to new versions of dependencies and 16 percent don’t update.
Now what? Advice from the State of Open Source Security report
If you maintain open source code,
- Make sure your project has a public-facing disclosure policy so anyone who finds vulnerabilities can quickly report them to you.
- Run regular audits and security checks against your codebase to make it easier for you to catch vulnerabilities before they become public.
- Make it clear to users of your project that you care about security. When a security issue is addressed, clearly present your users with detailed information so they know exactly how to proceed.
If you use open source code,
- Use a tool to automatically detect known vulnerabilities in your third-party components so you can fix them as quickly as possible.
- Contribute back. Most of the time, maintainers are working hard on open source projects in addition to their day-to-day work. Rolling up your sleeves and helping address issues is one of the best ways to ensure your favorite project stays healthy and secure.
- Report vulnerabilities as responsibly as possible. If you find something amiss, look for a private way to tell the maintainers about it. If there’s no public disclosure policy, see if you can discretely inform them through email or some other form of communication.
Download the full report here.