SBOM Use Case: Cybersecurity
It is vital to ensure that software deployed on a system does not carry any known vulnerabilities; otherwise, a security incident is only a question of when, not if. While the main focus is on the security and known vulnerabilities of the application itself, its components also need to be considered. Each component added to a piece of software expands its attack surface, and any component with a known security issue increases the risk to the surrounding software. This might be due to a known bypass for a used input sanitizer or an observed exploit leveraging an included component.
Consequently, SBOMs become a vital tool in any arsenal to secure our software by providing an overview of all components. This list of components can be automatically cross-checked against threat intelligence feeds, e.g., the National Vulnerability Database, such that identifying vulnerable components becomes a routine part of the development process. In the event of a security incident, once the attack vector has been identified, the SBOM can also help with incident management by allowing fast indexing of all software that includes the exploited components, pinpointing the potentially compromised systems.
Identifying Vulnerable Components
Section titled “Identifying Vulnerable Components”Modern software is not a monolith written from scratch but rather a conglomeration of individual components that each provide part of the required functionality. Furthermore, components are dynamically added and removed during the development process, and each component can bring in additional transitive components. Manual due diligence on all these directly and indirectly added components becomes unrealistic. However, each added component and its functionality may also provide attack vectors if it contains vulnerabilities. Having an SBOM that lists all included components allows for an automated cross-check of components against threat intelligence feeds of known vulnerabilities, for example in the CI/CD pipeline, allowing the development team to identify potentially vulnerable components early and update or mitigate them.
Example
Section titled “Example”During the development of a Java software project, multiple dependencies are added, including a component that itself depends on log4j. The development happened in the first half of 2021; the development team did their due diligence, and no known vulnerability existed in any of the added components. Half a year later, Log4Shell hits. Other software vendors, without SBOMs, are scrambling to identify software products that include log4j with the vulnerable version, whereas any vendor that maintained their SBOMs can simply search the machine-readable SBOMs for any mention of log4j to identify exposed products that need attention.
Incident Management
Section titled “Incident Management”Even with the best security practices, a security incident might still happen. After understanding how the attacker breached a system, it is essential to identify all other systems that might also be affected. This includes not only systems exposed by the exploited system but also all systems that can be exploited with the same attack. SBOMs assist with this search: once the attack and the software and components involved have been identified, the SBOMs of each system’s software can be cross-checked against this information, and any dangerous similarities to the breached system can be addressed.
Example
Section titled “Example”The incident response team identified a breach in one of the public-facing websites. The attacker used an SQL injection vulnerability to manipulate the database. It turns out that the injection vulnerability is due to a faulty sanitization function in a component that the exploited software depends on. Now, by simply scanning the SBOMs of all deployed software, the response team can identify not only all systems that run the exploited software but also any other software that uses the component with the faulty sanitizer and might therefore have been exploited as well.