Supply chain security: lockfiles, provenance and the dependency you did not choose

01The four ways a package turns hostile

Supply chain compromise is not one threat. It is four distinct mechanisms with different defences, and conflating them is why teams buy a scanner and remain exposed. Knowing which one you are defending against tells you which control actually helps.

Maintainer account takeover publishes malicious code under a name you already trust, so your lockfile pins nothing useful once you upgrade. Typosquatting relies on you installing the wrong name in the first place. Dependency confusion exploits resolution order between your private registry and the public one. And the transitive case - the package you did not choose, pulled in four levels deep - is where most of the real exposure sits, because nobody reviewed it and nobody knows it is there.

02Lockfiles do less than you think

A lockfile pins exact versions and integrity hashes, which guarantees that everyone installs the same bytes. That is genuinely valuable and it is where most teams stop. What it does not do is tell you anything about whether those bytes are safe, and it does not protect you at the moment of the upgrade - which is precisely when a compromised version enters.

The control that adds real value is treating lockfile changes as reviewable code. A dependency bump that adds nine new transitive packages should be visible in the diff and should require someone to look. Most teams auto-merge these because the bot opens forty of them a week, and the volume is exactly why an attacker targets that path. If your policy is to auto-merge patch updates, at minimum require that the set of package names is unchanged.

03Install-time scripts are the fastest path to damage

The overwhelming majority of real-world npm compromises have used postinstall scripts, because they execute automatically on every developer laptop and CI runner that installs the package, before any of your code runs and before any test executes. The payload does not need your application to call the library. It just needs you to type install.

Disabling lifecycle scripts globally and maintaining a small allow-list for the handful of packages that genuinely need them - native compilation, browser binaries - is the single highest-leverage change available. It takes an afternoon to find the exceptions and it removes the mechanism entirely rather than trying to detect the payload.

• Set `ignore-scripts=true` and allow-list the packages that break.
• Run installs in CI with no cloud credentials and no registry write tokens in the environment.
• Deny outbound network from the install step; a package that phones home should fail loudly.
• Never run `npm install` on a developer machine that holds production credentials.

04Provenance answers a different question to scanning

Vulnerability scanning tells you that a package version has a known CVE. Provenance tells you where the artefact came from - which source commit, built by which workflow, on which runner. These answer different questions, and only the second one helps with malicious code, because malicious code does not have a CVE assigned when it is published.

Signed provenance attestations let you verify that the published artefact was built from the public repository you think it was, rather than uploaded from a laptop with a stolen token. Adoption is still uneven across ecosystems, so treat it as a preference signal when choosing between comparable packages rather than a hard gate you can enforce today. Where you publish artefacts yourself, generate provenance now - it costs almost nothing in a hosted CI workflow.

05SBOMs are inventory, not security

An SBOM is a list of what is in your build. It has no defensive effect by itself, and teams that generate one to satisfy a customer questionnaire and then never query it have bought a compliance artefact rather than a control. The value appears only at the moment a new compromise is disclosed and someone asks whether you are affected.

That value is real and it is measured in hours. The teams with a queryable SBOM per deployed artefact answer 'are we running the affected version' in minutes. The teams without one spend a day grepping repositories, and they usually miss a service. Generate SBOMs at build time, store them alongside the artefact, and make sure someone can actually query across all of them - that last part is what most implementations skip.

06A proportionate starting set

You cannot review twelve hundred packages, so do not pretend to. Concentrate effort on the boundary where new code enters: adding a direct dependency, and upgrading anything. Everything else is monitoring.

In practice this is four things - disable install scripts, proxy all installs through a registry you control, require human review on any lockfile change that adds package names, and keep a queryable inventory of what is deployed. None of them requires a vendor, all of them survive contact with a real delivery schedule, and together they cover the mechanisms that have actually been used in the field.