Choosing a tool to track and mitigate open source security vulnerabilities

How to find the best Software Composition Analysis (SCA) for your organization

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. Continue reading Choosing a tool to track and mitigate open source security vulnerabilities.

Responding to new open source vulnerability disclosures

Best practices for quick remediation and response

Responding to New Vulnerability Disclosures

The techniques to find, fix, and prevent vulnerable dependencies are very similar to other quality controls. They revolve around issues in our application, and maintaining quality as the application changes. The last piece in the vulnerable library puzzle is a bit different. In addition to their known vulnerabilities, the libraries you use also contain unknown vulnerabilities. Every now and then, somebody (typically a library’s authors, its users, or security researchers) will discover and report such a vulnerability. Once a vulnerability is discovered and publicly disclosed, you need to be ready to test your applications for it and fix the findings quickly—before attackers exploit it. Continue reading Responding to new open source vulnerability disclosures.

Integrating continuous testing for improved open source security

Testing to prevent vulnerable open source libraries.

Integrating Testing to Prevent Vulnerable Libraries

Once you’ve found and fixed (or at least acknowledged) the security flaws in the libraries you use, it’s time to look into tackling this problem continuously. There are two ways for additional vulnerabilities to show up in your dependencies: Continue reading Integrating continuous testing for improved open source security.

Mitigating known security risks in open source libraries

Fixing vulnerable open source packages.

Fixing Vulnerable Packages

Finding out if you’re using vulnerable packages is an important step, but it’s not the real goal. The real goal is to fix those issues! This chapter focuses on all you should know about fixing vulnerable packages, including remediation options, tooling, and various nuances. Note that SCA tools traditionally focused on finding or preventing vulnerabilities, and most put little emphasis on fix beyond providing advisory information or logging an issue. Therefore, you may need to implement some of these remediations yourself, at least until more SCA solutions expand to include them. Continue reading Mitigating known security risks in open source libraries.

Finding vulnerable open source packages

When and how to test your application for open source vulnerabilities.

Finding Vulnerable Packages

Now that you understand what a known vulnerability is, let’s start going through the four steps needed to address them: find, fix, prevent, and respond. The first step in solving any problem is acknowledging you have one! And so, with vulnerable packages, your first act should be to look for vulnerable packages your application is consuming. This chapter discusses how to test your application, when and how you should run such a test, and the nuances in running the test and interpreting the results. Continue reading Finding vulnerable open source packages.

What defines a known open source vulnerability?

Understanding known vulnerabilities in open source packages.


Open source software—the code of which is publicly available to scrutinize and typically free to use—is awesome. As consumers, it spares us the need to reinvent the wheel, letting us focus on our core functionality and dramatically boosting our productivity. As authors, it lets us share our work, gaining community love, building up a reputation, and at times having an actual impact on the way software works. Because it’s so amazing, open source usage has skyrocketed. Practically every organization out there, from mom-and-pop shops to banks and governments, relies on open source to operate their technical stacks—and their businesses. Tools and best practices have evolved to make such consumption increasingly easier, pulling down vast amounts of functionality with a single code or terminal line. Continue reading What defines a known open source vulnerability?.