How SBOMs Protect Google's Massive Software Supply Chain

marketing814989 304 views 27 slides Sep 17, 2024
Slide 1
Slide 1 of 27
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27

About This Presentation

SBOMs are a detailed inventory that lists all components, libraries, and tools used in creating, building, and deploying software. That’s crucial for a handful of reasons: visibility into dependencies, enhance security, meet compliance and streamline development.

How does a software giant like Go...


Slide Content

How SBOMs protect Google’s massive
software supply chain
Brandon Lum
Open Source Security Engineer
Google
Alan Pope
Director of DevRel
Anchore

Housekeeping
01
02
03
All participant lines are muted
Questions will be accepted throughout, enter questions via Q&A panel
You will receive a follow-up email with a link to the recording
04 Please respond to poll questions as they are appear on your screen

Agenda
Introductions



01
02
SBOMs in Observability, Security and Compliance
03 How Google scaled to Millions of SBOMs
04 Q&A

SBOMs in Observability,
Security and Compliance

SBOMs Start Simple
1.Increased visibility of dependencies

2.Enhanced security posture

3.Minimum requirements for compliance

4.Streamline development

How Google scaled to
Millions of SBOMs

Number of SBOMs (Apr 2024)
650M
~4M SBOMs /
week

Where do we start? YES
Opinionated or not? YES

●Problem scope is HUGE, many moving parts.


●Less is MORE
○1 standard: SPDX SBOMs
○1 storage and retrieval process
○n builders << m products
○etc.
CDX

How to generate SBOMs
Source ArtifactBuild
●Builds are lossy
●Loses context
●Includes tests and plugins
●Ambiguous dependency
resolution
Source SBOMs?? Analysis SBOMs?Build SBOMs??

Too little
information
(Incomplete)
Too much information
(Inaccurate)
Build ArtifactSource
Build time
ArtifactSource
How to generate SBOMs
This is the leverage point

How consumers see Software
gcr.io/abcd

How producers see Software
staging.gcri.io/abcd
(amd64)
staging.gcri.io/abcd
(arm64)
assemble
assemble
staging.gcri.io/abcd
(multi-arch)
promote
gcr.io/abcd
./a.out

Using SLSA to compose SBOMs
gcr.io/abcd
Build 1
Build 2
Build 3 Build 4
SLSA build metadata can be used to glue together lost pieces of SBOMs,
creating more accurate SBOMs by composing them together!
•https://slsa.dev/blog/2022/05/slsa-sbom
•Kubecon: SBOM X-ray Superpowers (Google/Anchore collaboration)

Fleet-wide Insights
Using GUAC + deps.dev, we mapped out fleet-wide dependency
OpenSSF scorecard risks.
Danger zone!

Next Steps
Whitepaper: SBOM and its role in Cybersecurity
https://get.anchore.com/sbom-cybersecurity-whitepaper/

Get started with Syft today and contribute
https://github.com/anchore/syft


Visit our GitHub and Community Discourse
github.com/anchore and https://anchore.com/discourse

Learn more about Anchore Enterprise
https://anchore.com/platform

Manning Book: Securing the Supply Chain Security
Manning Book: Securing the Supply Chain
Security

Authors: Brandon Lum, Michael Liberman

Discount Code: lumanchore

Thank you for joining!



Schedule a demo of our platform @ get.anchore.com/demo-request

BACKUP

What are properties of the SBOMs we
want to strive for?

●Design doc with properties of SBOMs and best
practices to achieve them
○Properties
■Accurate and complete
■Trustworthy (Integrity & Provenance)

●Best practices: more throughout the talk!

How to SBOM
Looking for
SBOMs that are…
Accurate

Complete

Trustworthy

Retrieve Flow

Product OwnerCompliance Officer
Give me SBOMs for
product PixelOS.
I am looking for URI: XYZ
or Hash: sha256:abcd…
Translating request requirements is not easy
-Product mapping to software is HARD
-Effort needs to put into maintaining software inventory

Retrieve Flow

I am looking for
URI: XYZ
or
Hash: abcd…

Product Owner
Compliance Officer
Give me SBOMs for
product PixelOS version
X

Accuracy/Completeness
Source ArtifactBuild
●Builds are lossy
●Loses context
●Includes tests and plugins
●Ambiguous dependency
resolution
Source SBOMs?? Analysis SBOMs?Build SBOMs??

Too little
information
(Incomplete)
Too much information
(Inaccurate)
Build ArtifactSource
Build time
ArtifactSource
Accuracy/Completeness

List of Best Practices
Attaining good quality (accuracy and completeness):
-When possible, generate SBOMs during build time, thus reducing reliance on heuristic derived SBOM information, using metadata instead.
-In the build process, generate the SBOM as close to the build step itself. Ideally by the build tool. However, this is difficult to scale with the number of build tools and ecosystems.
-Therefore, SBOM generation through dependency metadata in the source is a good alternative. However, when doing so, it is important to:
-Ensure all dependencies are fully resolved
-Ensure all dependencies are pinned
-Tie the build artifact to the SBOM information produced through a build attestation (e.g. SLSA).
-When generating SBOMs, include and use good software identifiers
-When generating SBOMs, include information about known unknowns, including their software identifiers
-Provide a means to lookup SBOM and software composition information through software identifiers
-Compose SBOMs to obtain a more complete SBOM.

Showing good quality (integrity and provenance)
-As a minimum, or when contracts of quality are in place:
-SBOM producers should sign their SBOM that can be verified to their organization.
-SBOM consumers should verify the integrity and provenance of the SBOM is that of the SBOM provider.
-If an SBOM makes reference to software provided by a third party, it should reference or include the third party SBOM and propagate any provenance information required to
verify it.
-When there is no trust anchor of quality in place (e.g. open source), or if a consumer has a higher security standard of SBOMs (requiring independent auditing of the quality):
-SBOM information captured should be accompanied by how they were produced (e.g. tooling and method), ideally at the field granularity, such that it provides a way to
evaluate accuracy of the information.
-SBOM information captured should be accompanied by where/when they were produced (e.g. Build-time vs post-build analysis SBOM), ideally at the field granularity, such
that it provides a way to evaluate accuracy of the information
-SBOM documents and fields should be accompanied by verifiable attestations that the tooling ran without being tampered (e.g. SLSA attestations)

Retrieve: Edge cases
“Edge” Cases

-Container images manifest or config change (drift in hashes)
-Promoting images from staging to prod (change in reference)
-CI stages which result in change of hash (e.g. signing APKs)
-Inclusion of binaries which do not provide additional info
-Inclusion of binaries in packages that SCA tools can’t scan (e.g. installables)
Attaining good quality (accuracy and completeness):
-\Compose SBOMs to obtain a more complete SBOM.

Generate; Store; Retrieve;
Store RetrieveGenerate
●Builders, Build tools
●SCA otherwise
●SBOM at every step
●SBOMs attested by
builders
●Store SLSA attestations
●Link with good identifiers
(URIs/hashes)
●Compose SBOMs
recursively using SLSA
●Product teams
maintain software
inventory