Here are 4 best practices to help you create an issue-resistant free and open source software vulnerability management program while remaining agile.
How often do you read those all-too-familiar “vulnerability discovered in X software” headlines? More importantly, how quickly have you as a security director, application owner, or engineer been able to respond to them? You may have good control over all the applications you run, but do you know every version of every library in all of your projects?
If not, do you trust all the open source projects for which source code is included in your applications? Perhaps you do. After all, according to Eric Raymond’s The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, Linus’s Law states that “given enough eyeballs, all bugs are shallow.”
But are software vulnerabilities covered in Linus’s Law? Perhaps the law doesn’t apply because software vulnerabilities outstretch mere bugs and encompass everything from architectural issues to emergent properties of complex systems. Or, perhaps secure coding is covered by Linus’s Law where free and open source software (FOSS) security failures are actually part of the feedback loop (baked into the law). Either way, your organization, shareholders, and clients shouldn’t be forced to participate in anything that puts them at this much cyber risk.
So, how can you solve this issue of free and open source software vulnerability management? Unfortunately, there isn’t a single industry-recognized tool that does it all on its own. In order for your developers to leverage all that bootstrappable code, you’ll need to do some heavy lifting at first. The end goal is a mature FOSS vulnerability management program—but what does that even look like?
While nobody can explicitly say what a mature program looks like for your organization, here are four best practices for managing open source code from a security perspective.