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 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 Design SBOM
Breaking down the Source SBOM
Breaking down the Build SBOM
Breaking down the Analyzed SBOM
Breaking down the Deployed SBOM
Breaking down the Runtime SBOM
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.
Turning SBOM overwhelm into action
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.