Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Build of Materials For Cloud Native ap...

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.

Gareth Rushgrove

September 15, 2021
Tweet

More Decks by Gareth Rushgrove

Other Decks in Technology

Transcript

  1. Gareth Rushgrove VP Product, Snyk Occasional open source contributor, Open

    Policy Agent Conftest creator, Devops Weekly curator.
  2. 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.
  3. 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
  4. 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?
  5. 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 },
  6. 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
  7. 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.
  8. Enforce policy 3. Consuming SBOMs SBOM Check for license issues

    Search “Tell me where we use OpenSSL” Check for vulnerabilities ...
  9. 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