On Friday, Jan 26, CISA issued guidance on SBOMs that cover product lines, aimed at software producers, to shed light on the creation of Build Software Bill of Materials (SBOM) for assembled products, emphasizing the significance of tracking evolving components within the rapidly changing realm of technology.
We specialize in product security here at Finite State, so let’s break it down!
Unraveling the Jargon: Product Line Build SBOMs
For years, since the SBOM concept has caught on, physical product companies have been struggling with what goes into their SBOMs. The recent guide introduces the concept of a "Product Line Build SBOM" or "PLB-SBOM" for such assembled product collections.
This terminology is inclusive of various products like Embedded and Internet of Things (IoT) devices, personal computers, servers, and software releases incorporating integrated components.
The Essentials of PLB-SBOM Creation
Currently, most device manufacturers generate multiple SBOMs for one assembled product, or attempt to leverage new standards like CycloneDX v1.5 to combine as much data into a single SBOM as possible.
This new advice and guide lays out a systematic approach for describing a product line with a build SBOM. The guidance shows that device manufacturers should create a “high level” PLB-SBOM for each version of their product that references separate SBOM documents for each part of their product, instead of combining all of the SBOMs together into one document. This enables manufacturers and consumers of their SBOMs to track the changes in the subcomponents of a product independently.
The guidance emphasizes the following required information:
- Identifier Selection: Determining a unique identifier for the product line.
- Versioning System: Defining a versioning system associated with the chosen identifier.
- Component Listing: Exactly like other SBOMs, enumerating all components distributed together as a group.
- Version Numbers: Assigning version numbers to each component.
- Build SBOM Reference: Providing a reference to the build SBOM that generated each component image included in the product group as part of the PLB-SBOM.
Recommended Practices for Comprehensive Security
In addition to the required information, the guide suggests several recommended practices to enhance cybersecurity measures:
Artifact Hashing
Each artifact associated with a component should have a hash, so that stakeholders using the PLB-SBOM can use it as a cross-check for drift. End users can diff the artifacts to see the changes and impacts, and decide if any updates are acceptable.
Examples of artifacts that would benefit from a hash include tarball, zipfile, container image, install package, disc image, and source file. These individual artifacts can greatly impact a product line’s security, and providing a consistent hash across versions helps assure customers that supply chain attacks are less likely.
Identifiers Inclusion
Product companies should add any available identifiers (PURL, CPE, SWID tags) for the product component when appropriate. At Finite State, we prefer to use PURL and CPE as our primary identifiers.
Authorship and Maintenance
The advice stipulates that the author of the PLB-SBOM data should be the entity releasing the product line (in most cases, the manufacturer of the product line). This is helpful, because in the past some SBOMs have used the component creator/maintainer as the “author,” and some have used the name of the SBOM generation tools as the author. This clarification helps product companies put their names on their product lines.
Additionally, advocating for regular maintenance of the PLB-SBOM as updates to the product components are applied is helpful and key. As physical products have longer shelf lives than some smaller software-only products, and could exist in environments for years into the future, having maintained PLB-SBOMs with up to date component data and version data helps any customer to better understand their risk.
Strengthening Product Security
The publication of the advice for PLB-SBOMs is a great sign that product security and embedded device security are finally becoming top-level concerns for industry and governments. As a leader in the product security space, Finite State has been working on some of these tricky problems and we’re thrilled to see more advice and dialogue around this space.
Seeing the community dialogue around PLB-SBOMs aligns with our broader industry goals of enhancing transparency, traceability, and accountability in the software supply chain. By implementing these practices, software producers can fortify their systems against vulnerabilities, ensuring a proactive defense against emerging threats.
