In March 2024, a Microsoft engineer named Andres Freund noticed SSH logins on a Debian testing box were taking 500 milliseconds longer than they should. That anomaly led him to discover CVE-2024-3094, a backdoor deliberately planted in the xz-utils compression library by a contributor who had spent two years building trust in the project. The backdoor was days away from shipping in major Linux distributions. It is one of the clearest examples yet of why "software supply chain security" has moved from a compliance checkbox to a board-level concern. Between SolarWinds (2020, roughly 18,000 downstream organizations affected), Log4Shell (December 2021), and the xz incident, security teams have learned that the packages, build systems, and CI/CD pipelines behind their software are now as much of an attack surface as the application code itself. This post lays out the practices that actually reduce risk, and where tools like Anchore fit into the picture.
What Makes Software Supply Chain Security Different From Application Security?
Software supply chain security is different because it protects the pipeline that produces your software, not just the code you wrote. Traditional AppSec tools — SAST, DAST, code review — assume the artifact being tested is trustworthy and focus on finding bugs in first-party logic. Supply chain security starts from the opposite assumption: that any dependency, build step, container base image, or CI runner could be compromised before your code ever runs. Sonatype's 2023 State of the Software Supply Chain report counted over 245,000 malicious packages published to open-source registries that year alone — more than the previous four years combined. Gartner has separately projected that by 2025, 45% of organizations worldwide will have experienced an attack on their software supply chain, roughly triple the rate from 2021. That shift is why the practice now spans four distinct layers: source integrity (who can commit and merge), build integrity (what actually produced the binary), dependency integrity (what's inside it), and deployment integrity (what's actually running in production). A vulnerability scanner alone only addresses one of those four.
Why Do Software Bills of Materials (SBOMs) Matter So Much Right Now?
SBOMs matter because you cannot secure, or even accurately assess, software you cannot inventory. An SBOM is a structured, machine-readable list of every component, library, and version that makes up a piece of software — the ingredient label for your application. Executive Order 14028, signed in May 2021 after the SolarWinds breach, made SBOMs a requirement for vendors selling software to the U.S. federal government, and CISA has since published formal guidance (2023) on minimum elements and VEX (Vulnerability Exploitability eXchange) documents that tell downstream consumers whether a given CVE is actually exploitable in their specific deployment. This matters in practice: when Log4Shell hit in December 2021, organizations without SBOMs spent weeks manually grepping filesystems and asking vendors "do you use Log4j?" Teams with SBOM tooling in place identified affected systems within hours. The two dominant formats, SPDX and CycloneDX, are both now ISO-recognized or industry-standard, and generating them at build time (not retroactively) is the difference between an SBOM that's accurate and one that's already stale by the time you need it.
How Should Teams Implement Provenance and Build Attestation?
Teams should implement provenance by adopting the SLSA (Supply-chain Levels for Software Artifacts) framework, which defines four levels of increasing build integrity, from SLSA 1 (documented build process) to SLSA 4 (hermetic, reproducible builds with two-party review). In practical terms, this means every artifact should carry a cryptographically signed attestation stating what source commit, what build system, and what parameters produced it — so a consumer can verify the binary they're running actually matches the source they audited. Sigstore, the open-source signing project backed by the OpenSSF, has made this achievable without teams needing to manage their own PKI: over 99% of new PyPI packages and a growing share of npm packages now support Sigstore-based signing as of 2024. The xz backdoor is instructive here too — because the malicious code was inserted into release tarballs but not visible in the public git history, teams relying solely on source-code review missed it; provenance attestation that ties a binary to a reproducible build process would have made that discrepancy detectable. NIST's Secure Software Development Framework (SP 800-218, updated 2022) now formalizes these expectations for any organization selling into regulated industries or the federal government.
What Role Does Continuous Monitoring Play After Deployment?
Continuous monitoring matters because a supply chain isn't secure once — it's secure (or not) every day a new CVE, malicious package version, or expired signing key enters the picture. The average time-to-exploit for a newly disclosed CVE dropped to under 5 days in 2023 according to multiple threat intelligence vendors, while the average enterprise takes weeks to patch. A one-time audit or a scan that only runs at merge time misses everything that happens after code ships: a transitive dependency gets compromised (as happened with event-stream in 2018 and ua-parser-js in 2022, both widely-used npm packages hijacked via maintainer account takeover), a base image is rebuilt with a new vulnerable package, or a previously "safe" component gets a CVE disclosed six months into production use. Effective programs re-scan running production inventories against live vulnerability feeds daily, not just at build time, and pair that with runtime detection for behavior that provenance and static scanning can't catch — a build step reaching out to an unexpected network endpoint, for instance, which is exactly the kind of signal that would have flagged the xz backdoor's staged payload activation logic.
How Do You Choose Between a Scanner Like Anchore and a Full Supply Chain Security Platform?
The choice comes down to whether you need vulnerability visibility or end-to-end risk reduction. Anchore built its reputation on container image scanning and SBOM generation, and it remains a capable tool for teams whose primary need is CVE detection in container images and basic SBOM output for compliance reporting. But scanning is one layer of a four-layer problem. Organizations that adopt a scanner alone typically still have to separately solve source integrity (who can approve and merge code), build provenance (proving what actually produced the artifact), policy enforcement (blocking non-compliant builds before they ship, not just reporting on them after), and runtime correlation (connecting a production incident back to the exact build and commit that introduced it). Teams evaluating options in 2026 are increasingly asking not "does this tool find CVEs" — most competent scanners do — but "does this platform let me enforce a policy that stops an unsigned or unattested artifact from deploying at all." That's the practical line between a point tool and a supply chain security program.
How Safeguard Helps
Safeguard was built around the assumption that scanning alone doesn't stop the attacks that matter most — the xz-style, SolarWinds-style incidents that live in the build pipeline, not in a CVE database. Safeguard generates accurate, build-time SBOMs automatically (SPDX and CycloneDX) so your component inventory is never stale, and pairs that with SLSA-aligned provenance attestation so every artifact carries cryptographic proof of the commit, build system, and pipeline that produced it. Rather than treating policy as a report you read after the fact, Safeguard enforces it at the gate: unsigned artifacts, unattested builds, and dependencies with unresolved critical CVEs can be blocked from deploying, not just flagged. On top of that, Safeguard continuously reconciles your SBOM inventory against live vulnerability and malicious-package feeds, so a compromised transitive dependency or a maintainer account takeover on a package you depend on surfaces the same day it's disclosed, not during your next quarterly audit. For teams currently relying on a scanner for compliance checkboxes, Safeguard is designed to be the layer above it — closing the gaps in source integrity, build provenance, and policy enforcement that a scan alone can't reach, so that the next xz-scale incident gets caught in your pipeline instead of in your production environment.