Check five things before you tag: your accounts, your workflow permissions, the contents of the artifact, how it will be published, and who will notice if it goes wrong. This list is short on purpose, with a link to a guide for each step.
1. Accounts
- 2FA on npm, PyPI and GitHub, with a security key where possible and recovery codes stored away from your phone. See npm 2FA and recovery and GitHub account security.
- Token list reviewed. Anything you cannot explain is revoked. See granular token settings.
2. Workflow
- The permissions block lists only what each job needs. See token permissions for release workflows.
- Publishing uses trusted publishing where available. For PyPI's first release, see pending publishers.
- The publish job uses an environment with a reviewer.
- Third party actions are pinned. See pinning actions to SHAs.
3. Artifact contents
- For npm, preview the tarball: npm pack dry run.
- For Python, inspect the sdist: checking your sdist for stray files.
- Look at the build tools too: build-system requires.
- Run an audit on your dependencies and fix what has a fix. A free scan at gold.safeguard.sh/scan gives a quick inventory.
4. Publishing
- Bump the version in one step: what npm version does.
- Scoped and first time? Use the public access option.
- Turn on provenance if your CI supports it: requirements and what becomes public.
- Consider testing the Python upload on TestPyPI first.
5. After the release
- Install the published package in a clean folder or container and run a smoke test. See testing the published artifact.
- Confirm the registry page shows what you expect: visibility, links, version. For PyPI, verified URLs help users trust your repository link.
- Make sure someone sees alerts while you are away. See who watches security alerts when the solo maintainer is away.
- Keep a compromise runbook where you can find it: your package was compromised.
Print version
| Area | One line check |
|---|---|
| Accounts | 2FA, key, recovery codes, token list |
| Workflow | Least privilege, trusted publishing, approval, pinned actions |
| Artifact | Dry run, no secrets, build tools reviewed, dependencies scanned |
| Publish | One step bump, access option, provenance |
| After | Clean install test, registry page, alerts |
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are triaged by what matters, which is what you want from the audit step above.
Quick check
Do I need every step for a tiny package?
The account and workflow steps are cheap and cover the worst failures. Do those first, then add the rest as the package gains users.
How often should I rerun this list?
Run the full list for every release, and the account and token parts at least a few times a year.
Last reviewed: 19 October 2026.
