As threat actors aim at IT supply chains, enhanced cybersecurity has been the recent driving force for industry adoption of the Software Bill of Materials (SBOM) framework.
With a simple list of components that make up a software product, SBOMs enhance transparency between software buyers and sellers, provide the necessary visibility to identify vulnerabilities, and enable rapid incident response. SBOMs directly address inefficiencies in the software development process that lead to a visibility gap between clients relying on the software’s functionality and the developer or supplier’s knowledge of its build and source components.
SBOMs also offer protection against licensing and compliance risks associated with SLAs with a granular inventory of software components. In considering the potential efficacy of SBOM adoption, there’s no downside to standardizing software supply chain practices when it mitigates critical IT, business, and third-party risks and reduces an organization’s bottom line.
This article looks at software bills of materials, file data, existing standards, benefits, use cases, and what SBOMs mean for cybersecurity.
Jump to:
- What is a Software Bill of Materials (SBOM)?
- What’s in a SBOM File?
- Need for Standardization
- The Vulnerability-Exploitability eXchange (VEX)
- Advantages of SBOM Adoption
- How to Create a SBOM
- Proof of Concept: Healthcare SBOM
- What SBOMs Mean for Cybersecurity
What is a Software Bill of Materials (SBOM)?
A software bill of materials (SBOM) is a machine-readable inventory of components, dependencies, metadata, and the hierarchical relationship for a given software product. With a universe of open source and proprietary components, SBOMs provide transparency by identifying risk-prone elements or later deemed vulnerable to attack.
The SBOM framework is about the units of software identified by developers and suppliers known as components and associated data known as attributes. In its entirety, a software product is the primary component and often contains multiple upstream components, with SBOM entries for each to form a collective file.
Software Shoppers’ Nutrition Label
Like looking at a nutrition label in the grocery store, organizations can use SBOMs to evaluate a product’s source code before making a purchase. When the grocery shopper’s physician later informs them of a new allergy or health issue, it’s on the patient to look back and throw out those food items.
In the case of software components, exploitable vulnerabilities are identified regularly and require priority remediation. Without the equivalent of a nutritional label for software in use, organizations would find it difficult to address vulnerable systems. Threat intelligence can help scan IT environments for the latest malware, but that’s just one security layer against zero-day threats.
Read more: Supply Chain Flaws Found in Python Package Repository
The Problem with Software Supply Chains
Given all software contains vulnerabilities, understanding the components of the code being purchased, used, or built is increasingly critical to preserving the integrity of IT environments.
There is no such thing as an ironclad risk-averse software management strategy; therefore, organizations must strive to be risk-aware. In the new millennium, the rise of Agile programming methodology means shorter development cycles and more frequent application deployments, which also translates to a heightened risk of unstable releases. Add the mixing of open source and proprietary software components into solutions, and the software supply chain is understandably complex.
With the sheer volume of development taking place, organizations must take a more aggressive approach towards managing third-party risk.
SBOM Use Cases
The predominant use cases for SBOM are its application to supply chain vulnerability management and product integrity assurance processes.
Vulnerability Management
Because vulnerabilities exist, arise, and linger – downstream organizations must consider software supplier risks. SBOMs’ inventory of components makes identifying specific vulnerabilities a far easier task. With the adoption of VEX files, organizations can be precise in confirming a vulnerability’s exploitability status and promptly remediate critical vulnerabilities.
Product Integrity
More transparency means more informed buyers and sellers and products with high levels of certainty in their effectiveness. Assurance in the source and integrity of software components is critical to improving the cybersecurity ecosystem and SBOMs give organizations more visibility and control regarding software licensing and entitlement tracking.
Also read: How to Defend Common IT Security Vulnerabilities
What’s in a SBOM File?
Though a few formats are gaining traction, there isn’t one universally accepted SBOM structure. The National Telecommunication and Information Administration (NTIA) admits the currently proposed baseline component attributes are purposely basic, with room for continued development and specific twists depending on the industry. The NTIA Software Component Transparency Framing Working Group stated:
“This is one of the major drivers for establishing such a basic set of information as a starting point, rather than initially requiring a more robust set of attributes that may require more time and resources to collect and maintain.“
The Proposed Baseline Component Attributes
| Author Name | The author of the SBOM (e.g., developer, supplier, GRC, third-party) |
| Timestamp | Date and time of initial creation and last updated |
| Supplier Name | Identifying information of the developers and suppliers of a component |
| Component Name | Name of component or list of multiple component names |
| Version String | Component version information with a versioning scheme |
| Component Hash | Cryptographic hashes or digital signatures of component data |
| Unique Identifier | Additional data related to component’s place in the unique hierarchy |
| Relationship | Enumerates existence of upstream or downstream dependencies |
Some attribute data may require multiple inputs like supplier names, while other fields may not be fillable by the SBOM file author based on their visibility. In the latter case, the author should assert whether the field data is unknown, doesn’t exist, is partially known, or known.
Other potential attributes to consider include usage info, licensing, end-of-life dates, third-party notices, component clusters, and how components affect downstream systems. In any instance, cryptographic authentication of SBOMs is imperative for verifying their authenticity.
The Importance of Component Relationships
Whether it’s open-source, proprietary, or a combination, the components that merge into today’s software and their relationships impact organizations’ bottom line. Starting with the primary component, developers and suppliers can define upstream component relationships that pertain to the product’s supply chain history.
Also read: Multi-Party Cyberattacks Lead to Big Losses
In the following graphic, NTIA provides a conceptual example of charting relationships for a software application. In this example, the SBOM contains four components: the primary component and three upstream components. Though additional components may exist beyond these four, SBOM authors must work with existing knowledge. As seen in the flow chart and table, SBOMs can capture an image of component details and their relationship in the software supply chain.
Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), 2nd ed., 2021, p. 16.
Need for Standardization
SBOMs need to follow industry-accepted formats that allow interoperability between different industries and organizations to make adoption a reality. With a few standards already in place, organizations have the framework to write, maintain, and share software component data quickly.
SPDX: Software Package Data Exchange
Developed by the Linux Foundation in 2010, the Software Package Data Exchange (SPDX) is the leading open standard for SBOM formats. SPDX files include software components, copyrights, licenses, and security references.
The SPDX specification fits the NTIA proposed minimum standard for an SBOM and use cases for vulnerability scanning, license compliance, and more. With SPDX Lite, organizations can utilize a compact subset of the SPDX standard for exchanging data. In August 2021, the SPDX became an official standard as ISO/IEC 5962.
SWID: Software Identification Tagging
Towards the end of the 2010s, the International Organizations for Standards (ISO) began developing a standard for tagging software components with machine-readable IDs. Software Identification (SWID) Tags, as they’re now known, are the structured embedded metadata in software that communicates software product name, version, developers, relationships, and more.
Like software asset management (SAM), SWID Tags can help automate patch management, software integrity validation, vulnerability detection, and allowing or blocking software installations. ISO/IEC 19770-2 was confirmed in 2012 and updated in 2015.
OWASP’s CycloneDX
The OWASP Foundation designed CycloneDX as a part of its open-source software component analysis solution, Dependency-Track, in 2017. With use cases like vulnerability identification, license compliance, and analyzing outdated components, CycloneDX is a lightweight standard for multi-industry use. The fourth iteration of CycloneDX (1.3) was released in May 2021.
Read more: OWASP Names a New Top Vulnerability for First Time in Years
The Vulnerability-Exploitability eXchange (VEX)
Developed by the NTIA, the Vulnerability-Exploitability eXchange (VEX) offers an affirmation about the status of specific vulnerabilities in software products. By issuing a VEX, software suppliers inform clients of specific vulnerabilities that might not be exploitable. Examples of different non-exploitable vulnerability statuses include:
| Vulnerability Status | Description |
| Fixed | Product version resolves a specific vulnerability |
| Known, Affected | Action required to address this vulnerability |
| Known, Not Affected | No action required |
| Under Investigation | Unknown vulnerability impact; vulnerability still in evaluation |
Like an SBOM, the VEX format offers a framework for more transparency between software stakeholders. For enterprise organizations, VEX is also machine-readable provides for mass intake and automation of software component vulnerability management.
Advantages of SBOM Adoption
Software bills of materials are beneficial to any organization that values mitigating additional risk and best cybersecurity practices. Vendors in vulnerability management, third-party risk management, and software composition analysis are already integrating SBOM services to assist organizations in the transition.
- Streamline information sharing about software components and vulnerabilities
- Share a product SBOM with ease via common data files (json, xml, html, pdf, or txt)
- Enhance supply chain integrity with more informed developers, vendors, and clients
- Prompt rollout and rollback of crucial patches and remediation steps
- Improved record-keeping for software audits and regulatory compliance standards
- Enhanced visibility into operational software, components, and system relationships
How to Create a SBOM
Software bills of materials should be living records updated to provide the most precise visibility into the source code components at play. For managing SBOMs, organizations first must identify pertinent software inventory items like unsafe info, vulnerabilities, licenses, and versions.
- Collect component data, enumerate attribute data, and create the SBOM
- Complete initial refinements before producing the primary component file
- Review and finalize the file for release to stakeholders and prospective clients
- Monitor integrity of the file, remediate identified alterations, and update the file
Though U.S. federal contractors will be the first required to create SBOMs, advocates have a global vision for including them in the software development process. As the existing standards become more popular, making an adjacent SBOM for each new software component will become best practice. The result will be a more robust ecosystem built on transparency.
Read more: Attackers Exploit Flaw that Could Impact Millions of Routers, IoT Devices
Proof of Concept: Healthcare SBOM
In October 2019, the NTIA published Phase I of its initiative to develop an SBOM Proof of Concept for software component transparency. Medical device manufacturers (MDM) producing SBOMs for use by healthcare delivery organizations (HDO) led the charge, and the result has been a foundation for continued development.
Two years later, the NTIA completed Phase II. In findings published earlier this month, Phase II validated the accepted baseline elements and SPDX, enumerated standard software components and a How-to Guide for producers, and explored VEX use cases. Phase III goals include driving adoption across the healthcare sector, automating SBOM exchange, and addressing end-of-life products and services inefficiencies.
What SBOMs Mean for Cybersecurity
Among information security’s objectives (Confidentiality, Integrity, and Availability), software bills of materials best address preserving the integrity of organization data and systems. As a formal document about software in use or development, the software component files can present added risk in safeguarding proprietary secrets. Likewise, an SBOM doesn’t directly affect the availability of data.
SBOMs offer an industry precedent that expands transparency between developers, software vendors, and clients. With standards in place, organizations can securely inform partners of source code details during the contracting process. As SBOMs become more mainstream, organizations will have a more assertive posture to identify bugs, vulnerabilities, and zero-day threats. For cybersecurity professionals globally, SBOM adoption is a clear win.
Also read: Kaseya Breach Underscores Vulnerability in Managed IT
