How SBOMs Protect Google's Massive Software Supply Chain
marketing814989
304 views
27 slides
Sep 17, 2024
Slide 1 of 27
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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...
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 Google catalog thousands of software applications? Brandon Lum, Open Source Security Engineer at Google, and Alan Pope, Director of Developer Relations at Anchore introduce Syft, an OSS tool that helps generate SBOMs for Google’s highly complex and containerized apps.
In this live webinar you will learn:
- Why SBOMs are a necessity for every software company today
- How SBOMs aid in Observability, Security and Compliance
- How Google built 100M SBOMs
- How to avoid potential pitfalls on the way
Size: 2.03 MB
Language: en
Added: Sep 17, 2024
Slides: 27 pages
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