Gnu Group Learning AcademyGnu Group ↗
DevSecOps Fundamentals · Module 05 of 12

SBOM generation and component inventory

Create and reason about software bills of materials so releases have a durable component inventory that can be rescanned later.

Learning objectives

By the end of this module, you should be able to:

  • Explain what an SBOM records and what it does not prove.
  • Distinguish SPDX/CycloneDX-style inventory from vulnerability results.
  • Tie an SBOM to an immutable artifact digest and release.

SBOM is inventory, not a security verdict

An SBOM records components and relationships. Vulnerability status changes over time, so the same SBOM can be rescanned against newer intelligence.

Bind inventory to the artifact

Store the image/file digest, build identifier and SBOM together. A detached inventory with no artifact identity is weak evidence.

Formats support interchange

SPDX and CycloneDX are common SBOM formats. Choose based on ecosystem and downstream consumers, not fashion.

Worked example

Artifact identity

artifact digest → SBOM → vulnerability scan → release evidence
Same digest + same SBOM can be re-evaluated later as advisories change.
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 05 — Validate a minimal SBOM

Goal: Check that an inventory has components and artifact identity.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create SBOM-like document

cat > /tmp/sbom-demo.json <<'EOF'
{"artifact":"sha256:demo123","components":[{"name":"demo-lib","version":"1.2.3"}]}
EOF
STEP 2

Validate fields

python3 - <<'PY'
import json
x=json.load(open('/tmp/sbom-demo.json'))
assert x['artifact'].startswith('sha256:') and x['components'][0]['version']=='1.2.3'
print('SBOM identity/inventory present')
PY
STEP 3

Plan retention

Record where the release digest, SBOM and scan result would be retained together.

Verify

  • Artifact identity is immutable-style.
  • At least one component has a name and version.

Expected outcome

  • The learner can explain why SBOM and vulnerability report are different evidence.

Diagnose / troubleshoot

  • If package versions are missing, improve package discovery before relying on the SBOM.
  • If the SBOM is generated before the final build, regenerate it from the promoted artifact.
Real-world connection

A retained SBOM allows incident teams to answer “where do we use this component?” without rebuilding old releases.

Optional real-tool lab

Optional tool lab — Syft

Generate an SBOM from a directory or approved image.

Prerequisites

  • Install the referenced open-source CLI only for the optional lab.
  • Use an organization-approved pinned version in real CI; do not blindly use latest.

Cost / risk

  • Expected cloud cost: none. Use only approved repositories and disposable training artifacts.

Warnings

  • Never scan or publish real production secrets in a training lab.
  • Scanner output is evidence for triage, not an automatic statement of exploitable risk.
TOOL 1
syft version
TOOL 2
syft dir:. -o cyclonedx-json=/tmp/syft.cdx.json
TOOL 3
test -s /tmp/syft.cdx.json && echo 'SBOM created'
Avoid these traps

Common mistakes

  • Calling an SBOM a vulnerability scan.
  • Generating inventory from a different artifact than the one released.
  • Publishing sensitive file content as SBOM metadata.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What is an SBOM?

A structured inventory of software components and related metadata for an artifact or source.

2Does an SBOM prove there are no vulnerabilities?

No. It is inventory; vulnerability intelligence and context are separate.

3Why retain the artifact digest with the SBOM?

To prove which immutable artifact the inventory describes.

4Scenario: a new CVE is published three months after release. How can an SBOM help?

Rescan the retained component inventory/artifact mapping to identify affected releases without rebuilding them.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.