A Software Bill of Materials (SBOM) is a security document that identifies every component in a device or piece of software and lists related information about each component, including supplier names, versions, unique identifiers, and dependencies.
SBOMs are like ingredient labels for technology. An ingredient label includes everything used to create a food product so that consumers can track nutritional information and avoid allergic reactions. Similarly, an SBOM tells everyone who works with technology what was used to create it, so they can track vulnerabilities and mitigate cybersecurity risks.
SBOMs are a critical part of the software supply chain. SBOMs simplify and strengthen cyber security.
By establishing transparency for devices or software, SBOMs enable manufacturers, customers, and end users of technology to conduct continuous vulnerability monitoring, communicate about new risks, and ensure compliance with industry regulations.
Back to Top
Without SBOMs, there is no universally accepted best practice for tracking software components. This prevents transparency, increases complexity, and makes vulnerability monitoring a time-intensive and costly process.
Transparency is the only way to trust technology. SBOMs provide granular insight in a common format that can be used to compare devices and cross-reference components with resources like the National Vulnerability Database (NVD).
Instead of taking a passive approach to cybersecurity (responding to a breach or attack after it happens), SBOMs enable organizations to take a proactive approach (finding and fixing vulnerabilities before they become threats).
Back to Top
In 2021, the United States Department of Commerce released The Minimum Elements for a Software Bill of Materials (SBOM), which communicated the purpose and format for SBOMs as standardized security documents.
The minimum elements for an SBOM include the following details for proprietary, third-party, and open source software components:
- Supplier Name
- Component Name
- Component Version
- Other Unique Identifiers (e.g. Common Platform Enumeration (CPE))
- Dependency Relationships
- Author of SBOM Data
- Timestamp of SBOM Data
Back to Top
The Department of Commerce includes three data standards for the creation of SBOMs:
- Software Package Data eXchange (SPDX)
- CycloneDX
- Software Identification (SWID) tags
SBOMs that meet these standards can be manually created or automatically generated.
Manufacturers of devices or software can manually create SBOMs using their knowledge of the codebase. Following a common standard, they can list minimum required elements in a text file. However, manual SBOM creation is a time-consuming and error-prone process.
To generate, manage, and update SBOMs at scale, it is recommended to use an automatic SBOM generator (like Vigilant Ops). Automatic SBOM generators are quicker and less error-prone than manual processes. They can scan software that is in development or already deployed, identify individual components, and include all minimum required elements in a preferred format.
Back to Top
SBOMs are predominantly used in highly regulated industries like healthcare, finance, energy, and government. The U.S. Food and Drug Administration (FDA) now mandates SBOMs in its premarket guidance for all “cyber devices” (including any devices with the ability to connect to the internet.)
However, SBOMs are rapidly becoming a standard security practice in other industries.
Developers and manufacturers of technology use SBOMs to track and monitor vulnerabilities for their products so they can communicate with customers and quickly develop security patches when required.
Security professionals use SBOMs to track, monitor, and respond to vulnerabilities across their organization. Standard formats enable them to compare products and quickly find Common Vulnerabilities and Exposures (CVEs) when they are disclosed.
Compliance officers use SBOMs to meet regulatory requirements and cybersecurity standards in their industry.
Back to Top
Today, there are a variety of SBOM generation tools available, making it easy for most organizations to create initial documentation.
However, as SBOMs are created for multiple devices and shared amongst multiple organizations, managing the SBOM lifecycle becomes a significant challenge.
The “SBOM Lifecycle” includes every step required to use SBOMs as part of a standard security process:
- Managing existing SBOMs
- Making updates to SBOMs as technology evolves
- Monitoring for new vulnerabilities
- Searching for vulnerabilities in existing SBOMs
- Sharing SBOMs with relevant stakeholders
- Distributing security patches
- Staying compliant with the latest industry regulations
SBOM Lifecycle Management tools like Vigilant Ops can help security professionals make the most of their SBOMs to secure their software supply chain in a scalable and efficient manner.
Back to Top
Organizations that want to adopt SBOM best practices should start with a tool (like Vigilant Ops) that generates SBOMs in standard formats like SPDX, CycloneDX, or SWID.
To maintain a repeatable security process, organizations should look for an SBOM Lifecycle Management tool that helps them generate, monitor, and distribute SBOMs while staying compliant with their industry’s regulations. (Once again, Vigilant Ops is a great option for SBOM Lifecycle Management.)
For ongoing news, guidance, and updates regarding SBOMs, security leaders can reference the National Telecommunications and Information Association.
Back to Top
Although SBOMs are currently being adopted by highly regulated industries like healthcare, finance, energy, and government they are expected to become a common security standard across industries—as a critical step towards software supply chain security.