No single tool stops every software supply chain attack. Dependency confusion is best handled by registry configuration, a compromised maintainer by release controls and inventory, a build system compromise by build integrity and provenance, and a malicious update by update policy plus monitoring. Match the control to the attack class before you shop.
Four classes, defined
A software supply chain attack is any attack that reaches you through software you consume or the process that produced it, instead of through your own code. The SLSA threat model splits this into source, build, dependency and package threats, and notes that some of them sit outside what its levels address. For buyers, four practical classes cover most headlines.
- Dependency confusion: a public package is published under the same name as a private one, and a build tool picks the public one.
- Compromised maintainer: an attacker takes over a legitimate publisher account or hands, then ships a bad version under a trusted name.
- Build system compromise: the vendor's build pipeline is altered, so a malicious artifact is produced from clean source.
- Malicious update: a bad release reaches you through the normal update channel, whatever the cause upstream.
What fits each class
| Attack class | Where it enters | Controls that fit | Tool category to evaluate |
|---|---|---|---|
| Dependency confusion | Package resolution | Scoped or single-source registries, name reservation | Registry or proxy settings, dependency scanning that flags unexpected sources |
| Compromised maintainer | New version of a trusted package | Short-lived publish credentials, release delay, lockfiles | Inventory, monitoring, policy gates on new versions |
| Build compromise | Vendor build | Provenance, hardened builders | Vendor assurance, attestation checks |
| Malicious update | Update channel | Staged rollout, update delay, rollback | Continuous monitoring, asset inventory |
Notice that the right column is mostly not a scanner that matches known CVEs. A package that is malicious but has no CVE will not show up in a CVE feed at all. Ask any vendor how they handle packages that are malicious rather than merely vulnerable.
How to use this when buying
Start from your own exposure. If you run private packages, class one matters most and the fix is largely configuration you control. If you depend on a few critical open source packages, class two argues for inventory and a delay before adopting new versions. If you buy a lot of commercial software, class three is a supplier assurance question, not a scanner question.
Then ask each vendor three things: which classes they address, how, and how they prove it. A claim that covers all four with one feature deserves a follow up.
Try it yourself
Open the demo and look at how a dependency inventory is built. Every class above starts with knowing what you run.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies and gates, and zero-day discovery, which cover the inventory and monitoring side of these classes. Registry configuration and vendor build integrity remain your own controls. You can run a free scan to see an inventory of one project.
Quick check
Can one tool cover all four attack classes?
Not on its own. Each class enters at a different point, so you need a mix of configuration, process and monitoring.
Why is a CVE scanner not enough for a compromised maintainer?
A malicious release usually has no CVE when it first appears, so a scanner that only matches CVE records has nothing to match.
Sources
Last reviewed: 19 October 2026.
