Sign your releases so customers can check them
After a year of poisoned packages, being able to prove a release came from your build system is no longer optional.
This year attackers published malicious versions of real packages more than once, using stolen tokens. Users had no easy way to tell a real release from a fake one, because both came from the official account.
Signing and provenance change that. The release says which repository, which commit and which build workflow produced it, and that statement is signed so it can’t be forged with just a publishing token.
- On npm and PyPI, publish from CI with trusted publishing, using OIDC instead of long-lived tokens, and enable provenance.
- Sign container images and binaries with Sigstore or your platform’s signing service.
- Remove old publishing tokens once trusted publishing works.
- Protect the release workflow itself: required reviews, protected branches, and no secrets available to pull requests from forks.
And on the consuming side, start checking provenance for your most important dependencies.