"Knowing whether you are exposed to a just-announced vulnerability in a rapid fashion is more than half the battle." - probably Sun Tzu, if he were alive today ;)
Software supply chain security is rapidly gaining attention, thanks to major vulnerabilities like dependency confusion, as well as software supply chain attacks against critical and pervasively used companies like SolarWinds and Codecov. Open source software in particular has faced the brunt of the attackers, forcing the industry to band together and work on security projects like sigstore, security scorecards and the SLSA framework.
Despite these efforts, one thing is painfully evident - very few projects actually know the composition of their application binaries. And when a vulnerability like Apache Log4j gets announced, it's a mad scramble to find out the blast radius. Just see the dependency hell that developers had to deal with for Log4j (h/t deps.dev).
So, the industry embarked on another project to deal with this - SBOM.
A software bill of materials (or SBOM for short) is a complete inventory of software components and dependencies of an application. This includes open source and closed source packages, language frameworks and runtimes, shared objects/libraries and other software components required for the application to be built and run as expected. Even if a package is patched, it does not mean that all dependent packages have upgraded to incorporate the latest release. However, once you understand the interdependencies, it is easier to gauge the risk of exploitable vulnerabilities and kickstart the remediation process.
As a concept, SBOM isn't new - it is borrowed from the bill of materials (BOM) that was traditionally used in the manufacturing industry and has since permeated the IT industry via software procurement. Apart from dependencies, SBOM is also useful to understand software license composition and compliance issues.
All SBOMs were not created equal though. So, in an effort to standardise the components of an SBOM, the National Telecommunications and Information Administration (NTIA) released a set of guidelines in 2021 which cover three minimum elements - data fields, automation and processes.
- Data fields: SBOMs should contain baseline information about each component to be tracked (Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp).
- Automation: SBOMs should support automatic generation, machine-readability, and common data formats (SPDX, CycloneDX, SWID tags).
- Processes: SBOM operations (requests, generation and use) should be defined (Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes).
SBOMs are typically generated during the application development life cycle - CI/CD tools can automatically create SBOMs as part of the pipeline, or software composition analysis (SCA) tools can scan for components and generate SBOMs. For a complete picture, SBOM generation tools must navigate the entire dependency graph though, and not just present a one-level deep picture.
Common data formats are really key for widespread adoption e.g. the Software Package Data Exchange (SPDX) specification is an industry standard for publishing SBOMs such that they can be easily and automatically ingested by software vulnerability and patch management tools.
In 2021, US President Biden issued an executive order requiring all Federal Government software suppliers to include SBOMs in their submissions. Taking a cue, security teams all over should start asking software vendors to provide SBOMs for all applications - it may take a while to get everyone onboard, but it is definitely a worthwhile effort.