How Can Devs Keep Up with the Library Security Devil?

So, you don’t have the budget to buy Contrast, but you want your developers to be on top of the security of your open source libraries. No problem! Here’s a few simple tips and tricks to staying current.

Get on the user and developer mailings lists for all your libraries.

Sometimes vulnerability notices are released on the author’s mailing list for library users.

So, each application utilizes, on average, 71 libraries. This is easy -- just subscribe your team leads to those 142 mailing lists! The tricky part will be that your application libraries change so much. We suggest you add a post-commit hook to notify you when libraries change, so you can get on the new lists.

We also hope you have a PhD in writing mail filters, because wow, that will rapidly become a noisy inbox.

Watch the CVE data dump every week.

Mitre releases a data dump every week of the newly published vulnerabilities in their well-known format. You’ll need to write a parser and scan for the relevant libraries that your apps are using. Don’t worry, there are no standards or patterns here. So, you’ll have a lot of fun trying to match their entries with your libraries!

Also, make sure that only the teams that are using a particular library get the CVE notification. That means you’ll need to somehow get a continuous bill-of-materials for all your apps. (If only you had budget for Contrast: you could have that as part of your annual subscription!)

Get on Twitter!

We’re almost there. The CVE folks decided last year that they just can’t keep up with all the vulnerabilities in software. The node.js community doesn’t even bother with CVEs anymore because they couldn’t keep up. So, they built their own system. To compensate for these critical holes, you’re gonna need Twitter.

On Twitter, you can be directly connected to a lot of the security researchers that are on the forefront of application security. You can also learn about other professions that may be less stressful than application security.

Pull applications out of production when a new vulnerability is discovered.

Be careful, there are plenty of these every week, so you’ll want to be quick about disabling your business.  After pulling your app and pissing off your customers, you can begin pissing off your developers. They’ll have to update the library and re-code your application to match any new APIs, re-test to make sure you didn’t break anything, and re-deploy your applications.  Easy!

If your developers say “we don’t even use that library, it’s just a compile time dependency!”, just respond, “Sorry, I can’t prove that because I don’t have budget for Contrast.”

Conclusion

I think I’ve given you a very simple guide on how to make sure you’re in the loop on library security. Now, what about unknown vulnerabilities in your open source libraries?

Well, the charade is up -- you actually do need Contrast Security for that!