"Prevents supply chain attacks" is a marketing phrase, not a technical one. It can mean the product blocks a bad package before install, detects one after it arrives, or helps you respond once it is running. Ask which of the three it does, for which attack types, and at which point in your pipeline.
Three verbs, three jobs
| Verb | What it does | Where it acts | Example question |
|---|---|---|---|
| Block | Stops a bad component from entering | Pull request, registry proxy, install time | What exactly is blocked, and on what evidence? |
| Detect | Finds a bad component already present | Scheduled or continuous scans | How soon after publication does it appear? |
| Respond | Limits damage and speeds recovery | Inventory, alerts, fix workflow | How fast can I list every place it is used? |
A product may do all three, one or two. The phrase "prevents" is accurate only for the first.
Attack types matter
Supply chain attacks come in several forms, and a control that suits one may miss another. Typosquatted packages, compromised maintainer accounts, malicious updates to trusted packages, tampered build systems and poisoned dependencies in a lockfile are different problems. A scanner that checks known vulnerabilities, for example, will not stop a brand new malicious release that has no advisory yet.
Ask the vendor to name the attack types its blocking covers and the ones it does not. A confident vendor will list limits.
What to ask for
- The blocking rule. On what signals does it block: age of a release, advisory data, behaviour analysis, a policy you wrote?
- The bypass path. Who can override a block, and is the override recorded?
- The detection delay. Between publication of a bad release and an alert, what is the typical gap, and how is it measured?
- The response data. Can it answer "where do we use this package version?" in minutes?
- The failure mode. If the service is unavailable, does your build fail open or closed?
Write these answers down. They become your acceptance criteria.
Test it with a safe scenario
Never test with live malware. Use a package you control, publish a harmless test release, and see how the product treats it under your policy. Try a new version of an existing dependency, an unknown package name close to a real one, and a lockfile change with no matching manifest change. Record what is blocked, what is flagged and what passes silently.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for where the gate acts, what evidence it shows and who can override it.
Where Safeguard fits
Safeguard offers policies, gates and guardrails, dependency and SBOM scanning, zero-day discovery and an asset inventory, which map to the block, detect and respond jobs. Judge each on your own repositories, starting with the free scan at gold.safeguard.sh/scan.
Quick check
Can any product prevent every supply chain attack?
No. Controls reduce exposure to defined attack types. Ask which types are covered and which are not.
Is detection worse than blocking?
Not necessarily. They serve different moments. Detection helps with things already in your estate, which blocking at the gate cannot reach.
Last reviewed: 19 October 2026.
