Security should not be taken lightly

Open Source security lifecycle: It takes almost 3 years to publicly disclose library vulnerabilities

Gabriela Motroc
open source

© 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. 

Open Source

To read more about open source, download the latest issue of JAX Magazine:

All eyes on Open Source

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.

Discovering vulnerabilities

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. 

Releasing fixes

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.

SEE ALSO: Think open source software is free? Think again…

Notifying users

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.

SEE ALSO: Dependency update: Auto-fix tools are helpful but they can only take developers so far

Now what? Advice from the State of Open Source Security report

If you maintain open source code,

  1. Make sure your project has a public-facing disclosure policy so anyone who finds vulnerabilities can quickly report them to you.
  2. Run regular audits and security checks against your codebase to make it easier for you to catch vulnerabilities before they become public.
  3. 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,

  1. Use a tool to automatically detect known vulnerabilities in your third-party components so you can fix them as quickly as possible.
  2. 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.
  3. 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

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments