Software bill of materials (SBOM): Syft, CycloneDX, Grype
You produce SBOMs for your apps and images, use them to answer new vulnerabilities in seconds and document with VEX which ones don’t affect you.
Level 301 · 15 lessons · 12 practice labs
Lessons
What an SBOM is
- Why an SBOM is needed: software’s ingredients label
- Formats: CycloneDX and SPDX
- SBOM fields: component, version, purl, hash
- SBOM requirements and expectations worldwide
- Short task: pick the risky components out of a ready SBOM
Producing
- SBOMs from source code with Syft
- SBOMs from container images with Syft
- Producing an SBOM at build time and attaching it to the image
- SBOM quality: missing and wrong components
- Short task: attach an image’s SBOM in the local registry
Using
- Scanning an SBOM for vulnerabilities with Grype
- When a new vulnerability lands: which apps are affected
- VEX: the documented way to say “not affected”
- Building and querying an SBOM store
- Capstone: trace a critical vulnerability across ten services’ inventories in an hour
Practice labs
- Read the component fields in an SBOM: Find a component’s name, version, purl and hash in a CycloneDX file.
- Pick the risky components out of a ready SBOM: Use jq to filter components that are unmaintained, lack a version or carry a problematic licence.
- Compare CycloneDX and SPDX output and choose by requirement: Compare field by field the same project’s SBOM in both formats and justify which you deliver given customer expectations in different countries.
- Produce an SBOM from source code with Syft: Generate a CycloneDX SBOM from the project directory and state the component count.
- Produce an image’s SBOM and attach it in the local registry: Extract an SBOM from the image with Syft, attach it as an artefact alongside the image and pull it back from the registry.
- Find and fix missing and wrong components in an SBOM: Show that a vendored library and a statically linked component are absent from the SBOM and close the gaps by generating at build time.
- Scan an SBOM for vulnerabilities with Grype: Scan the SBOM file and list the components with critical findings.
- Find which apps a newly announced vulnerability affects: Search five apps’ SBOMs for the affected component and version range and list those affected.
- Write a VEX document for a product that is not affected: Prove the vulnerable code is never called, produce a justified VEX document and show the scan now suppresses that finding.
- Organise SBOM files by product and version: Place ten SBOMs into directories with consistent naming and create an index file.
- Write a script that queries the SBOM store: Write a script that lists the products containing a given package name and version.
- Trace a critical vulnerability across ten services in minutes: Query the store, extract affected services with versions, apply VEX statuses and produce the list that goes to the owners.
About this course
You produce SBOMs for your apps and images, use them to answer new vulnerabilities in seconds and document with VEX which ones don’t affect you.
What you will learn
- What an SBOM is
- Producing
- Using
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.