A security checklist to run before every release

A good release security checklist is short enough to run every time and specific enough to fail. The list below has twenty items in five groups. It draws on NIST's Secure Software Development Framework (SP 800-218), the SLSA build levels, and OWASP's Application Security Verification Standard.

How should I use this list?

Make it a release gate. Every item has a yes or no answer and an owner. If an item cannot be answered yes, the release notes must say why and who accepted the risk. Copy it into your pipeline or ticket template and adjust.

NIST describes the SSDF as a core set of high level practices that can be integrated into any software development life cycle, and says following them should reduce vulnerabilities in released software. SLSA frames build integrity as levels, from provenance that exists, to signed provenance from a hosted platform, to a hardened build platform. ASVS gives a verification basis for application security controls.

The checklist

Code

1. Every change was reviewed by someone other than its author.
2. Static analysis ran on the release commit with no unreviewed high severity result.
3. Tests for authentication, authorization and input handling ran and passed.
4. Any change to security sensitive code has a named reviewer.

Dependencies 5. A software bill of materials was generated for this exact build. 6. Dependencies were matched against current advisories on release day, not last week. 7. No known exploited vulnerability is reachable in what you ship. 8. New or changed dependencies were reviewed by a person. 9. Lockfiles are committed and the build used them.

Secrets 10. A secrets scan ran on the repository history for this release range. 11. No credentials appear in build logs, images or artifacts. 12. Any credential used by the pipeline is scoped to this job and can be rotated.

Build integrity 13. The build ran on a hosted, controlled platform, not a developer laptop. 14. Provenance (what built this, from which source and inputs) was recorded. 15. Artifacts are signed or checksummed and the digest is stored with the release. 16. Third party build steps are pinned to an exact version or commit.

Evidence and recovery 17. Test results, scan results and approvals are stored and tied to the release identifier. 18. A rollback path was tested for this release, not assumed. 19. Someone owns monitoring for the first hours after deploy. 20. Security relevant changes are written in the release notes in plain language.

What does a failed item look like?

If item 7 fails, you have two honest options: fix it, or document why it is not reachable and who approved shipping. What you cannot do is ship and say nothing. The record is the point. An auditor, a customer or your future self will ask why.

What to do

1. Paste the twenty items into your release template and delete any you cannot verify, then add an item for each one you removed saying how you will.
2. Automate the checks that can be automated: items 2, 5, 6, 9, 10 and 15 fit in CI.
3. Assign an owner to each manual item.
4. Store the completed list with the release, so the evidence travels with the build.
5. Review the list after every incident and add the missing check.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework
• SLSA security levels
• OWASP Application Security Verification Standard
• CISA, 2026 Minimum Elements for a Software Bill of Materials

Last reviewed: 18 October 2026.