Software Build of Materials For Cloud Native applications September 2021

Gareth Rushgrove 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.

No content

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

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?

Software Supply Chain frameworks SLSA SCIM SCVS

Emerging standards CYCLONEDX SPDX

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 },

1. Generating SBOMs org.cyclonedx cyclonedx-maven-plugin 2.5.2 $ ./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

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.

Enforce policy 3. Consuming SBOMs SBOM Check for license issues Search “Tell me where we use OpenSSL” Check for vulnerabilities ...

DEMOS

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

Thanks Any questions let me know @garethr