Why this matters
As a Platform Engineer, you guard the software supply chain. Two core tools help you do it:
- Image scanning finds known vulnerabilities (CVEs) in container images before they reach production.
- SBOMs (Software Bill of Materials) list everything inside an image, enabling audits, impact analysis, and compliance.
Real tasks you will do:
- Block image promotions when a High/Critical CVE is found.
- Generate and store SBOMs for every build to satisfy compliance and speed up incident response.
- Triage CVEs, propose fixes, and document short-term exceptions with expiry dates.
- Answer "Are we affected?" quickly when a new vulnerability is announced by searching SBOMs.
Concept explained simply
Image scanning in one minute
An image scanner looks inside a container image, identifies packages and versions, and checks them against a vulnerability database. It produces a list of CVEs with severities and remediation hints. You then apply a policy (for example, "fail the build if severity ≥ High").
What is an SBOM?
An SBOM is a structured list of components and versions used in your software. Think of it as an ingredient label for your container image. Common formats include SPDX and CycloneDX. An SBOM doesn’t say what is vulnerable; it says what is present. Scanners map CVEs to SBOM components.
Mental model
Two lenses on the same image:
- SBOM = What’s inside? (packages, versions, licenses)
- Scanner = What’s risky? (CVEs matched to those packages)
Pipeline view:
- Build image (pin versions).
- Generate SBOM (store it with the artifact).
- Scan image (enforce policy).
- Report and remediate (upgrade base image or dependencies).
- Track exceptions (time-bound, justified).
Worked examples
Example 1 — Scan result and pass/fail decision
Image: app-backend:1.4.2 Findings: - CVE-2021-1234 (openssl 1.1.1k) Severity: High Fix: 1.1.1u - CVE-2020-9999 (zlib 1.2.11) Severity: Medium Fix: 1.2.13 Policy: Fail on High and Critical. Decision: FAIL (at least one High). Next step: bump base image or update openssl.
Example 2 — SBOM excerpt (CycloneDX-like)
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{"type":"library","name":"openssl","version":"1.1.1k","purl":"pkg:apk/openssl@1.1.1k"},
{"type":"library","name":"zlib","version":"1.2.11","purl":"pkg:apk/zlib@1.2.11"}
]
}Use the SBOM to quickly check if a CVE affects you by matching component name + version.
Example 3 — Simple CI policy gate (pseudocode)
scan_results = run_image_scan("app-backend:1.4.2")
if scan_results.max_severity in ["Critical", "High"] and not has_valid_exception(scan_results):
fail_pipeline("Blocking due to High/Critical vulnerabilities")
else:
proceed()Exercises
Do these now. They mirror the exercises below the lesson.
Exercise 1 — Decide pass/fail and remediation
Given the scan snippet:
Image: payments-api:2.0.0 Vulnerabilities: - CVE-2022-1111 | libssl | 1.1.1k | High | Fixed in 1.1.1u - CVE-2023-2222 | curl | 7.74.0 | Medium | Fixed in 7.88.1 - CVE-2019-3333 | busybox| 1.31.1 | Low | N/A Policy: fail on High and Critical.
Tasks:
- Pass or fail?
- List the exact remediation steps.
- If you must ship today, draft a minimal, time-bound exception note.
Exercise 2 — Draft a minimal SBOM snippet
Create a minimal CycloneDX-like JSON with these components:
- alpine-base 3.18 (type: container)
- openssl 1.1.1u (library)
- curl 7.88.1 (library)
Include a unique bom serial number (any UUID-style string) and component entries with name, version, and type.
Checklist — Make this real at work
- Define a clear policy threshold (e.g., fail on High/Critical).
- Generate an SBOM during build and store it with the image (e.g., in the registry as an attached artifact).
- Add an image scan step in CI and block merges on policy failures.
- Require time-bound exceptions with a ticket reference and auto-expiry.
- Schedule periodic re-scans of images already in registry.
Common mistakes and self-check
- Only scanning base images. Self-check: Are app dependencies also scanned?
- Ignoring language-level packages. Self-check: Does scanning include OS and app packages?
- Not storing SBOMs. Self-check: Can you answer "where is openssl 1.1.1k used?" in minutes?
- Permanent allowlists. Self-check: Do exceptions expire automatically?
- Unpinned versions in Dockerfile. Self-check: Are base images pinned by digest?
- Policy drift between teams. Self-check: Is there a single documented policy in CI?
Who this is for
- Platform and DevOps engineers adding supply-chain controls.
- Backend engineers who build and ship containerized services.
- Security engineers partnering with platform teams on policy.
Prerequisites
- Basic Docker image knowledge (layers, base images, tags vs digests).
- Familiarity with CI pipelines.
- JSON/YAML reading comfort.
Learning path
- Understand scanning vs SBOM (this lesson).
- Add SBOM generation to your build.
- Add scanning and simple severity-based policy.
- Introduce exceptions with expiry and rationale.
- Scale: store SBOMs, index them, and enable search by component version.
Practical projects
- Project 1: Build once, produce two artifacts — image and SBOM — and push both to the registry. Attach the SBOM to the image as related metadata.
- Project 2: Create a CI job that fails on High/Critical and posts a short report as a pipeline summary.
- Project 3: Write a small script that, given a package@version, searches stored SBOMs and lists affected images.
Mini challenge
Your company policy is "Fail on High/Critical. Medium allowed only if a fix is unavailable." Given a scan shows: one High with a fix available, one Medium with no fix, and two Low. Decide: pass or fail? What immediate action do you take?
Quick Test
Everyone can take the test for free. Only logged-in users get saved progress and resume features.