Check P12 · provenance family · severity LOW · automatic · one of the 12 npm and PyPI package checks
Maps to OWASP LLM03 A missing build attestation is an evidence gap: the check reports that where the package was built cannot be proven, not that it was tampered with.
The question this check asks: can the registry say where this version was built? npm lets a publisher attach a build attestation — a signed statement of the repository and workflow that built the package. This check reports whether there is one.
An attestation ties a published version to the build that made it, which is the evidence P4 can only approximate by comparing names. It is also rare: most packages, including most of the popular ones, carry none. A check that warned on its absence would warn on nearly everything, so this one states the fact and leaves it there.
On npm the latest version's record is read for attestations. pkg-provenance — the latest version carries a build attestation — and pkg-no-provenance — it carries none — are both notes at 0 points. Neither moves the verdict.
On PyPI this check is skipped: PyPI publishes no attestation in the JSON this roster reads. The skip is listed on the report and never withholds a PASS.
None in the usual sense: the check never raises the verdict. A reader who treats “no build attestation” as a warning will find it on most packages; it is a fact about how the package was published, not a finding about the package.
Whether the attestation is valid. Its presence is read; it is not verified against the repository or the build. PyPI attestations. Not in the record read. The package's code is not read.
Scope, the same on every page of this roster: RepoGates does not see git clone, package managers or curl — outside Claude Code with the RepoGates plugin, whose hook refuses a clone or install that names a blocked repository on the command line, before it runs. The hook sees Bash tool calls in that one client and nothing else; a package named on the line (npm install express, pip install flask, npx, npm create) is judged by its own verdict under this roster, its declared repository riding along. Direct dependencies named on the command line only; transitive dependencies and lockfiles are not resolved. A package added by editing package.json or requirements.txt and installed later is not a line the hook judges. Edit and Write are read for one thing only — an API key about to be saved — checked on the machine and never sent; that guard asks, it never denies. This roster reads what npmjs.org and pypi.org publish about a package — its record, its release history, its declared repository — and never the package's code or what it installs after it. A registry other than those two (a --registry or --index-url on the line) is asked about, not assessed. A package the registry no longer serves is not assessed, never a pass. A PASS means nothing matched on what was read.
npm view NAME dist.attestations
npm audit signaturesnpm audit signatures, run in a project, verifies the signatures and attestations of what that project installed.
Why is a missing attestation not a finding? Because most npm packages, including most of the popular ones, carry none. Warning on its absence would warn on nearly everything; the check records the fact as a note and leaves the verdict alone.
Does RepoGates verify the attestation? No. The check reads whether the registry's record carries one. Verifying it against the repository and the build is not done on this tier.
Why is PyPI skipped? Because PyPI's project JSON, which this roster reads, carries no attestation. The skip is listed on the report and is never a pass.
P4 Name matches its source · P2 Source repository · V6 Package signature.
Add RepoGates to Chrome Pricing
Sources for this page: the rule and weights from the product's own roster and scoring tables.