Treat it as a change that needs an explanation, not as proof of compromise. Compare the new version with earlier ones, look for a stated reason such as a pipeline change, and hold the upgrade until you have one. A drop in provenance is a stronger signal than never having had it.
Why the change matters more than the absence
Most packages have never published build attestations, so absence alone tells you little. A package that always did and then stopped has changed how it ships. Registries describe what an attestation gives you. npm says provenance publicly links a package to its source code and build instructions, so developers can verify where and how it was built before downloading. PyPI says attestations bind a release file to a cryptographic digest and let users verify it was attested by a particular identity, such as a GitHub Actions workflow.
If that link disappears, the artifact may have been published by hand or from a different place. The cause can be dull, such as a maintainer publishing from a laptop to rush a fix, or a CI migration. It can also be less dull. You cannot tell from the signal alone.
How to check
- List the last several versions and note which carry attestations. The deps.dev API shows SLSA provenance data for npm versions, and an attestations field for other systems.
- Check the project's release notes, changelog and recent issues for a reason: a pipeline change, a token problem or a registry change.
- Look at the publisher. Did the publishing account change, or did the maintainer list change around the same time?
- Diff the new version against the last attested one. Focus on install scripts, new dependencies and any obfuscated code.
- Look at how publishing is configured. npm trusted publishing lets a package accept publishes from a specific workflow using OIDC, which removes long-lived tokens. A project that adopted it and then published outside it is worth asking about.
- Ask in the project's issue tracker, politely and in public, so the answer helps others.
Decide what to do
| Finding | Reasonable action |
|---|---|
| Clear, plausible explanation and clean diff | Upgrade, note it |
| No explanation, clean diff | Wait, ask, retry in a few days |
| No explanation and new install script or dependency | Do not upgrade; escalate for review |
| Package already installed in your builds | Check where it runs and whether secrets were in reach |
What this check cannot do
A version with provenance is not automatically safe, and a version without it is not automatically bad. Provenance speaks to origin, not intent. Use it to decide how much manual review a change needs, not to skip review.
Make it routine
Record, for each critical dependency, whether it publishes attestations. When a version arrives without one, your tooling can flag the change. That turns a rare, odd event into a short review instead of a surprise.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how change over time is surfaced after a first baseline.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, continuous monitoring workflows, and policies and gates. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a version without provenance malicious?
No. There are many innocent reasons. Treat it as a question to answer before upgrading.
Can I require provenance for every dependency?
Few packages publish it today, so a blanket rule will block a lot. Apply it first to critical, high-access packages.
Sources
- npm Docs: Generating provenance statements
- npm Docs: Trusted publishing for npm packages
- PyPI Docs: Digital attestations
- deps.dev API v3 documentation
Last reviewed: 19 October 2026.
