In March 2024, a Microsoft engineer named Andres Freund noticed something odd: SSH logins on a Debian testing server were taking about 500 milliseconds longer than they should. That small delay led him to CVE-2024-3094 — a backdoor buried inside XZ Utils, a compression library baked into nearly every Linux distribution on Earth. The backdoor had been planted over roughly two years by a contributor who patiently earned maintainer trust before slipping malicious code into a build script. It's the clearest recent proof that software supply chain security (SSCS) isn't about the code your team writes — it's about the thousands of dependencies, build systems, and pipelines you inherit. Since SolarWinds compromised an estimated 18,000 organizations in December 2020, and Log4Shell (CVSS 10.0) exposed hundreds of millions of devices a year later, SSCS has gone from a niche compliance checkbox to a board-level priority — and a market where vendors like Anchore have built entire businesses around one piece of the puzzle: the SBOM.
What Is Software Supply Chain Security, Really?
Software supply chain security is the practice of securing every component, dependency, tool, and process involved in building, packaging, and shipping software — not just the code a team writes itself. That includes open source libraries pulled from npm, PyPI, or Maven Central, the CI/CD pipelines that compile and test the code, the container registries that store finished artifacts, and the third-party APIs the application calls at runtime. This matters more than most teams assume: Synopsys's Open Source Security and Risk Analysis report has repeatedly found that 70-96% of the average commercial codebase is open source, meaning most of what ships under a company's name was written by someone outside the company. A typical enterprise application can pull in several hundred transitive dependencies it never explicitly chose. SSCS is the discipline of knowing what's in that pile, verifying it hasn't been tampered with, and catching problems before they reach production — a scope far broader than traditional application security, which mostly assumes the code in front of you is trustworthy.
Why Did Supply Chain Attacks Suddenly Become Everyone's Problem?
Supply chain attacks scaled up because attackers realized compromising one upstream provider is far more efficient than attacking thousands of downstream targets one at a time. SolarWinds proved the model in December 2020, when a tampered update to the Orion platform reached roughly 18,000 customers, including U.S. Treasury and Department of Homeland Security networks, from a single injection point. Log4Shell (CVE-2021-44228), disclosed on December 10, 2021, carried a maximum CVSS score of 10.0 and sat inside a logging library embedded in an estimated hundreds of millions of Java applications, turning one obscure dependency into a global incident response event overnight. Gartner's 2021 prediction that 45% of organizations worldwide would experience a software supply chain attack by 2025 — a three-fold increase from 2021 — has aged uncomfortably well; Sonatype's 2023 State of the Software Supply Chain report logged over 245,000 malicious open source packages discovered that year alone, more than the prior four years combined. Attackers have effectively moved upstream, and defenses built only around "our own code" no longer cover the actual attack surface.
What Does an SBOM Actually Do — and Why Has Anchore Bet Its Business on It?
A Software Bill of Materials (SBOM) is a structured inventory of every component inside a piece of software — think of it as an ingredient label that lets a security team answer "am I running the vulnerable version of Log4j?" in minutes instead of the weeks it took most enterprises in December 2021. Anchore, one of the more established names in this space, built its open source tools Syft (SBOM generation) and Grype (vulnerability scanning) squarely around this idea, later packaging them into Anchore Enterprise and courting federal buyers through programs like DoD's Platform One and Iron Bank, where SBOM production is a hard requirement. SBOMs typically follow one of two standards — SPDX (a Linux Foundation project) or CycloneDX (originated by OWASP) — and the NTIA has defined a set of "minimum elements" a compliant SBOM must include. The gap Anchore's approach leaves open is provenance: an SBOM tells you what's inside a package, but not whether the build process that produced it was tampered with. The XZ Utils backdoor would have shown up in a perfectly formatted SBOM listing "xz-utils 5.6.1" — the malicious code was hidden inside the build scripts and test artifacts, not declared as a new dependency. SBOMs are necessary. They are not sufficient.
What Are the Core Pillars of a Complete SSCS Program?
A mature software supply chain security program rests on four pillars, and most breaches trace back to a gap in one of them: component inventory (SBOMs), build provenance and integrity, continuous vulnerability and malware monitoring, and policy enforcement inside CI/CD itself. Provenance is the pillar SBOM-first tools tend to underweight — it's addressed by frameworks like SLSA (Supply-chain Levels for Software Artifacts), originally developed at Google and now housed under the OpenSSF, which defines four levels of build tamper-resistance, and by Sigstore/cosign, which lets teams cryptographically sign and verify artifacts rather than trust them by default. Continuous monitoring matters because a dependency that was safe on Monday can be flagged malicious by Friday — Sonatype and Socket have both documented cases of maintainer accounts being hijacked to push malware into packages with millions of existing downloads, meaning a one-time scan at build time misses threats introduced after the fact. Policy enforcement closes the loop by blocking a pull request or build from merging until it clears defined thresholds — unsigned artifacts, critical CVEs, or packages published in the last 24-48 hours, a common heuristic since freshly published malicious packages are a recurring pattern in npm and PyPI attacks.
How Do Regulations Like Executive Order 14028 Change What's Required?
Executive Order 14028, signed May 12, 2021 in direct response to SolarWinds, turned SBOM production from a best practice into a federal purchasing requirement, and the compliance apparatus built on top of it has only grown since. NIST's Secure Software Development Framework (SP 800-218) now defines the practices federal software vendors must attest to, and as of 2024 CISA requires software producers selling to federal agencies to submit a formal self-attestation form confirming those practices are followed. FedRAMP authorizations increasingly expect SBOM artifacts as part of the continuous monitoring package, and the Department of Defense's push toward continuous Authority to Operate (cATO) leans heavily on the same provenance and inventory data. The regulatory pressure isn't confined to the U.S.: the EU Cyber Resilience Act, which entered into force in December 2024, will require manufacturers of products with digital elements sold in the EU to maintain SBOMs and report actively exploited vulnerabilities within 24 hours, with most obligations phasing in by 2027. For any company selling into government or EU markets, SSCS has quietly become a contractual line item, not a security team's optional initiative.
How Safeguard Helps
Safeguard was built on the premise that an SBOM is a starting inventory, not a finish line. Where SBOM-first tools generate a point-in-time snapshot at build or scan time, Safeguard maintains continuous visibility across the full pipeline — source repositories, build systems, dependency graphs, container registries, and deployed artifacts — so a package that turns malicious after it's already in production gets flagged the same day, not at the next scheduled scan. Safeguard verifies build provenance using SLSA and in-toto attestations, so teams can confirm an artifact was actually produced by the pipeline it claims to come from, closing the exact gap that let the XZ Utils backdoor hide inside legitimate-looking build scripts. Policy-as-code gates sit directly in CI/CD, blocking unsigned artifacts, newly-published dependencies, and known-malicious packages before they merge, rather than surfacing them in a report after the fact. And because compliance is now a purchasing requirement rather than a nice-to-have, Safeguard maps every finding directly to EO 14028, NIST SSDF, and FedRAMP control language, so security and compliance teams work from the same evidence instead of reconciling two separate tools. The goal isn't a better ingredient label — it's knowing, continuously, whether anything in the kitchen has been tampered with.