Warn in pull requests when an npm package loses attestation/provenance?

[martincostello]

Tell us more.

As part of CVE-2025-54313, compromised versions of eslint-config-prettier were published to npm.

One of the indicators of compromise in this incident was that the new versions of the packages had no attestations/provenance in npm compared to the previous releases.

These are visible to users here as a green tick in npmjs.org:

The compromised versions have been since taken down, but they did not have these ticks.

Via the npm registry, this information is exposed via the dist.attestations property.

For example for eslint-config-prettier@10.1.8 this is:

"attestations": {
  "url": "https://registry.npmjs.org/-/npm/v1/attestations/eslint-config-prettier@10.1.8",
  "provenance": {
    "predicateType": "https://slsa.dev/provenance/v1"
  }
}

To aid in user identification of such issues, it may be beneficial for Renovate to include a warning in the pull request description if an npm package update from version X to Y loses the attestation for the user to exercise caution and investigate further.

A possible disadvantage of adding this is that if renovate doesn't already do a registry call for the previous dependency version, it will need to be added in order to determine if the attestation was lost in the case where the updated package isn't attested. In the case of the new version being attested, this isn't necessary.

There may be legitimate reasons to lose attestation (e.g. moving from GitHub Actions CI/CD to another service that does not provide attestations), so this would just be an advisory warning. Similarly, I'm not proposing that renovate do any further validation of the attestation(s) themselves.

Related to #11228.

[rarkins]

Is it as simple as "attestation = good, non-attestation = bad", or do we need to check the contents too? e.g. if this were git signing then you can't just say "oh it's ok, someone signed it" - the signer's identity also requires it

BTW it looks like the attestations are already in the general/root metadata which Renovate already fetches, so there's no need to do one API call per-release. e.g. in https://registry.npmjs.org/eslint-config-prettier

[martincostello]

For the purposes of this suggestion I would see it the below as there's no attempt to check the validity of the assertion (e.g. it's from the same repository/system as the old version):

Old Version	New version	Status
Not attested	Not attested	❔ Neutral
Not attested	Attested	❔ Neutral (but likely an improvement)
Attested	Not attested	⚠️ Possibly bad (i.e. published from a private location due to a leaked token)
Attested	Attested	❔Neutral

It could be extended later to be more thorough. For example:

• Same originating repository as the previous version?
• Does the attestation match the repository in the package metadata?
• Is the attestation the same type/provenance as the previous version?

[rarkins]

In that case, it sounds like the solution would involve:

• A new, optional boolean field attestation per-release in datasource results, supported by npm-only for now
• Add a Warning to the PR body if upgrading from an attested release to a non-attested release

[martincostello]

That sounds reasonable to me - I'm happy to raise a PR to add that if you're welcome to the change?

[rarkins]

That would be welcomed, thanks - I've converted this to an issue: #37258