An organisation wants to reduce software supply-chain risk. What actually reduces it, in what order, and which popular measures provide less than they appear to?

The threat model, stated properly

Supply-chain risk has several distinct forms, and conflating them produces misdirected effort:

• A compromised upstream dependency — a legitimate package that becomes malicious, through account takeover or a hostile maintainer.
• A typosquatted or confused dependency — a package resolved from the wrong source, including dependency confusion where an internal name is claimed publicly.
• A compromised build system, which is the highest-impact case: the source is clean, the artefact is not, and no amount of source review detects it.
• A compromised artefact in transit or at rest in a registry.
• A vulnerable but honest dependency, which is a patching problem rather than an attack.

What reduces risk, in order of value

1. Pin and verify dependencies by cryptographic hash, with a committed lockfile. This eliminates the entire class of "the package changed underneath us" and is close to free. It is the highest-value control and it is frequently absent.
2. Control resolution: an internal proxy or mirror with explicit allow-listing of sources, which removes dependency confusion and typosquatting structurally rather than by vigilance.
3. Secure the build system as a production system. Ephemeral, isolated build environments; no persistent credentials on builders; least-privilege access to signing keys; and no ability for a pull request from a fork to run with secrets. A build system with standing access to production credentials is the softest target in most organisations.
4. Build provenance: signed attestations recording what source produced what artefact, on which builder, with which inputs — verified at deployment. This is what makes the build system's integrity checkable rather than assumed.
5. Reproducible builds where feasible, so an artefact can be independently rebuilt and compared. Expensive and the strongest available evidence.
6. Reduce the dependency count. The most effective long-term control and the least popular: every dependency is a trust relationship, and a large fraction are trivial and replaceable.
7. Patch promptly, with automation, since most realised harm comes from known vulnerabilities rather than novel attacks.

What provides less than it appears

• An SBOM by itself. Knowing what is in the artefact is necessary and does nothing on its own — an inventory is not a control. Its value is entirely in what consumes it: vulnerability matching, policy enforcement, and rapid answers when a widely-used package is compromised. An SBOM generated and stored unread is compliance theatre.
• Vulnerability scanning without reachability analysis, which produces thousands of findings, most in code paths never executed, and trains teams to ignore the output — the same dynamic as alert fatigue, with the same consequence.
• Signing without verification. Signatures that nothing checks at deploy time are metadata.
• Reviewing dependency source code, which does not scale and is not what most compromises would have been caught by anyway.
• Blocking all new dependencies through a review board, which is routed around rather than followed.

The organising principle

Assume compromise and limit consequence. Even with every control above, a compromised dependency is possible. So the durable investments are runtime least privilege, network egress restriction from build and production environments, secrets that are short-lived and narrowly scoped, and the ability to detect and revoke quickly.

A compromised dependency in a workload with no credentials and no egress is a much smaller event than the same dependency in a workload with a long-lived cloud administrator key — and that difference is architecture, not scanning.