Publish GuardCheck how your packages reach their registries - before a stolen token publishes for you.

How it works - and what is sourced

The checks follow the skill: no long-lived token on a registry that accepts OIDC from your CI, and every other token scoped and expiring (npm and NuGet tokens now expire within 30-90 days, so one with no expiry on record is treated as lost); nothing expired or expiring within two weeks of the as-of date; at least two owners per package on a security key or passkey; no laptop publishes; no pull_request_target or workflow_run trigger on the release workflow; default permissions none; third-party actions pinned to a full commit SHA; no restored caches; the OIDC identity only in the publish job; the publish job in a protected environment, separate from the build; a dry-run step; a written, rehearsed rollback per registry; signed binaries with checksums; internal names blocked from public upstreams. Publish steps are recognised by their commands (npm publish, twine, gem push, cargo publish, nuget push, mvn deploy, goreleaser, docker push and others).

The rankings follow the skill: trusted publishing bound to a protected environment by default, the narrowest bot-owned token where no OIDC exists, the tag ruleset where the tag is the release (Go, SwiftPM, Packagist); a human approval gate for paying customers, many dependents or after an incident; provenance when buyers ask. A deadline migrates the registry whose credential runs out first; an incident runs the rollback runbook first. Private consumption: one blocking internal endpoint when you control the feed, explicit client mapping otherwise.