In the United States, the Cybersecurity and Infrastructure Security Agency (CISA) has been working to promote Software Bill of Materials (SBOM) standards and adoption since 2018.
CISA's focus is operationalizing and scaling SBOM usage by sharing tools, recommending technologies, and describe use cases. At the same time CISA has been iterating on the underlying requirements to fit the next adoption phase.
Last week, CISA published Framing Software Component Transparency, 3rd Edition to help drive this next phase forward.
Background
After a sharp rise in software supply chain attacks that affected multiple federal agencies, NTIA and then CISA took on the task of improving transparency in software supply chains. CISA recognizes that limited visibility into these supply chains leads to higher cybersecurity risks, increases technology maintenance costs, and encourages focusing on speed over security. In 2018, the NTIA teamed up with industry and community partners to make software supply chains more transparent, aiming to reduce risks, costs, and the time needed to handle cybersecurity incidents. Recommendations for Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) have come out of these collaborative working groups.
Framing Software Component Transparency
The first edition of Framing Software Component Transparency came out in 2019, followed by the second in 2021.
The SBOM Tooling and Implementation Working Group has been responsible for the Third Edition. This group aims to develop a model for software component information that can be shared openly across industries.
In this model, the Software Bill of Materials (SBOM) is the key artifact—it lists a software’s components, includes ownership details, and shows how components are connected.
Third Edition Changes
The software naming problem - ability to uniquely identify a software or component within the SBOM - is one of the core challenges in processing SOM. The Third Edition's primary focus is to recommend practices that help address this challenge.
To achieve this, it focuses on -
1. Declaring a required minimum set of Baseline Attributes necessary to identify Components with sufficient relative uniqueness
2. Identifying supplemental, optional Attributes and external elements beyond the baseline set to serve a variety of SBOM applications and
3. Enabling correlation of SBOMs with external sources for relevant analysis
Component Baseline Attributes
This edition focuses on defining mandating Baseline Attributes for component identification.
A component attribute maturity level is also specified for organizations/tools that aim to provide additional details to meet more comprehensive requirements.
These maturity levels are:
- Minimum Expected
- Recommended Practice
- Aspirational Goal
The list of baseline attributes is as follows, along with their minimum and recommended detail:
- SBOM level Attributes
- Timestamp
- Type
- Primary Component
- Component level Attributes
- Component Name
- Version
- Supplier Name
- Minimum: If the component is unmodified, use the upstream supplier name else, replace it with the primary component’s supplier
- Unique Identifiersome text
- Recommended: At least one unique identifier for each component
- Minimum: As many globally unique identifiers as available for each component
- Cryptographic Hashs
- Recommended: At least one secure hash and its algorithm for the primary component
- Minimum: At least one hash and its algorithm for any component if knowable
- Relationships
- Recommended: Relationships and their completeness for all included components
- Minimum: Relationships and their completeness for the primary component and its direct dependencies
- License
- Recommended: License information for as many as possible
- Minimum: License information for the primary component
- Copyright Notice
- Recommended: Copyright notice for as many as possible
- Minimum: Copyright notice for the primary component
In addition, this edition clarifies how to handle scenarios when the data needed to complete the SBOM is unknown, unavailable, or cannot be declared.
Unknown Component Attributes
An unknown attribute should be handled with
- Using the value “no assertion” (i.e., data is missing) differently from the value “no value” (i.e. the Attribute is not applicable for this specific SBOM).
- After all reasonable efforts to eliminate “no assertion” from the Baseline Attributes.
Redacted Components
If a component requires redaction, it must continue to preserve the component version and cryptographic hashes along with its dependency relationships.
Unknown Dependencies
If an SBOM contains known unknown dependencies, the relationship completeness fields must be used to declare each component's state of completeness.
Supplemental Information
The third edition clarifies extending SBOM to support additional use cases by providing supplemental information such as -
- End-of-life data or level-of-support for components
- Indication of what technologies a Component implements or supports
SWID Removed
In another major change, the third edition removed SWID from the recommended format and updated mapping for the remaining SPDX and CycloneDX formats.
Conformance with Third Edition
sbomqs - Interlynk's open source multi-specification SBOM utility has been updated to check for SBOM conformance with the third edition. With the build version 0.2.2 or later, sbomqs can break down SBOM's compliance along the lines of
- score for each field on completion
- percentage completion of specific baseline attribute
- maturity level of baseline attribute - None / Minimum / Recommended
With the command - sbomqs compliance -f sbom.cdx.json --color
Summary
CISA remains committed to software transparency and the SBOM working groups are helping standardize and operationalize SBOM to improve software risk transparency. The third edition of Framing Software Component Transparency includes practical guidance for SBOM tool builders and operators to ensure consistency in SBOM generation and real value extraction from such SBOMs.
At Interlynk, we advance our open source tools and platform capabilities as the specifications are clarified. Interlynk's open source utilities such as sbomqs and sbomasm as well as Interlynk's free SBOM management platform - https://app.interlynk.io/ remain the most trusted and up to date utilities for working with SBOM.
