AppSec Decoded: Is an SBOM a silver bullet for software supply chain security?

In this episode of AppSec Decoded, we discuss what an SBOM can and can’t do in terms of software supply chain security.

2021 was the year of software supply chain attacks. High-profile security breaches like Codecov, Kaseya, and Apache Log4j demonstrated the widespread damage that can occur with only a single exploitation in the software supply chain. Attacks like these prompted President Biden’s cybersecurity executive order 14028, which calls for the National Institute of Standards and Technology (NIST) to define cybersecurity standards for companies doing business with the federal government.

Among the anticipated guidelines is a software Bill of Materials, or SBOM, which acts as an ingredients list of all the open source and third-party components in a codebase. 

So when the stakes are high, as they were last December with the disclosure of Log4j, an SBOM might have been the silver bullet needed to secure the software supply chain, right?

Not quite. While an SBOM can verify if a vulnerability version of Log4j exists in a given codebase, it’s only for that application. Organizations with multiple applications and hundreds of thousands of lines of code would need an SBOM for every codebase to properly assess the security risk of their business.

In our latest episode of AppSec Decoded, Taylor Armerding, security advocate at Synopsys Software Integrity Group, sat down with Tim Mackey, principal security strategist at Synopsys Cybersecurity Research Center, to discuss how an SBOM can help organizations tackle today’s software supply chain security. Mackey also discusses what security measures government agencies like NIST need to establish to ensure organizations can address the complexity that comes with managing security risks of their software supply chain.

Stay on top of the latest application security news

Subscribe to the blog