Valid provenance does not certify safe code

Five malicious versions across four @asyncapi packages reached npm on July 14, 2026, carrying valid provenance attestations. Microsoft's incident analysis describes legitimate GitHub Actions release workflows publishing packages from unauthorized source commits.

The attestation was not a counterfeit. That is precisely why this incident belongs in a dependency review: the evidence about how a package was built can be genuine while the package itself is hostile.

I would keep provenance verification and remove the shortcut that treats its success as permission to merge. The failure was not having a receipt. It was asking the receipt to stand in for a code review.

The receipt points to the code

GitHub's 2023 introduction to npm provenance describes a verifiable connection between the published artifact, its source repository and commit, and its build instructions. Provenance therefore does say something about the inputs. It gives reviewers a way to find and inspect them; it does not pronounce them benign.

StepSecurity's investigation traces the generator-family packages to the next branch and the specs release to a separate repository's master workflow. It inspected attestations identifying the workflow, commit and run. Microsoft's account also describes an alpha release before the stable specs release. This was not one universal branch rule.

The lesson I take from that trail is to use the attestation as the beginning of an investigation. Follow it to the change and the release trigger. A familiar repository name is not an explanation for why a particular commit should be trusted.

The payload waited for import

Microsoft reports that the loader ran when the package was imported or required, rather than through an npm installation lifecycle hook. Suppressing those hooks with --ignore-scripts did not neutralize that trigger. This does not mean static inspection at installation time is useless; it means a hook-specific mitigation cannot cover every execution path.

For a dependency update, I want the proposed review to cover the published package's entry points and changed files, not just its install scripts. If someone runs behavioural checks, they belong in an isolated environment without production credentials. The check should state what actually ran and what it could not observe. I have not executed these malicious packages.

As an illustration, an update bot could attach a valid provenance result and a green test suite while never exercising the altered entry point. Neither attachment would answer the missing question. The review still needs to explain the changed execution path and why the selected tests cover it.

Give the update an accountable decision

My proposed merge rule is to require a reviewer or policy to connect three things: the verified origin, the actual package changes, and the evidence for accepting those changes. A diff summary can help a reviewer navigate; it should not become another decorative green checkbox.

For high-impact dependencies, a release-age hold can provide time for more scrutiny. I would make exceptions explicit for urgent security fixes and avoid treating any fixed waiting period as a safety guarantee. Waiting does not inspect code.

The practical change for the next platform review is small: find every control labelled “verified provenance” and write down the decision it is allowed to support. Keep it for source-and-build traceability. Pair it with a separate decision about the package contents and the authority those contents will receive.

Verify the build receipt, then review what it points to. A genuine provenance statement is evidence to use, not permission to stop looking.