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.
Software Build of Materials
For Cloud Native applications
VP Product, Snyk
Occasional open source contributor, Open Policy
Agent Conftest creator, Devops Weekly curator.
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.
- Export compliance
- Open source license
- EOL awareness
- High assurance
- Process improvements
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
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.
The current focus is setting minimum elements for a
SBOM that meets the basic user needs.
Software Supply Chain frameworks
Components of an SBOM
Other unique identifiers
Author of SBOM data
"description": "Core annotations used
1. Generating SBOMs
$ ./mvnw cyclonedx:makeAggregateBom
$ tern report -i golang:1.12-alpine $ syft golang:1.12-alpine
2. Storing SBOMs
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.
3. Consuming SBOMs
“Tell me where we
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
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.
Client libraries Tools to consume SBOMs
Any questions let me know @garethr