When risk_state is none and compromised is false: catching the Mastra-class provenance drop

Most supply chain checks ask two questions: is there a CVE, and is this version a known malicious publish. Both can return clean while the publish is still wrong.
That is the Mastra-class case. A package that normally ships with npm provenance attestation publishes a version without it. risk_state is none. supply_chain.compromised is false. Nothing in the traditional signals fires. The missing attestation is the signal.
Attestd now returns that as supply_chain.provenance.
Tri-state semantics#
| Value | Meaning |
|---|---|
true | This version has a valid npm attestation |
false | The package has a provenance baseline, but this version lacks attestation |
null | No baseline known. Most packages never publish provenance. Absence is not a signal |
false is the alert condition. null is not.
The baseline is permanent and machine-derived. The first time any version of a package returns a non-empty attestations array from the npm registry, Attestd records a baseline for that package. There is no human curation step. If a later version drops provenance, the field returns false.
Why this matters#
Compromised publishes often skip the CI path that produces attestations. Account takeover, stolen tokens, and manual npm publish outside the trusted workflow all produce the same pattern: package content looks normal enough to pass CVE and malware feeds, and provenance is missing relative to prior releases.
Branching on provenance === false catches that class without waiting for an OSV MAL advisory or a registry yank.
Example response shape#
{
"product": "@example/core",
"version": "1.4.2",
"supported": true,
"risk_state": "none",
"supply_chain": {
"compromised": false,
"sources": [],
"provenance": false
},
"supply_chain_monitored": true
}
CVE layer clean. Compromise layer clean. Provenance baseline drop. That combination is actionable.
How to use it#
In CI, fail on the alert state:
- uses: attestd-io/check-action@v1
with:
api_key: ${{ secrets.ATTESTD_API_KEY }}
product: "@your-org/package"
version: "1.4.2"
fail_on_provenance_missing: true
In application code:
const result = await client.check("@your-org/package", "1.4.2");
if (result.supplyChain?.provenance === false) {
throw new Error("Provenance baseline drop");
}
Do not treat null as a failure. Most of the registry has never published provenance. Failing on null creates noise and trains teams to ignore the signal.
Scope#
npm only for v1. PyPI PEP 740 coverage is still too sparse for a reliable baseline. Provenance is checked inline on /v1/check for monitored npm packages (24h cache) and warmed in the background sweep for watchlist packages. No LLM involvement. Registry HTTP only.
Coverage#
supply_chain.provenance ships in the Attestd API, @attestd/sdk 0.6.0, attestd 0.6.0, and check-action 1.2.0. Field docs: response fields. Supply chain guide: supply chain.