Securing Open Source Libraries

Chapter 7. Summary

Open source is amazing, and is here to stay, but it’s also a complicated beast when it comes to ownership, trust, and security. Unlike purchased software, once you download an open source library you are on your own. There is no vendor to notify you about issues, no commitments that vulnerabilities will be found or fixed, and nobody to sue to if you got hurt.

If you’re using open source (and you most certainly are), you need to take on the responsibility of keeping it secure. You must set up the tools and processes that will help you stay safe, and raise awareness of this risk throughout your organization. The 2017 Equifax breach serves as a very painful lesson of what could happen if you don’t.

While open source security is a broad topic, the most critical part of it is dealing with known vulnerabilities in open source libraries. This book suggested a framework for dealing with this risk, split into four steps:

• Find the vulnerabilities in your dependencies

• Fix the found issues quickly and efficiently

• Prevent additions of new vulnerable libraries during dev

• Respond to newly disclosed vulnerabilities in libraries you already use

These logical steps should hold true regardless of the tools you choose for addressing this problem, but I definitely suggest you leverage a Software Composition Analysis (SCA) solution to help you get them done. Each chapter points out various tool attributes to consider, tips on how to integrate them, and the trade-off you’ll ...