Understanding SBOMs: A snapshot of your software security
Image by macrovector via Freepik
In May of 2021, President Biden signed the Executive Order on Improving the Nation’s Cybersecurity. The order directs government agencies to make sweeping changes to ratchet up software security policy at the Federal level.
The order set into motion a flurry of activity across government agencies, as some of the nation’s top cybersecurity experts work diligently to ensure the technological infrastructure underpinning our civic lives is in alignment with these new regulations.
In the midst of these conversations about securing the software supply chain, one term consistently rises to the forefront: SBOM.
SBOM stands for Software Bill of Materials. It’s an accounting of all the components in a software application. More precisely (per the NTIA), an SBOM is a “complete, formally structured list of components, libraries and modules that are required to build a given piece of software and the supply chain relationships between them.”
As a result of the Executive Order, we can expect that all developers and software suppliers doing business with the federal government will be required to provide SBOM. The timeline for compliance has not yet been established, but the policy is moving quickly, and we are likely to see these regulations in place within the year. And it’s not just the feds who should be thinking about SBOMs; any enterprise owner looking to secure their software supply chain should be familiar with SBOMs and require them from their software vendors.
Today, more than 90% of all new software is built using open-source components. The upside of open source code is that the opportunities are limitless - developers have unprecedented freedom and access to create new applications using existing building blocks. The downside is that, in many cases, those components contain vulnerabilities and deeply embedded licensing restrictions that jeopardize the integrity of the package.
An SBOM solves that by providing transparency.
What’s in an SBOM?
The NTIA defines the minimum elements to be included in an SBOM.
● Supplier Name The name of an entity that creates, defines, and identifies components.
● Component Name Designation assigned to a unit of software-defined by the original supplier.
● Version of the Component Identifier used by the supplier to specify a change in software from a previously identified version.
● Other Unique Identifiers Other identifiers that are used to identify a component or
serve as a look-up key for relevant databases.
● Dependency Relationship Characterizing the relationship that an upstream component
X is included in software Y.
● Author of SBOM Data The name of the entity that creates the SBOM data for this component.
● Timestamp Record of the date and time of the SBOM data assembly.
License information (and license text) is also often included.
There are a number of tools in the market available for generating and publishing SBOMs. It’s important to remember, however, that an SBOM is just a snapshot in time. In order to truly secure your software supply chain, you must continuously check for new vulnerabilities. Yesterday’s SBOM is no more useful than the Covid test you took last week. There are always new risks emerging, and scanning must be a constant, ongoing process.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!
