Block trust downgrades
Block releases that use weaker publishing trust evidence than earlier releases of the same package.
A package can establish a trusted publishing process and then release a later version through a weaker path. That change can be legitimate, but it can also indicate that a maintainer account or publishing token was used instead of the established release workflow. The trust-downgrade selector lets you review or block that regression.
The selector currently supports npm. The rule name is ecosystem-neutral so the same policy can cover other ecosystems if their registries expose comparable trust evidence in the future.
How matching works
For the selected release, the firewall compares its publishing trust evidence with releases of the same package published earlier. Trust is ordered from strongest to weakest:
- Trusted publisher
- Provenance attestation
- No trust evidence
The selector matches when any earlier release has stronger evidence. For example:
| Earlier release | Selected release | Match |
|---|---|---|
| Trusted publisher | Provenance attestation | yes |
| Provenance attestation | No trust evidence | yes |
| Provenance attestation | Provenance attestation | no |
| No trust evidence | Provenance attestation | no |
Comparison uses publication date, not version number. Prereleases do not establish the trust baseline for a stable release. A match identifies a change in publishing evidence; it does not by itself prove that the release is malicious.
Add the rule
On an npm firewall, open Rules and create a rule:
- Execution phase: filter versions
- Selector function: Trust downgrade
- Effect: block and log
As JSON:
{
"id": "block-trust-downgrades",
"executionPhase": "versions",
"selector": { "function": { "name": "trust-downgrade" } },
"ruleEffect": { "block": true, "log": true },
"description": "Block releases with weaker publishing trust"
}A versions-phase match removes the release during resolution. The same rule is also checked when a client fetches that release directly, so an exact lockfile URL cannot bypass it.
Test with log first
If you need to assess existing packages before blocking, start with log on and block off. Review matches for planned changes to publishing workflows. Enable block after you have accounted for legitimate changes.
Verify
Request metadata or an artifact for a package with a downgraded release, then inspect the logs:
bsfw logs --firewall <firewall-id>Confirm the entry contains the rule ID, package, and version. If a publishing change is expected, add an exception scoped to that package and version rather than disabling the rule.
Related
- Concept: Rule evaluation
- Reference: Selector functions, Rules and selectors
- How-to: Manage exceptions, View logs