CISA Releases Guidance on Minimum Expectations for Software Bill of Materials

On October 15, 2024, the U.S. Cybersecurity and Infrastructure Security Agency ("CISA") published software bill of materials ("SBOM") guidance through the third edition of Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) (dated September 3, 2024) (the "Guidance"). The Guidance provides "a minimum expectation for creating a baseline SBOM." As CISA has noted, "[an SBOM] has emerged as a key building block in software security and software supply chain risk management." SBOMs are defined by CISA as "a formal record containing the details and supply chain relationships of various components used in building software."

In light of the Government's increasing interest in the use of SBOMs, both as evidenced through the reference to a requirement for SBOMs in the proposed Federal Acquisition Regulation ("FAR") Cyber Threat and Incident Reporting and Information Sharing Rule (discussed here) and in the Office of Management and Budget's Secure Software Development Framework (discussed here), the Guidance could help inform future SBOM minimum requirements for government contractors as well as the broader software supplier community.

Developing practices to ensure the security of the software supply chain has been a focus of the Executive Branch for a number of years. In 2019, the National Telecommunications and Information Administration ("NTIA") published the first edition of Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM). NTIA built upon this guidance in 2021 when it released the second edition of Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM). Earlier that same year, the Biden Administration published an Executive Order on Improving the Nation's Cybersecurity, which tasked the Secretary of Commerce to provide guidance regarding practices that strengthen software supply chain security which included "publish[ing] minimum elements for an SBOM." Subsequently, in July 2021, NTIA published The Minimum Elements For a Software Bill of Materials (the "Minimum Elements").

Three years later, CISA published the third edition of Framing Software Component Transparency. Although CISA noted there is a distinction between the Guidance and the Minimum Elements, CISA also stated that it retains "the authority to update the [Minimum Elements]." One of the key additions to the third edition is the inclusion of maturity levels for various Attributes-the Guidance identifies practices as minimum expectations, recommended practices, or aspirational goals (for the purposes of brevity, this overview focuses on the minimum expectations). The Guidance further introduces the license and copyright holder Baseline Attributes, among other changes.

1. SBOM Meta-Information Attributes
   • Author Name: This should reflect the SBOM data creator's name (which may not be the supplier). At a minimum, the "SBOM must list the entity that prompted the creation of the SBOM."
   • Timestamp: This should reflect the production date and time of the SBOM. At a minimum, "the Timestamp should be consistent across time zones and locales and use a common international format."
   • Type: This should reflect the context in which the SBOM was created. This Attribute is listed as an aspirational goal (optional).
   • Primary Component (Root of Dependencies): This should reflect the SBOM's subject. At a minimum, the Primary Component should be declared.
2. Component Attributes
   • Component Name: This should reflect, as defined by the Component's Supplier, the Component's public name. At a minimum, the commonly used public name should be declared.
   • Version: This should indicate any software changes from a previous version. At a minimum, the version string should be declared.
   • Supplier Name: This should reflect the creator of the Component. At a minimum, "the Supplier Name should be declared for all Components."
   • Unique Identifier: This should reflect "additional information to help uniquely define a Component," such as a SWID Tag (Software Identification). At a minimum, each Component should have one unique identifier.
   • Cryptographic Hash: This should reflect "an intrinsic identifier for a software Component." At a minimum, any known hash or a hash that can be generated based on available information should be provided for SBOM Components. The hash algorithm should also be provided for reproducibility purposes (MD5, SHA1, and SHA2 are accepted, although the former two are not recommended).
   • Relationship: This should reflect "the association of a Component listed within the SBOM to other Components." At a minimum, the relationships and relationship completeness for the Primary Component and direct Dependencies should be declared. The types of relationships include primary, "included in," heritage or pedigree, and relationship completeness.
   • License: This should reflect the corresponding legal terms for the Component. At a minimum, this should be provided for the Primary Component.
   • Copyright Notice: This should reflect "the entity that holds exclusive and legal rights to the listed Component in the SBOM." At a minimum, this should be provided for the Primary Component.
3. Undeclared SBOM Data
   • Unknown Component Attributes: The Guidance offers as "[a] basic recommendation," that one should "always provide all of the Baseline Attributes," but clearly delineate between values where the data is missing and where it is not applicable. At a minimum, a Baseline Attribute should be declared "no assertion" or "no value" when necessary due to time constraints.
   • Redacted Components: This category applies when contractual obligations prohibit disclosure of the software's inclusion. At a minimum, redaction should occur only when contractually required.
   • Unknown Dependencies: This category applies when it is known that there are Dependencies, but the Dependencies themselves are unknown. At a minimum, "[e]very Direct Dependency to the Primary Component" should be declared. "Deeper Dependences may be declared as unknown when necessary."