Choosing a tool to track and mitigate open source security vulnerabilities
How to find the best Software Composition Analysis (SCA) for your organization
Technology (source: lambda86)
Choosing a Software Composition Analysis Solution
Continuously tracking your application’s dependencies for vulnerabilities and efficiently addressing them is no simple feat. In addition, this is a problem shared by all, and is not an area most companies would consider their core competency. Therefore, it is a great opportunity for the right set of tools to help tackle this concern.
As mentioned before, the category of tools addressing this concern is currently known as Software Composition Analysis (SCA). Throughout this book, I’ve referred to different capabilities an SCA solution may or may not have, and the implications therein. Those questions were meant to assist you in designing the right process and selecting the right tools to help.
Learn faster. Dig deeper. See farther.
In this brief chapter, I’d like to offer my opinions about which properties you should care about the most when choosing a tool. The SCA tooling landscape is evolving at an extremely fast pace, so I’ll avoid making statements about which tools handle each requirement well, and instead try to stick to the concepts, which will hopefully stay true over a longer period of time!
Choose a Tool Your Developers Will Actually Use
To successfully deal with open source security, you need your developers (and DevOps teams) to operate the solution. Given the fast pace of modern development, boosted in part by the use of open source itself, an outnumbered security team will never be able to keep you secure. Therefore, the SCA solution you choose must be designed for developers to be successful with.
Unfortunately, all too often, security tools (including SCA solutions) simply don’t understand the developer as a user. Integrating into an IDE or creating a Jenkins plug-in does not automatically make a tool developer-friendly, nor does adding the term “DevSecOps” into your documentation. To be successful with developers, tools need to be on par with the developer experience (DX) other dev tools offer, adapt to the user flows of the tools they connect to, and have the product communicate in a dev-friendly manner.
Notable capabilities I mentioned that affect DX are integrating with source code systems, testing pull requests (PRs), opening fix PRs, and having a rich and easy to use CLI. That said, the best way to know if your dev team will love the solution you choose is to involve them in the selection process, and ask them explicitly if this is a tool they’ll enjoy using. If the answer is no, you’re at high risk of buying an expensive solution only to fail in getting it adopted.
Aim to Fix Issues, Not Just Find Them
SCA tools are typically considered testing tools, flagging security problems at relevant times. However, the real goal isn’t to find vulnerabilities, but to fix them! In your plan for addressing this risk, be sure to go past the find and into the fix.
SCA tools differ greatly in how they support remediation. Some tools offer detailed advisories explaining the vulnerability, how the library entered your application, and what can you do to fix. Other tools go even further and automate the fix creation through fix PRs and patches. On the flip side, some tools don’t go much further than listing the flaws.
You should consider what you see as the ideal remediation process, and then select the tools that help you tee up continuous fixing for success.
Verify the Coverage of the Vulnerability DB
Even a perfect SCA solution can’t protect you against a vulnerability it doesn’t know about. The depth of the vulnerability database used is critical to getting the protection you’re after.
The most common pitfall in today’s SCA landscape is relying exclusively on CVEs. As I’ve explained before, vulnerabilities in application libraries are simply not sufficiently covered by CVEs. Following that, you should inspect the caliber of the DB sources, such as the security expertise in the team that maintains it and the means of vulnerability discovery. Lastly, inspect the quality of the advisories themselves, to ensure they give you the information you’ll need.
If you’re especially security conscious, you’d do well to also seek out databases that are first to disclose vulnerabilities, and offer early notifications on such issues. History shows the number of manually researched vulnerabilities is typically low, but their average severity and the prevalence of the affected libraries is quite high.
Ensure Your Tool Understands Your Dependencies Well
Understanding dependencies is one of those problems that seems easy until you truly dig in. When using an SCA solution, you’re relying on the tool’s ability to properly detect the libraries you are using. If it misses a library, it can easily miss a vulnerability.
One frequent shortcut tools take is to inspect direct dependencies, but not expand the graph to include indirect ones. As I mentioned before, most of the libraries you use (and thus most of the vulnerabilities they’ll hold) are indirect dependencies, pulled down by the packages you explicitly asked to use. It shouldn’t be too hard to check if the tool you’re inspecting goes deep into the dependency graph.
Beyond that, it’s hard to assess the depth of understanding a solution holds. Choose a couple of apps you’re very familiar with and see how well it expands their graph, especially in the application stacks that matter to you most.
Choose the Tool That Fits Tomorrow’s Reality Too
The way we develop software is changing, increasingly getting faster and more continuous. Many companies are in the midst of a digital transformation journey, looking to increase their productivity and speed while maintaining the safety and reliability they’re accustomed to.
Security practices and tools have not evolved as quickly, and many still rely on gates and pauses to allow audits or bring in the experts. Using the wrong security solution can get in the way of improving your development methodologies, which can prove very costly.
The tools you choose should clearly fit your needs today, but it’s equally important to ensure they fit the way you want to develop software, and help you get there, not get in the way.
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 need to make.
As mentioned in the introduction, this book didn’t cover the entirety of open source risk. I didn’t discuss open source tools and frameworks, barely mentioned legal risks, and definitely didn’t dive into potentially malicious libraries. The best practices in these areas are still being shaped, and I recommend participating in events like O’Reilly Security and DevSecCon to be a part of this evolution.
As open source continues to mature, I’m certain the practices and technologies for dealing with its risks will improve as well. Open source is created by the community, and that same community should participate in keeping it secure. In the meantime, make sure you are a responsible member of both this ecosystem and your organization, accept ownership for controlling the risk from the libraries you use, and stay secure!