What do open source maintainers know about security?
This post originally appeared on CSO Online, on November 30th, 2017.
Open source maintainers give up their own time to create great pieces of free software, which we then use to create business value. However, by consuming these projects we are also relying on these maintainers to keep these projects secure, and failing to do so may even outweigh the value we got.
In our recent survey on the state of open source security, open source consumers and maintainers were asked about their security expertise, actions and sense of ownership—and the results were very mixed.
One focus area revolved around the maintainer’s expertise. Maintainers were asked to rank their security expertise, ranging from “High” to “Next to nothing.” The results were not encouraging, however, they could be worse. Only 16.8 percent of maintainers ranked their expertise as high. Another 56 percent ranked it as medium, while 26 percent ranked it as low. On the positive side, only one percent of maintainers said they know “next to nothing” about security.
While seeing only one in six maintainers has high security expertise isn’t great, these stats likely reflect the general state of security proficiency among developers (if they’re not a little bit better). It does, however, demonstrate that security savvy OSS consumers should seriously consider contributing some of their expertise back, to help the entire ecosystem gain some of this knowledge and propagate it back.
The most upsetting set of results came in around security practices. A shocking 43.7 percent of maintainers said they never audited their code for security issues, and another 31.8 percent only audited their projects once or twice. Thirteen percent said they audit annually, while a mere eleven percent audit their code at least quarterly. Extrapolating these stats from maintainers to projects, nearly half of the OSS projects you consume have never been audited, and about a third are marginally better.
Inspecting the top 400,000 projects on GitHub, only 2.4 percent of projects include a file containing any security information, holding anything from how to disclose a discovered vulnerability to security related configuration. The OSS ecosystem doesn’t incentivize OSS maintainers to spend time on security, and as a result – they indeed do not.
Speed of response
Ending on a positive note, maintainers were asked how quickly do they think they can free up and resolve a security issue reported to them. An impressive 34 percent of maintainers said they’ll make time to fix it within a day, and another large group of 60 percent said they’ll do so within a week. Having 94 percent of maintainers willing to address the issue within a week or less is extremely beneficial, and faster than many commercial development shops.
In practice, we see the median time to repair a reported vulnerability is 16 days from disclosure to fix. Since it takes time to go from jumping on a reported issue to having a working fix, it goes to show that maintainers are closely delivering on these promised timelines.
This stat gives hope that the previous problems can be fixed, because it shows maintainers care. Remember that OSS maintainers are not paid for their work, so it’s not obvious they are able – or willing – to drop everything to address a reported security flaw. Their willingness to do so shows they encourage high security, they just need better scaffolding and support to make it happen—and we need to give them that.
Where do security patches come from?
January 25, 2018The best solution for known vulnerabilities is to upgrade your software. But sometimes there's not a security update immediately available. The next best solution is to patch your software. In this post, we go through four ways to find security patches for open source software.
npm Shrinkwrap Reloaded: Locking npm Deps with Package-Lock and Yarn.Lock
January 10, 2018Locking or “pinning” dependencies is a widespread best practice in Ruby, Python, and other ecosystems. In Node.js locking was much less widespread, until recently, thanks to the improvements provided by package-lock.json and yarn.lock. This post discusses how each of these solutions works and why you may want to use them.
Subscribe to The Secure Developer Podcast
A podcast about security for developers, covering tools and best practices.
Interested in web security?
Subscribe to our newsletter: