Lesson 07 — Software Bill of Materials (SBOM)

Learning Objectives

By the end of this lesson, you will be able to:

Understand what a Software Bill of Materials (SBOM) is
Learn why SBOMs are important for container security
Understand the components of an SBOM
Explore SBOM standards and formats
Learn how SBOMs improve vulnerability management
Integrate SBOM generation into CI/CD pipelines
Apply enterprise SBOM best practices for Amazon EKS

Why This Matters

Modern applications rarely consist of only custom-written code.

Instead, they contain:

Open-source libraries
Programming language packages
Operating system packages
Frameworks
Third-party dependencies
Container base images

A single container image may contain hundreds or even thousands of software components.

Without visibility into these components, organizations cannot quickly answer questions such as:

Which applications use Log4j?
Which containers contain vulnerable OpenSSL versions?
Which workloads are affected by a newly disclosed CVE?
Are we using approved software components?

An SBOM provides this visibility.

What is an SBOM?

A Software Bill of Materials (SBOM) is a complete inventory of every software component included in an application or container image.

Think of it as an ingredient list on a food product.

Container Image

↓

Software Bill of Materials (SBOM)

├── Base Image

├── Operating System Packages

├── Runtime

├── Libraries

├── Open Source Dependencies

├── Application Packages

└── Versions

An SBOM provides complete transparency into what is inside an image.

Why SBOMs Matter

Without an SBOM:

Critical CVE Published

↓

Which Applications Are Affected?

↓

Unknown

↓

Slow Response

With an SBOM:

Critical CVE Published

↓

Search SBOM

↓

Identify Affected Images

↓

Patch Quickly

SBOMs dramatically reduce incident response time.

What Information Does an SBOM Contain?

An enterprise SBOM typically includes:

Software name
Component version
Supplier or vendor
Package manager
License information
Hash values
Dependency relationships
Component type
Image digest
Build metadata

This information helps organizations understand exactly what has been deployed.

SBOM Example

Application

↓

Python 3.12

↓

Flask 3.0.2

↓

Requests 2.32

↓

OpenSSL 3.x

↓

Amazon Linux 2023

Every component is recorded with its version.

Direct vs Indirect Dependencies

Applications contain both direct and indirect dependencies.

Application

├── Direct Library A

│

└── Direct Library B

      │

      ├── Dependency C

      ├── Dependency D

      └── Dependency E

Indirect dependencies often introduce vulnerabilities that developers may not even know exist.

Why Open Source Visibility Matters

Most enterprise applications rely heavily on open-source software.

Application

↓

Open Source Packages

↓

Known CVEs

↓

Security Risk

SBOMs help identify where vulnerable open-source components are being used.

SBOM Standards

Several industry standards exist.

Standard	Purpose
SPDX	Software Package Data Exchange
CycloneDX	Security-focused SBOM format
SWID	Software Identification Tags

SPDX and CycloneDX are the most widely adopted standards for cloud-native environments.

SBOM Generation Tools

Common tools include:

Tool	Purpose
Syft	Generates SBOMs for container images
Trivy	Generates SBOMs and scans vulnerabilities
Anchore Enterprise	Enterprise SBOM management
Docker Scout	Image insights and SBOM generation
Microsoft SBOM Tool	SBOM generation for applications
CycloneDX CLI	Creates and validates CycloneDX SBOMs

Many tools also integrate directly into CI/CD pipelines.

SBOM in CI/CD

Enterprise pipelines automatically generate SBOMs.

Developer

↓

Source Code

↓

Build Image

↓

Generate SBOM

↓

Vulnerability Scan

↓

Sign Image

↓

Amazon ECR

↓

Amazon EKS

The SBOM becomes part of the software delivery artifact.

SBOM and Vulnerability Management

When a new CVE is announced:

New CVE

↓

Search SBOM Repository

↓

Affected Applications

↓

Patch Images

↓

Redeploy

Organizations can quickly identify impacted workloads instead of manually inspecting applications.

SBOM and Compliance

Many regulatory frameworks now encourage or require SBOMs.

Benefits include:

Software transparency
Supply chain visibility
Faster audits
License compliance
Risk assessment
Regulatory reporting
Vendor assurance

SBOMs help organizations demonstrate secure software development practices.

SBOM in Amazon EKS

Developer

↓

CI/CD Pipeline

↓

Build Image

↓

Generate SBOM

↓

Image Scan

↓

Image Sign

↓

Amazon ECR

↓

Amazon EKS

The SBOM becomes another security artifact alongside scan reports and digital signatures.

Enterprise Example

A multinational healthcare provider operates over 20,000 containerized workloads on Amazon EKS.

A Critical vulnerability is disclosed in a widely used JSON parsing library.

Because every image includes an SBOM:

Security engineers search the centralized SBOM repository.
They identify every affected application within minutes.
Development teams rebuild only the impacted images.
Updated images are rescanned, signed and deployed.

