Software supply chain security is the defensive discipline that protects the third-party components, build systems, and distribution channels your software depends on. After Log4Shell and xz-utils, CVE scanning alone no longer covers the attack surface.
A modern stack combines Software Composition Analysis, SBOM generation, malicious-package detection, and build attestation. Each layer catches a different class of attack, and most teams need at least three of them.
This page is a tool-buying guide. For the attack taxonomy and famous incident history — SolarWinds, event-stream, ua-parser-js, xz-utils — the supply chain attacks guide covers each attack type with how it worked and how to spot it.
What is software supply chain security?
A software supply chain is every piece of code, every build step, and every distribution channel between a developer’s keyboard and a running production artifact. Supply chain security is the practice of keeping each link in that chain trustworthy.
The problem is scale. The Synopsys 2024 OSSRA report found 96% of commercial codebases contain open-source components, with hundreds of dependencies per application. Each dependency is a trust decision, and each trust decision compounds across the transitive graph.
Traditional application security focuses on bugs in your own code. Supply chain security focuses on the code you did not write but still ship — npm packages, base container images, CI/CD actions, compiler toolchains, and the registries that deliver them.
Four properties make supply chain attacks harder to defend than classic application flaws:
- Reach. One compromised npm package can land in thousands of downstream projects simultaneously. The ua-parser-js hijack in October 2021 affected a package with roughly 8 million weekly downloads at the time.
- Intentional malice. Most supply chain attacks are not bugs — they are deliberate malicious code. There is no CVE at the moment of attack and no patch to apply; the fix is removing or replacing the compromised component.
- Trust bypass. The malicious code arrives through the same update channel as legitimate updates. Automated dependency bumps deliver it.
- Time asymmetry. The xz-utils backdoor (CVE-2024-3094) was the result of a two-year social-engineering campaign by an attacker using the name “Jia Tan”. No scanner existing at the time would have flagged the commits.
This is why the defensive stack is layered. No single tool answers every question. A complete stack needs to know what is in your software (SBOM), whether any of it has known vulnerabilities (SCA), whether any of it is malicious regardless of CVE status (behavioural analysis), and whether the artifact you are about to ship came out of a trusted build (attestation).
Threat categories the supply chain stack covers
A complete supply chain stack defends against seven distinct attack classes: known CVE vulnerabilities, typosquatting, dependency confusion, compromised maintainer accounts, long-term malicious maintainers, compromised build pipelines, and transitive dependency risk. Each category maps to a different defensive layer — picking tools starts with knowing which category matters most for your threat model.
Known vulnerabilities in dependencies. The largest volume category. A dependency has a CVE, your project pulls in the vulnerable version, and a scanner should flag it. This is what SCA tools have done for a decade. Covered by Snyk Open Source, Trivy, Grype, OSV-Scanner, and every tool in the open-source SCA list.
Typosquatting. An attacker publishes a malicious package with a name close to a popular one — colourama instead of colorama, crossenv instead of cross-env. Developers who mistype during installation get the malicious version. Traditional CVE databases do not know about these packages at publish time. Covered by Socket (behavioural analysis), OSV-Scanner via the OpenSSF Malicious Packages feed, and registry-level guards.
Dependency confusion. Attackers publish packages on public registries with the same name as your internal private packages, relying on default package-manager behaviour that picks the highest version regardless of registry. Alex Birsan demonstrated this against Apple, Microsoft, and PayPal in 2021. Covered by namespace reservation, private-registry proxies, and lockfile pinning — tooling side: Artifactory, Nexus, GitHub Packages.
Compromised maintainer accounts. An attacker takes over a legitimate publisher account and ships malicious code as a routine version bump. The ua-parser-js hijack in October 2021 pushed cryptominers and credential stealers as versions 0.7.29, 0.8.0, and 1.0.0. The event-stream incident in November 2018 saw a new maintainer add a malicious dependency (flatmap-stream) targeting the Copay Bitcoin wallet. Covered by behavioural scanners like Socket and by pinning dependencies to exact versions.
Malicious maintainers and long-term social engineering. The xz-utils backdoor is the canonical case — two years of patient trust-building by “Jia Tan” before inserting a backdoor into the SSH authentication chain. This category is the hardest to defend because the attacker controls commit access and can hide code in test fixtures and build scripts. Partial coverage from OpenSSF Scorecard (maintainer hygiene signals), behavioural analysis on released artifacts, and SLSA L3 provenance on the build.
Compromised build pipelines. The SolarWinds attack in 2020 modified the Orion build process, not the source code — the compiled binary shipped with a backdoor affecting roughly 18,000 organisations. The Codecov bash-uploader incident in 2021 modified a fetched CI script to exfiltrate environment variables. Covered by SLSA provenance levels, Sigstore signing, and CI/CD hardening (pin actions to commit SHAs, restrict secret access).
Transitive dependency risk. Most vulnerable code does not live in the packages you directly declare — it lives in the ones your dependencies pull in. A full dependency-tree scan is table stakes for every tool in this guide. Reachability analysis (Endor Labs, Snyk, Contrast SCA) adds a second filter that asks whether your code actually reaches the vulnerable function.
The 2025 threat data keeps showing why every layer matters. Socket reported identifying 1,700+ malicious packages linked to a single North-Korean campaign since January 2025, targeting npm, PyPI, Go, and Rust ecosystems simultaneously.
The modern supply chain security tool stack
A 2026-grade supply chain stack has five layers. Each layer maps to one or more threat categories above, and most production deployments run a tool in each.
Layer 1 — SBOM generation. The inventory step. An SBOM is the machine-readable list of every component in a build — you cannot defend what you cannot see. Syft is the open-source default, outputting SPDX and CycloneDX formats.
Trivy and Docker Scout also generate SBOMs as part of broader scanning. US Executive Order 14028 and the EU Cyber Resilience Act make this layer a compliance requirement for many sectors, not just a nice-to-have.
Layer 2 — SCA (CVE scanning). The vulnerability-matching step. Point a scanner at your SBOM or manifest and get a list of known CVEs in direct and transitive dependencies.
Snyk Open Source, Grype, OSV-Scanner, and Trivy all live here. The differences are database breadth (proprietary feeds, NVD, GHSA, OSV, distro-specific), prioritisation (EPSS, KEV, reachability), and fix-workflow depth.
Layer 3 — Malicious-package detection. The behavioural step asks a different question than SCA: not “does this package have a CVE?” but “does this package do anything malicious?”. Socket is the commercial leader with behavioural analysis for npm and PyPI.
The open-source path is OSV-Scanner plus the OpenSSF Malicious Packages feed, which is consumable through OSV.dev. Checkmarx SCA and Veracode SCA now include supply-chain feeds too, through platform acquisitions.
Layer 4 — Reachability analysis. The prioritisation step. Not every flagged CVE is exploitable — the vulnerable function may never be called from your code. Endor Labs reports up to 97% reduction in alerts through function-level reachability.
Snyk Open Source adds call-path reachability for Java and JavaScript, and Contrast SCA takes a runtime approach. This layer is where “hundreds of alerts” becomes “the ten that matter”.
Layer 5 — Build attestation and signing. The build-integrity step asks whether the artifact you are about to deploy is the one that came out of the build you trust. The SLSA framework defines provenance levels L1 through L3, with L2 adding signed provenance and L3 requiring build isolation and verified authenticity. Sigstore provides the tooling: cosign for signing artifacts, fulcio as the short-lived certificate authority tied to OIDC identities, and rekor as the public transparency log.
OpenSSF Scorecard rates dependency projects on 18+ security-hygiene checks, which is the upstream counterpart to build attestation downstream.
On top of these layers you can add dependency-update automation (Dependabot, Renovate) to shrink the exposure window when a CVE lands, and continuous SBOM monitoring (Dependency-Track) to catch portfolio-wide regressions when a new advisory affects a release you shipped months ago.
The practical question is not “which layer matters most?” — it is “which two or three layers am I not running yet?”. Most teams start at Layers 1 and 2 and move outward as the threat model demands.
Key Insight
The practical question is not "which layer matters most?" — it is "which two or three layers am I not running yet?"
Top 8 software supply chain security tools
The tools below are grouped by the layer where they are strongest. Most of them span more than one layer in practice.
1. Socket — malicious-package detection (Layer 3)
Socket leads behavioural malicious-package detection. It analyses what a package actually does — network calls, install scripts, filesystem access, shell execution, obfuscated code — and flags risky behaviour before any CVE is published.
That is the gap traditional SCA cannot see: typosquatting, compromised maintainer releases, and post-install malware. In H1 2025 the Socket Threat Research team documented 1,700+ malicious packages linked to one North-Korean campaign alone, many of which had no CVE.
Socket ships primarily as a GitHub App that posts a security report on every PR that changes dependencies. A CLI (@socketsecurity/cli) covers local scans and non-GitHub CI. Deepest coverage is on npm and PyPI; Go, Maven, Ruby, Cargo, and NuGet get lighter vulnerability + supply-chain analysis.
The Free tier is unlimited for open-source projects. Team starts at $25 per developer per month; Business at $50 per developer per month adds SBOM import/export and SSO. Enterprise is contact-sales.
Best for: JavaScript and Python teams who want proactive malicious-package blocking at PR time, on top of traditional CVE scanning.
2. Syft — SBOM generation (Layer 1)
Syft is Anchore’s open-source SBOM generator, the de-facto standard for Layer 1. It catalogs every package in a container image, filesystem, or archive and outputs SPDX or CycloneDX SBOMs in seconds.
With around 8,400 GitHub stars and active release cadence (v1.42.0 shipped February 2026), it is the tool most SBOM workflows quietly sit on top of. It runs entirely offline, auto-detects dozens of ecosystems (apk, dpkg, rpm, npm, pip, Maven, Go, Ruby, Rust, .NET, PHP), and has an official GitHub Action (anchore/sbom-action).
Syft does not scan for CVEs by itself. The canonical pattern pipes its output into Grype:
syft alpine:latest -o cyclonedx-json | grype
This “SBOM-first” split lets you generate the inventory once and re-scan it as new CVEs are disclosed, without touching the original image. Syft also supports signed SBOM attestations using the in-toto specification, which is the bridge into Layer 5 work.
Best for: Any team that needs SBOMs for compliance (Executive Order 14028, EU CRA) or wants a clean SBOM pipeline feeding the rest of the stack.
3. Grype — SBOM-based CVE scanning (Layer 2)
Grype is Syft’s sister project from Anchore. Where Syft catalogues, Grype matches — it consumes SBOMs (or scans directly) and reports known CVEs against NVD, GitHub Security Advisories, and distribution-specific feeds.
Two properties make Grype a strong fit for a supply chain stack. First, it composes cleanly with Syft for the SBOM-first pattern above. Second, its findings carry a composite 0-10 risk score built from CVSS, EPSS exploit probability, and CISA KEV catalog status — which lets you prioritise patches by real exploit likelihood, not just CVSS headline severity.
Grype is open-source (Apache 2.0), runs as a single Go binary with no daemon, covers 20+ language ecosystems, and accepts CycloneDX, SPDX, and Syft JSON as SBOM input. OpenVEX support lets you suppress findings your security team has already assessed. With roughly 11,500 GitHub stars it is the most-adopted open-source SBOM-first scanner.
Best for: Teams already generating SBOMs with Syft, or anyone who wants focused vulnerability matching with EPSS/KEV-based prioritisation instead of a raw CVSS list.
4. Snyk Open Source — commercial SCA with supply-chain feed (Layer 2 + Layer 4)
Snyk Open Source is the most-adopted commercial SCA, used by 2M+ developers. Its supply-chain relevance comes from three properties that open-source scanners do not match today.
First, a proprietary vulnerability database Snyk reports as roughly 3x larger than NVD, with 92% of JavaScript vulnerabilities disclosed before they appear in NVD. That advance-warning window matters when new malicious-package disclosures hit faster than the CVE process.
Second, automated fix pull requests across GitHub, GitLab, Bitbucket, and Azure Repos. For the “close the window” half of supply-chain defense, this is one of the shorter paths from disclosure to merged patch in CI.
Third, reachability analysis on Java and JavaScript — call-path tracing that filters out CVEs your code does not actually reach. Combined with the Risk Score (12+ contextual factors beyond CVSS), this pushes Snyk into Layer 4 as well.
Free tier covers 200 Open Source tests per month on private repos, unlimited on public. Team starts at $25 per contributing developer per month.
Best for: Teams that want a single commercial SCA covering database breadth, fix-PR workflow, and partial reachability — particularly Java and JavaScript shops.
5. Endor Labs — reachability-first SCA (Layer 4)
Endor Labs is the reachability specialist. Its pitch is simple: flagging every CVE in a dependency tree produces alert fatigue, and most of the flagged vulnerabilities are not exploitable in your code. Endor’s function-level reachability analysis filters the list down to what actually matters.
The reported outcome is up to 97% SCA alert-noise reduction, across 40+ programming languages. In February 2026 Endor Labs acquired Autonomous Plane to extend reachability from application code through to container images — full-stack reachability that understands which packages inside a running image are actually loaded.
Endor is used by OpenAI, Cursor, Snowflake, Netskope, and Atlassian. The platform also covers SAST, secrets detection, container scanning, and malicious-package detection, which is why some buyers consolidate on it rather than stitching four tools together.
Pricing is not publicly listed — Endor is a contact-sales product. For the budget question the SCA tools category and the supply chain attacks guide cover alternatives.
Best for: Engineering organisations drowning in SCA alerts who want reachability to be the default filter, or teams consolidating multiple AppSec tools onto one platform.
6. OSV-Scanner — Google-backed OSS vuln + malicious feed (Layer 2 + Layer 3)
OSV-Scanner is Google’s free, open-source scanner that queries the OSV.dev database — the largest normalized aggregate of open-source vulnerability data, pulling from 30+ ecosystem-specific sources.
Two supply-chain properties set it apart from a plain CVE scanner. First, OSV.dev ingests the OpenSSF Malicious Packages feed, which means OSV-Scanner surfaces known-bad packages (typosquats, malicious releases identified by OpenSSF Package Analysis) alongside conventional CVEs. It is the closest open-source approximation of Socket’s behavioural layer.
Second, guided remediation (currently npm and Maven) analyzes the dependency graph and recommends the minimum set of upgrades ranked by severity, dependency depth, and return on investment. V2 added layer-aware container image scanning for Debian, Ubuntu, and Alpine.
Fully free, no account required, 11+ language ecosystems, and 19+ lockfile formats. The latest v2.3.5 added transitive scanning for Python requirements.txt via the deps.dev API.
Best for: Teams that want the broadest open-source vulnerability database plus a malicious-package feed, especially if guided remediation on npm or Maven matters.
7. Trivy — cross-layer all-in-one (Layers 1 + 2)
Trivy from Aqua Security is the most-starred open-source security scanner on GitHub (34k+ stars) and the broadest single-binary option in the stack. One binary scans container images, filesystems, git repos, VM images, and Kubernetes clusters across four engines: vulnerabilities, misconfigurations, secrets, and licenses.
Its supply-chain contribution is breadth. A single trivy fs . command scans dependency lock files across 11+ language ecosystems (Go, Java, Node.js, Python, Ruby, Rust, PHP, .NET, Dart, Elixir, Swift), and the same binary generates SBOMs in CycloneDX and SPDX formats. The vulnerability database pulls from NVD, GitHub Advisories, and distribution-specific feeds for Alpine, Debian, Ubuntu, RHEL, and Amazon Linux.
Trivy does not do malicious-package behavioural analysis, reachability, or SLSA attestation. What it does do is let a small team cover Layers 1 and 2 with a single CI step and no platform:
trivy fs --severity HIGH,CRITICAL --exit-code 1 .
It is the default scanner inside Harbor (CNCF registry) and is widely used as the first gate in CI pipelines.
Best for: Teams that want broad cross-layer coverage (containers + IaC + deps + SBOM) with zero platform and one binary.
8. Sigstore + SLSA + OpenSSF Scorecard — build attestation and hygiene (Layer 5)
The final entry is a composite because the three projects work together. None of them is “a tool you install” in the same sense as the scanners above — they are standards and infrastructure that make build integrity verifiable.
Sigstore is the signing and transparency stack. cosign is the CLI that signs and verifies container images, blobs, and SBOM attestations. fulcio is the certificate authority that issues short-lived certificates bound to OIDC identities (GitHub, Google, etc.).
rekor is the public transparency log that records every signing event so third parties can audit it. In practice, teams use cosign in CI to sign release artifacts without managing long-lived signing keys.
SLSA (Supply-chain Levels for Software Artifacts) is the build-provenance framework — an OpenSSF project. It defines levels L0 through L3+, with L1 requiring automated provenance, L2 adding signed provenance generated by a hosted build platform, and L3 requiring build isolation so provenance cannot be forged by a compromised build job. GitHub Actions’ slsa-github-generator is one of the common ways to produce SLSA L3 provenance automatically.
OpenSSF Scorecard rates an open-source project on 18+ security-health checks — branch protection, code review, dependency update policy, signed releases, fuzzing, and more. It runs as a CLI or GitHub Action and scores each check 0-10. For dependency-vetting workflows, Scorecard is the upstream hygiene signal that complements downstream behavioural analysis.
All three are free and open-source. The right time to adopt them is when the answer to “can you prove this artifact came from this commit on this build system?” becomes a question your customers or regulators actually ask.
Best for: Teams that ship software others consume, teams under SLSA-aligned compliance pressure, and anyone whose threat model includes build-pipeline compromise.
Feature comparison
The table below maps each tool to the layers it covers and the threat categories it is strongest against.
| Tool | SBOM gen | CVE scan | Malicious pkgs | Reachability | Attestation | License |
|---|---|---|---|---|---|---|
| Socket | Business tier | Via feeds | Yes (deep, npm/PyPI) | Precomputed (Team+) | No | Commercial (free for OSS) |
| Syft | Yes (SPDX/CycloneDX) | No | No | No | in-toto attest | Apache 2.0 |
| Grype | Output only | Yes (NVD/GHSA/distro) | Via feeds | No | No | Apache 2.0 |
| Snyk Open Source | Yes | Yes (proprietary + NVD) | No (CVE-based) | Call-graph (Java/JS) | No | Freemium |
| Endor Labs | Yes | Yes | Yes | Yes (function-level) | Partial | Commercial |
| OSV-Scanner | Consumes SBOMs | Yes (OSV.dev) | Yes (OpenSSF feed) | Guided remediation | No | Apache 2.0 |
| Trivy | Yes (SPDX/CycloneDX) | Yes (NVD/GHSA/distro) | Via OSV/GHSA | No | No | Apache 2.0 |
| Sigstore + SLSA + Scorecard | No | No | No | No | Yes (L1-L3+) | Apache 2.0 / OpenSSF |
A few decisions fall out of this table in practice.
If you run only one open-source tool, it is Trivy (breadth) or Grype (depth). If you run only one commercial tool, it is Snyk or Endor Labs depending on whether your pain is database/fix-PR workflow or alert noise. Socket is additive to whatever you already run — nothing else fills the behavioural-malicious-package slot at the same depth on npm and PyPI.
How to build your supply chain stack
The right stack depends on which threat category you are most worried about, not which tool has the best marketing page. Use the framework below.
If your main threat is known CVEs in open-source dependencies — start with SCA. The open-source path is Trivy or Grype (paired with Syft for SBOMs). The commercial path is Snyk Open Source — either covers Layer 2 well. Add Dependabot or Renovate to automate the fix PRs.
If your main threat is malicious packages and typosquats — add behavioural detection. Socket is the shortest path on npm and PyPI. The open-source alternative is OSV-Scanner, because it pulls in the OpenSSF Malicious Packages feed through OSV.dev. This layer is additive, not a replacement — it catches what SCA cannot.
If your main problem is alert fatigue from too many CVEs — add reachability. Endor Labs is the reachability specialist with up to 97% alert reduction. Snyk’s reachability covers Java and JavaScript if you are already on Snyk. Reachability only pays off if your SCA is already generating noise you cannot ignore — it is a Layer 4 problem that presupposes Layer 2 is in place.
If your threat model includes the build pipeline itself — add SLSA and Sigstore. SolarWinds-class attacks are not caught by scanning source or dependencies; they are caught by proving that the artifact you ship is the one the trusted build produced. Start at SLSA L1 (automated provenance) and move up as the threat model justifies.
If you are shipping software to regulated sectors — start at SBOM. Executive Order 14028 and the EU Cyber Resilience Act make SBOM a table-stakes deliverable, and Syft handles this at zero cost. Feed the SBOMs into Dependency-Track for continuous monitoring across the portfolio.
A realistic 2026 starter stack for a mid-sized engineering org looks like this:
- Layer 1: Syft in CI, output archived per build
- Layer 2: Grype consuming the Syft SBOMs (open-source) or Snyk Open Source (commercial)
- Layer 3: Socket as a GitHub App, or OSV-Scanner with the OpenSSF Malicious Packages feed
- Layer 4: Add later — Endor Labs or Snyk reachability when Layer 2 produces more alerts than the team can triage
- Layer 5: cosign + SLSA provenance on release artifacts when customers or compliance demand it
For deeper tool-by-tool coverage the SCA tools category hub and the open-source SCA roundup each take a narrower slice.
