Git, CI/CD & GitOpsLXVIII · SBOMOperationalization
SBOM as an operational input — incident response, license audit, dependency change
What you'll learn
- Diff two SBOMs from two consecutive builds to find the dependency change
- Answer an incident-response question with the SBOM (what changed, what was in, what was deployed)
- Audit the license posture of an artifact against the SBOM
- Recognise the SBOM as the operational inventory that closes the loop between build, deploy, and audit
Prerequisites
Practice
Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x
The SBOM is the inventory of the deployed artifact. The inventory is consumed by three operations beyond vulnerability matching: incident response (what was in the artifact that failed), license audit (does the artifact comply with policy), and dependency change (what the next build will introduce).
Incident response, license audit, dependency change
A production incident triggered a rollback. The team needs to answer: what was in the failed artifact that is not in the last known-good? The answer requires a diff:
syft diff sbom.known-good.spdx.json sbom.failed.spdx.json
The diff command outputs the components added, removed, and changed. The output is the candidate root-cause list: the packages that landed in the failed build but not in the known-good.
flowchart LR
A["Known-good SBOM"] --> C["syft diff"]
B["Failed SBOM"] --> C
C --> D["Added"]
C --> E["Removed"]
C --> F["Changed"]
D --> G["Candidate root cause"]
E --> G
F --> G
Many organisations have an OSS license policy. The SBOM is the input to the audit; the matcher compares the SBOM’s license fields against the policy. The audit pipeline: pull the SBOM from the attestation, extract the license fields, compare against the policy list, emit a per-component decision, and aggregate to the artifact-level decision.
The dependency-change diff is the third operational use: the team proposes a dependency upgrade and asks “what else moves when we upgrade this package?”
syft diff sbom.before.spdx.json sbom.after.spdx.json
The diff shows the transitive movement. Generate the after-SBOM in a PR build, review the diff before merging, and track the dependency-change history.
Production discipline
- Persist SBOMs by digest with a long retention window. The SBOM is the audit trail.
- Index an SBOM diff tool against the SBOM store (the diff is the incident-response primary tool) and run the license audit on every build.
- Block the deploy on non-compliance.
Cross-course references
- Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) is the durable binding that makes the operational queries possible.
Quiz
Knowledge check · 4 questions
Q1. During a production incident, the team needs to identify which package changed between the last known-good build and the failed build. Which SBOM operation is the right primary tool?
Q2. A retroactive license audit is not sufficient evidence for compliance because the SBOM can be regenerated from the source at any time.
Q3. Name the three operational uses of an SBOM covered in this lesson.
Q4. Diagnose why the team cannot answer the audit question and recommend the fix.
Team T deploys a Node service. The CI generates an SBOM with syft and uploads it as a CI artifact with a 30-day retention window. Six months after deployment, a regulatory auditor asks: 'which OSS licenses were in the image?' The team cannot answer; the CI artifact retention has expired.
Passing score: 75%. Answers are checked in this browser.