Software Build of Materials For Cloud Native applications
A quick introduction to software bill of materials. What is it, why is it important, and how might that impact how we think about cloud native applications.
Talk from Kubernetes Community Days UK in September 2021.
A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build a given piece of software and the supply chain relationships between them.
providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website; Published on May 12th this year, the US executive order has lit a fire under long running discussions about Software Bill of Materials (SBOM). It mandates: The NTIA is responsible for several of the actions from the order, and has been running a multi-stakeholder process on Promoting Software Component Transparency for the last several years. www.ntia.doc.gov/SoftwareTransparency The current focus is setting minimum elements for a SBOM that meets the basic user needs. Why now?
2. Storing SBOMs OCI BOM-REPO-SERVER COSIGN Some interesting work going on here, but everything is early. Lots of opportunities to get involved and build useful/interesting stings. Less examples of at-scale SBOM storage in the real world.
Work to do (get involved!) There are nearly no good libraries with classes/types for SPDX or CycloneDX. If you’re building something today you’re going to be building your own clients. Accurate SBOM generation is hard. It needs to be maintained as part of upstream package management tooling. Instead we’re seeing lots of standalone and overlapping tooling. Too much of the conversation ends at generation. SBOMs aren’t the goal, they are a means to an end. More talk and tool building around consumption is needed. $ Upstream generation Client libraries Tools to consume SBOMs