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.

Transcript

1. Software Build of Materials For Cloud Native applications September 2021
2. Gareth Rushgrove VP Product, Snyk Occasional open source contributor, Open Policy Agent Conftest creator, Devops Weekly curator.
3. 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.
5. But why? - Export compliance - Open source license compliance - Audits - Vulnerability management - EOL awareness - High assurance systems - Search/visibility - Process improvements - Research Intellectual property management Software supply chain security Asset management
6. 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?
7. Software Supply Chain frameworks SLSA SCIM SCVS
8. Emerging standards CYCLONEDX SPDX
9. Components of an SBOM Supplier name Component name Component version Other unique identifiers Dependency relationship Author of SBOM data Timestamp "components": [ { "type": "library", "bom-ref": "pkg:maven/com.fasterxml.ja "publisher": "FasterXML", "group": "com.fasterxml.jackson.core", "name": "jackson-annotations", "version": "2.9.10", "description": "Core annotations used "hashes": [ { "alg": "MD5", "content": "26c2b6f7bc704ccadc64c8 },
10. 1. Generating SBOMs <plugins> <plugin> <groupId>org.cyclonedx</groupId> <artifactId>cyclonedx-maven-plugin</artifactId> <version>2.5.2</version> </plugin> </plugins> $ ./mvnw cyclonedx:makeAggregateBom $ tern report -i golang:1.12-alpine $ syft golang:1.12-alpine github.com/tern-tools/tern github.com/anchore/syft github.com/CycloneDX/cyclonedx-maven-plugin
11. 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.
12. Enforce policy 3. Consuming SBOMs SBOM Check for license issues Search “Tell me where we use OpenSSL” Check for vulnerabilities ...
13. DEMOS
14. 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
15. Thanks Any questions let me know @garethr