Without SBOMs, the organization would have needed to manually inspect thousands of applications, significantly delaying remediation.

Common SBOM Risks

Cloud Security Engineers frequently identify:

No SBOM generation
Outdated SBOMs
Missing dependency information
Incomplete package inventories
No SBOM storage
Manual SBOM generation
Missing version information
No linkage between SBOMs and container images
Untracked third-party components
Missing license information

These weaknesses reduce visibility into software supply chains.

Enterprise Monitoring

Security teams should monitor:

Missing SBOMs
New software components
Vulnerable packages
Unsupported software versions
License compliance
Dependency changes
Build pipeline events
Image digests
Software inventory changes
Supply chain policy violations

Continuous monitoring improves software governance and compliance.

Enterprise Implementation Strategy

A recommended rollout:

Step 1

↓

Standardize Base Images

↓

Step 2

↓

Generate SBOMs Automatically

↓

Step 3

↓

Store SBOMs Centrally

↓

Step 4

↓

Perform Vulnerability Scanning

↓

Step 5

↓

Digitally Sign Images

↓

Step 6

↓

Deploy to Amazon EKS

↓

Step 7

↓

Monitor New CVEs

↓

Step 8

↓

Update and Regenerate SBOMs

This approach strengthens visibility across the software supply chain.

SBOM vs Image Scanning

SBOM	Image Scanning
Lists all software components	Identifies known vulnerabilities
Provides software inventory	Detects CVEs
Supports compliance	Supports remediation
Enables dependency analysis	Enables risk prioritization
Improves supply chain transparency	Improves security posture

Both capabilities complement each other and should be implemented together.

Best Practices

As a Kubernetes Security Engineer:

Generate an SBOM for every production image.
Automate SBOM generation in CI/CD pipelines.
Store SBOMs alongside container images.
Use standardized formats such as SPDX or CycloneDX.
Link SBOMs to image digests and signatures.
Continuously update SBOMs whenever images are rebuilt.
Combine SBOMs with vulnerability scanning and image signing.
Monitor software inventory for newly disclosed CVEs.
Track third-party software and license obligations.
Use SBOMs to accelerate incident response and compliance activities.

SBOMs provide the visibility needed to secure modern software supply chains.

Real-World Scenario

A global e-commerce company receives an urgent advisory about a newly discovered vulnerability in an open-source compression library.

Without an SBOM, engineers would need to inspect hundreds of repositories and thousands of container images manually.

Instead:

The security team searches the centralized SBOM repository.
All affected container images are identified within minutes.
Developers rebuild the images using updated libraries.
The new images are scanned, signed and redeployed through Amazon EKS.

The organization reduces remediation time from several days to just a few hours.

Key Takeaways

After completing this lesson, you should understand:

What a Software Bill of Materials (SBOM) is
Why SBOMs improve software supply chain transparency
What information an SBOM contains
Common SBOM standards such as SPDX and CycloneDX
SBOM generation tools
SBOM integration into CI/CD pipelines
How SBOMs accelerate vulnerability management and compliance
Enterprise best practices for Amazon EKS

Software Bill of Materials (SBOM) is a foundational capability for modern Kubernetes supply chain security. By maintaining a complete inventory of software components, organizations gain the visibility needed to respond rapidly to newly disclosed vulnerabilities, meet regulatory requirements and build trustworthy cloud-native applications.

Knowledge Check

Question 1

What is the primary purpose of an SBOM?

A. Encrypt container images
B. Provide a complete inventory of software components within an application or container image
C. Replace vulnerability scanning
D. Configure Kubernetes networking

Answer: B

Question 2

Which two SBOM standards are most commonly used in cloud-native environments?

A. YAML and JSON
B. SPDX and CycloneDX
C. XML and HTML
D. OCI and Helm

Answer: B

Question 3

Which tool is commonly used to generate SBOMs for container images?

A. Prometheus
B. Syft
C. Fluent Bit
D. Argo CD

Answer: B

Question 4

How do SBOMs improve vulnerability management?

A. By preventing all vulnerabilities.
B. By enabling organizations to quickly identify which applications contain affected software components.
C. By replacing image signing.
D. By encrypting software packages.

Answer: B

Question 5

Which combination represents enterprise best practice?

A. Generate SBOMs automatically, use SPDX or CycloneDX, store them centrally, combine them with vulnerability scanning and image signing, and continuously update them.
B. Generate SBOMs only after production incidents.
C. Store SBOMs only on developer laptops.
D. Use manual spreadsheets instead of automated SBOM generation.

Answer: A

What’s Next?

In the next lesson, you will learn about Supply Chain Security Frameworks (SLSA & in-toto), exploring how modern software supply chain frameworks establish build integrity, provenance, artifact verification and end-to-end trust for Kubernetes workloads running on Amazon EKS.

➡️ Next Lesson: Lesson 08 — Supply Chain Security Frameworks (SLSA & in-toto)