Before you tag a release, run a dependency audit against runtime packages, confirm your lower bounds still include no known-vulnerable versions, check the lockfile and workflow pins, and write one line in the notes about any dependency security change. Fifteen minutes covers it.
The checklist
Print this, paste it into your release issue template, or keep it as a pull request checklist.
| Step | What to do | Why |
|---|---|---|
| 1 | Run an audit on runtime dependencies | Know what you ship |
| 2 | Review open dependency pull requests | Do not release with a security bump unmerged |
| 3 | Check lower bounds in the manifest | Floors should not allow versions with known advisories you are affected by |
| 4 | Frozen install in CI | Release from the tree you tested |
| 5 | Review workflow action pins and token permissions | The release job holds your credentials |
| 6 | Note dependency security changes | Users decide faster |
Step by step
1. Audit what users receive. For npm, npm audit --omit=dev leaves out dev dependencies, and --audit-level sets the severity that fails the command. The npm page warns that npm audit fix --force can install semver-major updates and should not be used without a plan.
2. Look at open update pull requests. Dependabot opens up to five version update pull requests at a time by default, and security update pull requests have a separate limit of 10. If one is waiting and it fixes a vulnerability in code you call, merge it before tagging.
3. Check floors. If a dependency had an advisory this cycle, make sure the minimum version in your manifest is at or above the patched version when your code is affected.
4. Release from a frozen install. npm ci installs exactly what the lockfile says, never writes to it, and errors if it disagrees with package.json. That gives you a release built from what CI tested.
5. Check the pipeline itself. GitHub recommends pinning actions to a full-length commit SHA and setting the default token to read-only, raising permissions per job. The release job is the one with publishing power, so review it first.
6. Write the note. One sentence is enough: "Raised the minimum version of parser to 2.3.1 to pick up the fix for an advisory." If you were not affected, you may say so, with a link.
What to skip
Do not try to review every transitive package by hand. Use tools to enumerate them, and spend your attention on direct runtime dependencies and the release workflow. And do not delay a release for a dev-only alert unless the tool touches release credentials.
Make it routine
If you release monthly, put these six steps in the release issue template. If you release rarely, add a calendar reminder. The goal is that the checks happen even when you are tired.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a check can block a merge until a finding is dealt with.
Quick check
Should a release wait for every dependency update?
No. Wait for security fixes that affect code you call. Other updates can follow in the next cycle.
Is a clean audit proof of safety?
No. It reports known advisories only. New ones appear after you ship, so keep watching.
Safeguard can run policy gates on pull requests and keep scanning after you release, which covers the period after the checklist is done. See the free scan.
Sources
- npm docs, npm audit: https://docs.npmjs.com/cli/v10/commands/npm-audit
- npm docs, npm ci: https://docs.npmjs.com/cli/v10/commands/npm-ci
- GitHub docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
- GitHub docs, security hardening for GitHub Actions: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
Last reviewed: 19 October 2026.
