How to find the best Software Composition Analysis (SCA) for your organization
Best practices for quick remediation and response
Responding to New Vulnerability DisclosuresThe 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.
Testing to prevent vulnerable open source libraries.
Integrating Testing to Prevent Vulnerable LibrariesOnce 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.
Fixing vulnerable open source packages.
Fixing Vulnerable PackagesFinding 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.
When and how to test your application for open source vulnerabilities.
Finding Vulnerable PackagesNow 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.
Understanding known vulnerabilities in open source packages.
IntroductionOpen 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?.
Guy Podjarny on why open source security is a community responsibility. Continue reading Who owns open source security?.