In March 2024, a single developer -- operating under the pseudonym Jia Tan -- nearly compromised every Linux server on the internet. The XZ Utils backdoor, discovered by Microsoft engineer Andres Freund through a lucky observation about SSH latency, was the culmination of a two-year social engineering campaign to gain maintainer access to a critical compression library embedded in virtually every Linux distribution. The backdoor would have given its operators remote code execution on any system running the compromised version of OpenSSH.
XZ Utils was not a high-profile project. It had two maintainers, no significant funding, and no security audit process. Yet it sat in the dependency tree of nearly every Linux-based system in production. This is the supply chain problem in its purest form: the security of your application depends on the security of every component in its dependency graph, including components maintained by unpaid volunteers who may be targeted by nation-state actors.
The Numbers Tell the Story
Sonatype's annual State of the Software Supply Chain report documented a 742% increase in supply chain attacks between 2019 and 2024. That is not a gradual upward trend. That is an exponential escalation by adversaries who have realized that compromising a single widely-used dependency is more efficient than targeting individual organizations.
Three incidents define the trajectory:
SolarWinds (December 2020) -- Russian intelligence operatives compromised the build pipeline of SolarWinds' Orion IT management software, inserting a backdoor that was distributed to approximately 18,000 organizations including the US Treasury, Commerce Department, and Homeland Security. The attack was undetected for nine months.
Log4Shell (December 2021) -- A critical remote code execution vulnerability in Apache Log4j, a logging library present in an estimated 35,000 Java packages (roughly 8% of Maven Central), became the most widely exploited vulnerability in history within hours of disclosure. Organizations that could not quickly determine whether they used Log4j -- directly or transitively -- were exposed for weeks.
XZ Utils (March 2024) -- The social engineering attack described above. Discovered by chance, not by any security process, audit tool, or SBOM-based detection mechanism.
Each of these incidents exposed the same fundamental weakness: most organizations do not have a reliable, machine-readable inventory of the software components running in their production environments. When a vulnerability is announced, the first question -- "Are we affected?" -- takes days or weeks to answer. That delay is the window during which attackers operate.
What Is an SBOM, Exactly?
A Software Bill of Materials is a machine-readable inventory of every component in a piece of software -- every library, every framework, every transitive dependency, along with version numbers, licenses, and known vulnerability status. Think of it as a nutrition label for software.
The concept is borrowed from manufacturing, where a Bill of Materials (BOM) has been standard practice for decades. When a car manufacturer discovers a defective brake component, they can trace every vehicle that contains that component within hours because they maintain a BOM for every product. Software has operated without this capability for most of its history.
An SBOM does not prevent vulnerabilities. It enables rapid response. When the next Log4Shell happens -- and it will -- an SBOM tells you within minutes whether your software includes the affected component, at what version, and through which dependency chain. That information transforms an incident response from "scramble to grep through codebases" to "query the SBOM database and generate an affected-systems report."
The Legal Landscape Has Changed
This is no longer optional for many organizations.
US Executive Order 14028 (May 2021, with subsequent implementation guidance) requires that any software sold to the US federal government include an SBOM. This affects not just government contractors, but any software vendor in the federal supply chain. The NTIA (National Telecommunications and Information Administration) published minimum elements for SBOMs that define the baseline: supplier name, component name, version, dependency relationship, author, and timestamp.
EU Cyber Resilience Act (CRA), which entered into force in late 2024 with a 36-month implementation window, makes SBOMs mandatory for any product with digital elements sold in the European Union. The scope is broad -- it covers everything from IoT devices to SaaS platforms to developer tools. Non-compliance carries fines of up to 15 million euros or 2.5% of global turnover.
US FDA requirements for medical device software now require SBOMs as part of premarket submissions. Devices submitted without SBOMs face rejection.
The trajectory is unmistakable. SBOMs are becoming a market access requirement, not a best practice suggestion. Organizations that implement them now are preparing for a regulatory environment that is already arriving.
SPDX vs CycloneDX: Choosing Your Format
Two SBOM formats dominate the landscape. Here is an honest comparison.
| Feature | SPDX (Linux Foundation) | CycloneDX (OWASP) |
|---|---|---|
| Governing Body | Linux Foundation / ISO | OWASP Foundation |
| ISO Standard | Yes (ISO/IEC 5962:2021) | No (but widely adopted) |
| Primary Focus | License compliance + security | Security + vulnerability mgmt |
| Format Options | JSON, XML, RDF, YAML, Tag-Value | JSON, XML, Protocol Buffers |
| Vulnerability Linking | Via external references | Native VEX integration |
| License Coverage | Comprehensive (SPDX License List) | Basic |
| Tooling Ecosystem | Broad, slightly fragmented | Growing, well-integrated |
| Federal Compliance | Explicitly referenced in NTIA guidance | Accepted, not specifically referenced |
| Machine Readability | Good | Excellent |
| Complexity | Higher (more fields) | Lower (purpose-built for security) |
| AI/ML BOM Support | Emerging (SPDX AI profile) | Yes (CycloneDX MLBOM) |
Our recommendation: for most development teams focused on security use cases, CycloneDX is the more practical choice. Its native vulnerability exchange (VEX) support, simpler schema, and tighter integration with security tooling make it easier to implement and consume. For organizations with significant open-source license compliance requirements (e.g., distributing GPL-licensed code), SPDX's comprehensive license tracking is more mature.
If you are selling to the US federal government, SPDX has a slight edge due to explicit NTIA references. To be fair, both formats are accepted, and most enterprise SBOM consumption platforms (Dependency-Track, Snyk, Anchore) can ingest either format.
Generating SBOMs in Your CI/CD Pipeline
The practical implementation is less painful than most teams expect. Here are working examples for common ecosystems.
Node.js / npm
# Using CycloneDX npm plugin
npx @cyclonedx/cyclonedx-npm --output-format json --output-file sbom.json
# Using Syft (supports multiple ecosystems)
syft dir:. -o cyclonedx-json > sbom.jsonPython / pip
# Using CycloneDX Python tool
pip install cyclonedx-bom
cyclonedx-py requirements -i requirements.txt -o sbom.json --format json
# For Poetry projects
cyclonedx-py poetry -o sbom.json --format jsonGo
# Using CycloneDX Go module
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod mod -json -output sbom.json
# Using Syft
syft dir:. -o cyclonedx-json > sbom.jsonRust / Cargo
# Using cargo-cyclonedx
cargo install cargo-cyclonedx
cargo cyclonedx --format json
# Using Syft
syft dir:. -o cyclonedx-json > sbom.jsonContainer Images
# Using Syft (the most versatile option for containers)
syft myregistry/myimage:latest -o cyclonedx-json > sbom.json
# Using Docker Scout (built into Docker Desktop)
docker scout sbom myregistry/myimage:latest --format cyclonedxThe key insight: Anchore's Syft tool is the Swiss army knife of SBOM generation. It handles containers, file systems, and archives across nearly every package ecosystem. For teams using multiple languages or containerized deployments, Syft as a single standardized tool reduces the maintenance burden of language-specific SBOM plugins.
CI/CD Integration Example (GitHub Actions)
name: Generate SBOM
on:
push:
branches: [main]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Syft
uses: anchore/sbom-action/download-syft@v0
- name: Generate SBOM
run: syft dir:. -o cyclonedx-json > sbom.json
- name: Scan for vulnerabilities
uses: anchore/scan-action@v4
with:
sbom: sbom.json
fail-build: true
severity-cutoff: high
- name: Upload SBOM artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.jsonThis pipeline generates an SBOM on every push to main, scans it for known vulnerabilities, and fails the build if any high-severity issues are found. Total addition to build time: approximately 30-60 seconds.
Beyond SBOMs: The Complete DevSecOps Toolchain
An SBOM tells you what is in your software. But a comprehensive DevSecOps pipeline needs to answer several additional questions: Is the code itself secure? Are the container images hardened? Are there secrets in the repository? Here is the full picture.
| Tool Category | What It Catches | Example Tools | CI/CD Integration | Typical Cost |
|---|---|---|---|---|
| SBOM Generation | Component inventory | Syft, Trivy, CycloneDX tools | Native | Free (OSS) |
| SCA (Software Composition Analysis) | Known vulns in dependencies | Snyk, Dependabot, Grype | Native | Free tier available |
| SAST (Static Application Security Testing) | Code-level vulnerabilities | Semgrep, SonarQube, CodeQL | Native | Free tier available |
| DAST (Dynamic Application Security Testing) | Runtime vulnerabilities | OWASP ZAP, Burp Suite, Nuclei | Moderate effort | Free (ZAP) to $$$ |
| Container Scanning | Image vulnerabilities, misconfig | Trivy, Grype, Docker Scout | Native | Free (OSS) |
| Secrets Detection | Hardcoded credentials, API keys | Gitleaks, TruffleHog, git-secrets | Native | Free (OSS) |
| IaC Scanning | Infrastructure misconfigurations | Checkov, tfsec, KICS | Native | Free (OSS) |
| License Compliance | License violations | FOSSA, Licensee, Syft | Moderate effort | Free to $$$ |
The honest assessment: no team needs all of these on day one. Start with three: SBOM generation (Syft), dependency scanning (Grype or Snyk), and secrets detection (Gitleaks). These three cover the most common attack vectors with the least implementation effort. Add SAST and container scanning as your security practice matures.
The Shift-Left Principle in Practice
"Shift left" has become something of a buzzword, but the underlying principle is sound: security feedback delivered to a developer while they are writing code is orders of magnitude cheaper to act on than security feedback delivered after deployment.
Here is what shift-left looks like in practice, not as a philosophy but as a technical implementation:
Pre-commit hooks run Gitleaks to catch secrets before they enter the repository. A leaked AWS key in a git commit is a compromised AWS key, even if the commit is later reverted -- git history is permanent.
Pull request checks run Semgrep (SAST) and Grype (SCA) against the changed files. Developers see security findings in the same interface where they review code. The feedback loop is measured in minutes, not weeks.
Build pipeline generates the SBOM, runs container scanning on built images, and validates that no high-severity vulnerabilities are present. Builds fail automatically on policy violations.
Deployment gates verify that the SBOM has been generated, vulnerability scans have passed, and the artifact has not been tampered with (using cosign for container image signing).
The critical distinction: this is not a security team reviewing deployments after the fact. This is automated tooling integrated into the developer workflow, providing immediate feedback at every stage. Developers are not asked to become security experts. They are given tools that surface security issues in the context of their normal work.
A Real-World Scenario: The Transitive Dependency Problem
Let us walk through how a single vulnerable transitive dependency can compromise an entire deployment, and how SBOMs change the response.
Your Node.js application depends on express. Express depends on body-parser. Body-parser depends on raw-body. Raw-body depends on bytes. You never imported bytes directly. It does not appear in your package.json. But it is in your node_modules, it runs in your production environment, and if a vulnerability is discovered in it, you are affected.
In a typical Node.js project, the ratio of direct dependencies to total dependencies (including transitive) is roughly 1:10. A project with 30 direct dependencies may have 300+ packages in its full dependency tree. Each one is a potential attack surface.
Without an SBOM, when a CVE is published for bytes version 3.1.0, your security team needs to manually check every project to determine exposure. With hundreds of microservices, this process can take days.
With an SBOM generated at build time and stored in a central registry like Dependency-Track, the query is immediate: "Which deployments contain bytes@3.1.0?" The answer returns in seconds, along with the full dependency chain showing how the vulnerable component entered each affected build.
That time difference -- days versus seconds -- is the difference between a controlled remediation and a crisis response.
What We Have Learned Shipping SBOMs
We have been generating and shipping SBOMs with every production deployment at CODERCOPS since mid-2024. Here is what we have learned.
Start with containers, not source code. Container-level SBOMs capture everything: your application code, your dependencies, the base image packages, the OS-level libraries. A source-code SBOM misses the runtime environment, which is where many vulnerabilities live (looking at you, outdated OpenSSL in Alpine base images).
Automate ruthlessly. The moment SBOM generation requires manual steps, it stops happening. It must be a mandatory, automated stage in the CI/CD pipeline. No SBOM, no deployment.
Use Dependency-Track for consumption. Generating SBOMs is the easy part. Consuming them -- continuously monitoring for newly disclosed vulnerabilities against your inventory -- requires a dedicated platform. OWASP Dependency-Track is open source, handles both SPDX and CycloneDX, and integrates with most notification systems. We run it as a central service that ingests SBOMs from every project's CI pipeline.
Expect initial noise. The first time you run SCA against a mature codebase, the vulnerability count will be alarming. Do not panic. Many findings are false positives, informational, or in code paths that are not actually reachable. Triage methodically: focus on critical and high severity findings in packages that are actually used (not just installed), and suppress false positives with documented rationale.
SBOM freshness matters. An SBOM generated six months ago is marginally useful. SBOMs must be regenerated on every build and stored with the corresponding artifact version. When a new CVE drops, you need to know what is running right now, not what was running at the last quarterly audit.
The Cost of Inaction
The average cost of a data breach reached $4.88 million in 2024, according to IBM's annual Cost of a Data Breach report. Supply chain attacks tend toward the higher end of that range because they often affect multiple organizations simultaneously and involve compromised trust relationships that are difficult to remediate.
More concretely: if your organization sells software to the US federal government or the European Union market, SBOM compliance is no longer a security best practice -- it is a market access requirement with specific deadlines. Federal procurement requirements are being enforced now. The EU CRA's implementation deadline is approaching. Organizations that have not implemented SBOM generation and vulnerability management by that point will face contractual and regulatory consequences.
The investment to get started is modest. Syft is free. Grype is free. Dependency-Track is free. Gitleaks is free. A senior engineer can implement a basic DevSecOps pipeline with SBOM generation in two to three days. The ongoing maintenance cost is minimal -- the tools run automatically in CI/CD and only require attention when they surface actual findings.
Compared to the cost of a supply chain incident -- or the cost of losing a contract because you cannot produce an SBOM -- the investment is negligible.
Where This Goes Next
The SBOM ecosystem is maturing rapidly. VEX (Vulnerability Exploitability eXchange) is emerging as a companion standard that lets software producers communicate whether a known vulnerability in a component is actually exploitable in their specific product. This addresses the false positive problem that makes early SBOM adoption noisy.
Build provenance attestation (via SLSA -- Supply-chain Levels for Software Artifacts) adds another layer by cryptographically verifying that a software artifact was built from a specific source commit, by a specific build system, with a specific SBOM. This makes it possible to detect tampering at the build level -- exactly the kind of attack that SolarWinds executed.
The direction is clear: software supply chain transparency is becoming a non-negotiable requirement, not a differentiator. The organizations building these capabilities now are not over-investing in security. They are meeting the baseline expectation of where the industry is heading.
Supply chain security is a core part of every application we build at CODERCOPS. If your team needs help implementing SBOMs, DevSecOps pipelines, or a security-first CI/CD workflow, reach out to us. We will get your pipeline hardened without slowing down your shipping velocity.
Comments