Use case or problem
First, thanks for already adding the artifact attestations check to the review process. Provenance verification is a real win for supply chain safety.
There’s a complementary gap it doesn’t cover. Attestations prove where a release artifact came from, but they don’t stop tampering with an existing release after publish. Mutable releases are a known weak point: if a maintainer account is compromised or a token leaks, an attacker can quietly re-upload main.js on an already-published tag, and everyone who installs or updates that version pulls the swapped asset. We’ve seen this pattern in real supply chain attacks across other ecosystems, where the compromise wasn’t a new malicious package but a hijacked existing release. Right now the review bot doesn’t flag whether a plugin’s releases are protected against this.
Proposed solution
Add a recommendation-level check in the Releases section, alongside the existing attestations one, that confirms GitHub’s immutable releases are enabled:
• Query GET /repos/{owner}/{repo}/immutable-releases and check enabled .
• If it’s off, surface a recommendation (not a hard error) explaining the benefit and linking to GitHub’s immutable releases docs.
Immutable releases (GA October 2025) lock a release’s tag and assets once published, so they can’t be modified, replaced, or deleted. Paired with attestations you get both ‘this came from the right source’ and ‘this hasn’t changed since publish.’ It’s a single API call and non-breaking, since it’s a recommendation rather than a requirement.
Current workaround (optional)
None at the review-bot level. Developers can enable immutable releases manually (repo setting, or PUT /repos/{owner}/{repo}/immutable-releases ), but there’s nothing prompting or verifying it during review, so most plugins won’t have it on and users have no signal either way. I’ve enabled both attestations and immutable releases on my own plugin and I’m happy to share the workflow config as a reference implementation.