In the age of increasing supply chain attacks and strict compliance requirements, knowing exactly what’s inside your container images is no longer optional. That’s where SBOM (Software Bill of Materials) comes in.

An SBOM is a formal, machine-readable inventory of all software components (libraries, packages, binaries) included in a container image or application.

With Docker now supporting SBOM generation natively from version v20.10.24, DevOps teams can integrate security and compliance checks directly into their CI/CD pipelines.

SBOM Basics for Beginners

Think of SBOM like a nutrition label — it tells you exactly what ingredients (packages, libraries, binaries) are inside your container image. Without it, you’re shipping a black box.

SBOM Answers:

  • What packages are in my image?
  • Which versions are used?
  • Where did they come from?
  • Are they secure?

If you’re building a Docker image for a Node.js or Java app, an SBOM gives you full visibility — not just for today, but also for future audits, vulnerability scans, and compliance checks.

Why SBOM Is a DevOps Must-Have

Concern Without SBOM With SBOM
Security Hidden vulnerabilities Component-level visibility
Compliance (e.g., NIST, FedRAMP) Manual, error-prone auditing Automated and traceable reports
Vendor & customer trust No evidence of safety Transparent dependency disclosure
Incident response Slow and blind Fast root cause identification

SBOM is now a requirement in many industries: fintech, healthcare, government, SaaS — anywhere that values security and traceability.

Getting Started with Docker’s Native SBOM

Starting from Docker v20.10.24, you can run:

1
docker sbom <image-name>

This command uses Syft (by Anchore) under the hood.

Prerequisites:

  • Docker version 20.10.24 or later
  • An image built with docker build

Check Docker version:

1
docker version

Example 1: Basic SBOM for nginx

1
2
docker pull nginx:latest
docker sbom nginx:latest

Sample output:

1
2
3
✔ Cataloged packages [57 packages]
libssl3      3.0.11-r0      apk
nginx        1.24.0-r1      apk

You now know what libraries nginx is using — vital for checking vulnerabilities.

Example 2: SBOM for Node.js App

Dockerfile

1
2
3
4
5
6
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "index.js"]

Build and scan:

1
2
docker build -t my-node-app .
docker sbom my-node-app

Output Sample:

1
2
yargs           17.3.1          npm
axios           1.3.4           npm

💡 You now have an inventory of every open-source dependency inside your production image.

Example 3: Export SBOM in SPDX Format

1
docker sbom --format spdx-json my-node-app > sbom.spdx.json

Use this file to:

  • Archive for audits (e.g., FedRAMP, ISO)
  • Integrate into vulnerability scanners
  • Share with clients or regulators

Example 4: Real-World CI/CD Pipeline with GitHub Actions

Use Case:

You’re in a fintech company. Every image must include an SBOM and pass scanning before deployment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
name: Build and Scan Docker Image

on:
  push:
    branches: [ main ]

jobs:
  build-and-sbom:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: docker/setup-buildx-action@v3
    - run: docker build -t myapp:latest .
    - run: docker sbom --format spdx-json myapp:latest > sbom.json
    - uses: actions/upload-artifact@v3
      with:
        name: sbom
        path: sbom.json

This ensures every build has a security manifest.

Example 5: Scan SBOM with Grype

Grype is a CLI vulnerability scanner that reads SBOMs.

Install it:

1
brew install grype

Scan an image:

1
grype myapp:latest

Or scan a saved SBOM:

1
grype sbom:sbom.json

Sample vulnerabilities:

1
openssl     1.1.1       CVE-2022-0778      HIGH

Real-World Failure Prevented: Log4Shell

Let’s say your Java image includes:

1
log4j-core:2.14.1

If your CI includes SBOM + Grype:

  • SBOM detects log4j-core
  • Grype finds CVE-2021-44228
  • Pipeline blocks deployment

🎯 You just avoided a critical zero-day vulnerability from hitting production.

Example 6: Store SBOM in Artifact Repositories

Store SBOMs alongside images in:

  • Amazon ECR (via S3 or tags)
  • Harbor (native SBOM metadata)
  • JFrog Artifactory

Best Practice:

  • Save SBOM as JSON
  • Attach SBOM hash as Docker label
  • Upload both image + SBOM to registry

SPDX vs CycloneDX: What’s the Difference?

Feature SPDX CycloneDX
Created By Linux Foundation OWASP
Ecosystem Broad (OSS, legal) Focused (security)
Format JSON, XML, RDF JSON, XML
Best For Auditing & licensing Vulnerability analysis

For security-first pipelines, CycloneDX is often preferred. Docker uses SPDX by default.

Final Thoughts

In 2025 and beyond, every software team needs a secure supply chain. SBOMs are your first line of defense.

“You can’t secure what you don’t see.”

Start small. Add docker sbom to your next build. Automate the rest over time.

With SBOM + scanning, you gain security, compliance, and trust — by default.

Happy Coding