Six of your forty direct npm dependencies publish provenance. What policy do you set?

## Start with the arithmetic, honestly Six out of forty is roughly the shape of a real dependency set today, and it is worth saying out loud in an interview rather than pretending the estate is uniform. The forty direct dependencies also pull in a transitive graph that is an order of magnitude larger and where coverage is worse still. Any policy that assumes coverage will be complete is a policy about a different codebase. ## Why the obvious policies both fail **"Require provenance on everything."** Thirty-four builds break on the first run. The team's realistic options are to vendor thirty-four packages, drop them, or turn the gate off — and they will turn the gate off. A control that is switched off on day two is worse than no control, because the org now believes it has one. **"Report coverage, enforce nothing."** A dashboard showing 15% is produced monthly, read by nobody, and the six packages that actually publish verifiable origin material are installed with exactly as little checking as the thirty-four that do not. You have paid for the reporting and bought no security. ## The split policy ### For the six: a real gate Verify, and verify *against an expectation*. A bare "the signature is valid" result means somebody was authenticated and signed something. The gate must assert the source repository and the workflow you expect for each package, and fail the build when the attestation names something else. That is the difference between a check that catches a hijacked publish and a check that catches nothing. This gate is cheap to keep green, because those six already publish provenance on every release. The cost only shows up when something is genuinely wrong, which is the definition of a well-placed control. ### For the thirty-four: enforce what exists - **Lockfile integrity hashes.** These give *continuity*, not origin: the artifact you install today is byte-identical to the one you resolved originally. That is a real property and it is enforced by default. It is not provenance — if the first resolution was already malicious, the hash faithfully pins the malice — but it removes the "silently swapped later" class. - **One controlled ingestion point.** Everything enters through a single proxy or mirror, so there is exactly one place where a check *can* be made, and where trust material must be preserved rather than stripped. - **A recorded, dated exception per package.** Not a blanket waiver. The list is the artifact you re-read in six months, and each row is a candidate for removal as upstream coverage improves. ### Two states, never one The single most important design decision is reporting **unverifiable** and **failed** as distinct results. | Result | Meaning | Response | | --- | --- | --- | | Verified, identity matches | Origin confirmed | Proceed | | Verified, identity unexpected | Origin is not who you thought | Stop | | Failed to verify | Material present, does not check out | Stop, investigate | | No attestation | Nothing was published | Record, do not block | Collapsing rows three and four is how a team learns that this alert always means nothing. ## The intermittent-publisher problem A harder case than "never publishes": a maintainer who cuts normal releases from CI and hotfixes by hand from a laptop. Now provenance exists for some versions and not others, and a consumer genuinely cannot distinguish "built off-pipeline in a hurry" from "tampered with". A hard gate blocks precisely the hotfix release you most urgently want to ship, which is the worst possible moment for a control to fire. The pragmatic answer is to allow the gap but alert on it — a transition from *has provenance* to *no provenance* for a package you were already verifying is a meaningful signal even when the explanation is mundane. And if it is your own package, fix the publishing path so every release takes one route. Inconsistent publishing is the upstream's bug, and it destroys the value of the attestations they do publish. ## Raising coverage You cannot mandate anything to maintainers you do not employ. What actually works: - File the issue or send the PR upstream, especially where the project already builds in a supported CI provider — enabling provenance there is often a small change. - Prefer packages that publish it when you have a genuine choice between comparable options. - Make sure the packages *you* publish carry provenance, consistently, on every release. That is the only part of the graph you fully control, and it is what you owe the consumers downstream of you. ## What to say when asked "so are you covered?" The honest senior answer: six dependencies have verifiable origin and are gated on it; thirty-four have byte-continuity and a recorded exception; the number is tracked and is expected to rise. That is a defensible position. "We require SLSA provenance" said about an estate where it is enforced nowhere is not.