Several beliefs about supply chain attacks lead buyers to the wrong purchase: that signed software is safe, that a CVE scan finds malicious packages, that a lockfile fixes everything, or that provenance means safety. The primary documentation says otherwise on each point.
Myth 1: Signed software is safe software
Fact: A signature shows who signed. CISA's advisory on the SolarWinds Orion compromise states the malicious DLL was signed with the vendor's legitimate code signing certificate. Signing matters, but it is not a clean-build proof.
Myth 2: A CVE scan will find malicious packages
Fact: CVE scanning matches versions to published vulnerability records. A newly published malicious release usually has no record yet. You need other signals, and you need to ask how a vendor gets them. In the xz case, the compromise received CVE-2024-3094 and CISA's alert named versions 5.6.0 and 5.6.1, but that is a record created after discovery.
Myth 3: A lockfile fixes dependency problems
Fact: The npm ci command installs from the lockfile and errors on a mismatch, which prevents surprise upgrades. It records whatever version you chose, good or bad, and does not help on first resolution of a confused name.
Myth 4: Provenance means the package is safe
Fact: npm states provenance does not guarantee a package has no malicious code. It links a package to its source and build.
Myth 5: Dependency confusion is a scanner problem
Fact: It is mostly a resolution and configuration problem. The pip documentation warns against using an extra index to find packages that are not in the main repository, because that is a dependency confusion risk. Fix the configuration, then use scanning as a second check.
Myth 6: This only affects big vendors
Fact: Any project that installs packages or runs shared pipelines is in the path. GitHub's hardening guide notes that anyone with write access to a repository can read its secrets, which is the kind of everyday access an attacker through a workflow would inherit.
Using the facts when you buy
| Claim you may hear | Question to ask |
|---|---|
| "We verify signatures" | What happens when a signed artifact is bad? |
| "We cover all supply chain attacks" | Which classes, by what mechanism? |
| "We detect malware" | From which signals, how soon after publication? |
| "We support provenance" | Verified or just displayed? |
Quick check
What is the most common wrong assumption?
That one control, signing or scanning, covers all attack classes. Each addresses a different entry point.
Where should I start?
With an inventory of what you run, since every response step depends on it.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis, policies and gates, and zero-day discovery. The free scan is a no cost way to see an inventory.
Sources
- CISA AA20-352A, SolarWinds Orion compromise
- CISA alert on XZ Utils, CVE-2024-3094
- npm ci reference
- npm Docs, Generating provenance statements
- pip install reference
- GitHub Docs, Security hardening for GitHub Actions
Last reviewed: 19 October 2026.
