Imagine that a new vulnerability in lodash was just announced. Applications using the npm package are being exploited through large scale automated Denial of Service (DoS) attacks. You need to act quickly to understand if your organization's systems are at risk. You need to figure out if any of your 6,000 applications are using the vulnerable versions of lodash before adversaries discover an exploit path through one or more of your applications.
The clock is ticking. Your customer's data is potentially at risk. Can you do it?
This isn't just a hypothetical. It's a very real situation that is happening more and more often - just think back to eventstream vulnerabilities. In some cases, exploits can come down to life or death; look at how commons-collection was manipulated at Hollywood Presbyterian Hospital or how pacemakers were recalled by Abbot Laboratories after they found a remote hacking vulnerability.
It is vital, anytime a vulnerability in open source software (OSS) components are announced, that two questions are answered as soon as possible:
Did we ever use the vulnerable version(s) of the open source component?
If yes, in what applications do they reside?
Answer immediately: Advantage goes to you. Prolong your answer: advantage goes to the adversary. Your answer could be found through automation requiring seconds of analysis. Or it might resemble a scavenger hunt taking weeks to months. The best organizations have automated faster than ever.
Organizations that create a software bill of materials (SBOM, or sometimes called a CBOM for "cybersecurity bill of materials") and apply automation and intelligence services to track new vulnerabilities across them over time, can answer these two questions immediately. Yet, according to our 2019 DevSecOps Community survey, even among the highest performing software development teams, only 53% of companies utilize an SBOM as part of their development and application security practice.
Creating an SBOM for every application is touted as a necessity by many governing bodies. Just to name a few:
The FDA started recommending the use of SBOMs for medical device manufacturers as far back as 2017. In January 2019, new PCI secure development standards advise organizations to generate an SBOM to track and trace the location of every single component.
The Commerce Department's National Telecommunications and Information Administration (NTIA) is considering requiring companies to list their sources of software parts to protect the U.S. software supply chains.
The U.S. House Energy and Commerce Committee released its Cybersecurity Strategy Report which details the importance and priority for utilizing an SBOM (December 2018).
More recently, Gartner discussed the importance of SBOMs in the context of a software composition analysis (SCA) practice; further highlighting why they're a strategic necessity.
In its report Technology Insights for Software Composition Analysis, Gartner places growing importance on SBOMs stating:
"By 2024, the provision of a detailed, regularly updated software bill of materials by software vendors will be a non-negotiable requirement for at least half of enterprise software buyers, up from less than 5% in 2019.
By 2024, 60% of enterprises will automatically build a software bill of materials for all applications and services they create, up from less than 5% in 2019." [emphasis added]
The best development teams understand the value of an SBOM - and it’s clear that now, more than ever - enterprises need to know what’s in their software at all times.
Literally every organization that builds software uses a combination of custom-built code, commercial ready-made code, and open source and third party components. Some build better software than others; but, as we already know, it's proven that the ones who build the best software use SBOMs for their codebases. Exemplar organizations do this because they recognize the parallels between software development and traditional manufacturing: Know what OSS and third-party parts are used inside and don't pass known defects downstream.
Open source components are particularly dynamic. They allow companies to save time and money, improve quality, deliver business agility, and mitigate (some) business risk. Open source components have become necessary in speeding up development timeliness and springboarding innovation. Production would be exponentially slowed and stunted without it. In fact, last year's State of the Software Supply Chain report showed a 68% YoY increase in Java component use - or 146 billion download requests.
But, to effectively manage large scale open source component use, you need to know what components you're using. That's where an SBOM comes into play. It tells you what open source software components your development teams are using and describes which of those components have known security vulnerabilities, architectural risks, or license risks. It enables you to make those quick decisions, identify exposure, and take appropriate steps in response to new vulnerabilities.
More specifically, the SBOM inventories:
Open Source Components and Versions - Rapid iteration -- benefiting ongoing evolution and refinement -- results in numerous components and ongoing version control. An automated SBOM provides real-time understanding of both. This is important because the average enterprise downloads upward of 500,000 open source components a year, according to our research.
Open Source Licenses - Similarly, an SBOM enumerates the licenses that govern open source components. This protects you from legal and/or intellectual property risks associated with improper use. Creating an SBOM protects your end-user application and ensures proper compliance within the broader software supply chain.
Open Source Vulnerabilities - Crucially, an SBOM enables rapid discovery of components should one of them suddenly become vulnerable. What good is a warning about defective parts if those parts cannot be located and replaced? Every minute a compromised component remains inside software is another minute for potentially devastating damage. An SBOM speeds the remediation time by telling you exactly where certain components and dependencies are being used.
If you're not already creating SBOMs, and want to see what's inside your application, start by using our free service, the Sonatype Vulnerability Scanner, to generate one for your application.
Creating an SBOM and knowing what's in your applications is the first step to better understanding what open source and third-party components have been flowing into and through your software supply chains.
Don't think it matters? Last year, the average enterprise organization consumed over half a million open source and third-party components. On average, 10% of them had known security vulnerabilities.
The clock is ticking. Have you automated faster than ever?