SBOMs in Production: Lessons from the SolarWinds & xz Attacks

The last few years have made one thing clear: modern software supply chains are broken. High-profile attacks like the SolarWinds breach in 2020 and the xz backdoor incident in 2024 showed just how fragile and opaque our dependency chains are.

This article digs deep into how Software Bill of Materials (SBOMs) are reshaping modern software security, what tools like CycloneDX and SPDX offer, and how SBOMs in production could have mitigated — or at least detected — some of the most impactful breaches in recent history.

What Is an SBOM?

An SBOM is a formal record of the components, libraries, and dependencies that make up a piece of software. Think of it like a nutrition label for software. It lists everything that’s inside, where it came from, and its version.

The U.S. government now mandates SBOMs for federal software vendors. Enterprises are following suit, not because of compliance pressure, but because it’s becoming impossible to secure software you don’t fully understand.

Why SBOMs Matter in the Real World

1. Attackers are targeting dependencies

Supply chain attacks don't aim at your code. They aim at the weakest library your application depends on. If you’re pulling in dozens of packages per build (and you are), you need to know what those packages are and where they come from.

Generate an SBOM Using syft (for Docker or Local Projects)

# Install syft (if not already installed)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate an SBOM in CycloneDX format for a Docker image
syft docker.io/library/nginx:latest -o cyclonedx-json > nginx-sbom.json

2. Transparency enables trust

Without an SBOM, you're blind to what's in your software. With one, you can trace vulnerable components, identify outdated packages, and even catch malicious insertions like the one seen in the xz utils.

3. SBOMs create a feedback loop

Once you’ve generated SBOMs for all your builds, you can start building policies:

• No packages without maintainers
• No outdated or vulnerable libraries
• Block known malware signatures
• Validate signatures of upstream packages

Case Study #1: SolarWinds (2020)

The breach: Attackers injected a malicious DLL into the build pipeline of the Orion monitoring platform. Over 18,000 customers installed the compromised binary.

What went wrong:

• No audit of what components were shipped to customers
• No integrity validation of build artifacts
• No SBOM to identify that a malicious file had been added

What an SBOM could have done:

• Provided a record of expected components per release
• Flagged untracked files in production images
• Helped customers quickly identify if they were affected based on component matching

Case Study #2: The xz Backdoor (2024)

The breach: A malicious contributor gained trust in the xz utils project. They inserted a backdoor that would trigger on SSH login, allowing remote code execution.

What went wrong:

• The malicious code was committed over months, slowly and subtly
• No downstream alerting when the xz tarball changed checksums
• No SBOM or hash registry to compare known-good binaries

What an SBOM could have done:

• Captured exact versions and hashes of xz as a dependency
• Alerted build tools when the hash did not match approved values
• Triggered a supply chain validation failure

Scan an SBOM for Known Vulnerabilities Using grype

# Install grype (if not already installed)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Scan the SBOM file generated earlier
grype sbom:nginx-sbom.json

CycloneDX vs SPDX

Use CycloneDX when you're embedding SBOMs into your DevOps pipelines and want tight CI/CD integration. Use SPDX when your focus is licensing, compliance, and legal traceability.

Integrating SBOMs into DevOps

1. Generate SBOMs automatically in CI pipelines
2. Store SBOMs in artifact repositories
3. Validate SBOMs before promotion
4. Monitor and update SBOMs in production

Tools like syft, grype, trivy, bomtool, and various CycloneDX generators are commonly used to support these steps.

Beyond Compliance: Why SBOMs Matter Now

The goal of SBOMs isn’t just checking a regulatory box. It’s knowing what you run. It’s building the foundation of a security model that can detect tampering, enforce integrity, and make supply chain attacks harder to pull off and faster to respond to.

As attacks move from code to the build system, from applications to libraries, and from CVEs to CI/CD abuse, SBOMs give us the one thing we’re all missing: visibility.

Final Thoughts

SBOMs won’t stop the next SolarWinds or xz attack by themselves. But they will:

• Help you know if you’re exposed
• Help you act faster in a breach
• Give you leverage in vendor trust
• Make your software build process auditable

Every team building or running software should be generating SBOMs today, not for compliance, but because modern security demands it.