CISA’s SBOM Minimums: Breaking Down the 6 Types

Table of contents

The below blog covers CISA’s new SBOM minimum requirements. For greater detail about SBOM management expectations, see Whiplash: Turning SBOM Guidelines from Text Books into Playbooks.

—-

The last years have seen product security teams worry about how to generate, manage, and encorporate Software Bills of Materials into actionable documents. However, just as Chief Product Security Officers (CPSOs) began to wrap their head around what SBOMs can really do, they got slammed with:

Attestation forms
New CISA SBOM Minimums
IMDRF SBOM guidelines
And other guidelines from the Omnibus bill

Up until now, it has been a bit of a wild goose chase to have an ‘acceptable’ SBOM since there was no standard. ‘Acceptable’ was relative to how much information the purchaser or end user needed to know about the software components within a device.

As many companies took it up on themselves to generate SBOMs, many were unclear about what to do with them in practice due to their lack of standardization.

So, when the new Minimum Guidelines were released, product security teams had a point of truth to point to, turning industry insights into a foundation for a device security roadmap.

CISA’s 6 SBOM types

CISA’s recent Types of Software Bill of Material (SBOM) Documents, breaks down the six SBOMs that are required for each device, when each should be created, its benefits, and its limitations.

Breaking down the SBOM Design

A hypothetical list of software components intended for a future project. Once compiled, teams can check potential vulnerabilities and adjust accordingly.

Breaking down the SBOM Source

A Source SBOM is based on the development environment. It is only a snapshot of the project’s current status.

Breaking down the SBOM Build

Type 3 SBOMs contain components that are likely to remain throughout the device’s life. They are critical in vulnerability identification.

Breaking down the Analyzed Software Bill of Materials

As the project moves closer to its final stage of development, an analyzed SBOM can be optimized by a third party to gain a holistic picture through analysis and artifacts.

Breaking down the Deployed SBOM

Type 5 SBOMs can begin taking in configuration variations and examining the true use of the product in the field.

Breaking down the SBOM Runtime

Entering the age of dynamic SBOMs, this product will experience updates for years to come. With development far behind it and deployment a distant memory, the SBOM must remain up to date and continuously reflect all post-production updates.

Are 6 SBOMs better than one?

Now that the initial shock has passed, these six distinct SBOMs refer more to stages of a device’s lifecycle than it is about generating new bills every time– as long as automation is prioritized.

See, these multiple SBOMs are a given for those who already implement SBOM management into their product security workflow. Others, who don’t automatically generate, update, and approve SBOMs will struggle to manually generate a new bill of materials every time a software component is added, removed, updated, or mitigated. Not only will they struggle due to the resource-intense nature of understanding all, but as companies attempt to manually generate moves from Type 1- Design through Type-6 runtime they’ll find an increasingly complicated device that has new dependencies, complications, and vulnerabilities.

Implementing automation processes go beyond generation to SBOM management. By ensuring a living document that can be relied on by all stakeholders in real-time, PSIRT teams can call upon the SBOM without having to question its accuracy.

Instead of needing to generate SBOMs at specific points, The Product Security Platform allows you to take the live SBOM and decide that the team is ready for the next phase, labeling everything after a specific date as Type 1, Type 2, etc.

Why Product Security Should be of Importance to All Company Stakeholders

There’s now way around it. Standards, regulations, and legislation now dictates that device security is a company problem, not just the security team’s.

Turning that into action requires product, security, and research teams to come together to delegate what is expected of each throughout the development stage through deployment and beyond. Managing 6 SBOMs per device requires product security teams to work with developers from the start of a project to ensure a security-first approach that includes documentation. From the very beginning, developers need to plan to generate and manage SBOMs on an ongoing basis.

Once this is implemented, product security tools can be used to take these SBOMs and generate VEX documents, conduct vulnerability management activities, and deliver a product of higher quality.