Announcement

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

RobertUpdated Jul 22, 20263 min read
Attestd supply_chain.provenance tri-state: true for attested versions, false when a provenance baseline drops, null when the package never published provenance.

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#

ValueMeaning
trueThis version has a valid npm attestation
falseThe package has a provenance baseline, but this version lacks attestation
nullNo 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#

json
{
  "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:

yaml
- 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:

ts
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.