What should a security checklist for every release include?

A release checklist should answer six questions in minutes: is the code reviewed, are the dependencies known and safe, are secrets out, can we prove how the build was made, did the security tests pass, and can we roll back. This cheat sheet turns each into checks you can tick, with a public standard behind each.

Keep it short enough that people use it. Twenty items that run on every release beat a hundred items that run once a year. Where a check can be automated, automate it and let the checklist hold only the result.

1. Code

• Every change in the release went through review by someone other than the author.
• Static analysis ran on the release branch, and no new high severity finding is open without a recorded decision.
• Security-relevant changes, such as authentication, authorization and input handling, were checked against a verification standard. The OWASP Application Security Verification Standard, currently at version 5.0.0, gives a list of requirements for testing web application technical security controls. OWASP advises citing requirements with the version included, for example v5.0.0 followed by the requirement number, because identifiers can change between versions.

2. Dependencies

• A current software bill of materials exists for this release. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, and has published updated minimum elements guidance. Check the current version of that guidance for the fields to include.
• Dependencies were scanned for known vulnerabilities after the last lockfile change.
• No dependency in the release appears in CISA's Known Exploited Vulnerabilities catalog without a fix or a recorded mitigation. CISA says organizations should use that catalog as an input to prioritization.
• New dependencies were reviewed by a person: name spelled correctly, maintainer known, license acceptable.
• Packages are pinned by lockfile, and the lockfile is committed.

For projects you do not control, OpenSSF Scorecard offers automated checks that assess open source projects for risky practices. It can run on your own repositories, or on someone else's from the command line. Treat a low score as a prompt to look closer.

3. Secrets and configuration

• A secrets scan ran on the diff and on the release artifact.
• No credentials are in environment files committed to the repository, build logs or container images.
• Production configuration differs from test configuration only where it should, and the differences are reviewed.
• Anything rotated in this release, such as keys or tokens, has an owner and a date.

4. Build and provenance

• The release was built by an automated pipeline from a tagged commit, not from a laptop.
• The build records what source and inputs produced the artifact, so a consumer can decide whether to trust it. SLSA describes itself as a set of incrementally adoptable guidelines for supply chain security, useful to producers and to consumers deciding whether to trust a package.
• Build credentials are limited to what the pipeline needs, and are not shared with developers.
• The artifact is signed or has a recorded digest, and deployment uses that digest.

5. Verification

• Tests for the security properties you promised, such as access control and logging, passed.
• If the release changes an externally visible surface, someone tested it from outside: new endpoints, new upload paths, new redirects.
• Logging and alerting for the new code paths are in place and tested.
• Infrastructure changes in the release were scanned before apply.

6. Release and rollback

• A rollback has been rehearsed for this type of change, and the previous artifact is retained.
• On-call knows what is shipping and what to watch.
• Customer-facing security notes, such as a changed permission, are drafted.
• Exceptions to this checklist are written down with a name and a reason.

How does this map to a framework?

NIST's Secure Software Development Framework, SP 800-218, describes a core set of high-level secure software development practices that can be integrated into any development life cycle. It says following them should help producers reduce the number of vulnerabilities in released software, mitigate the impact of those not found, and address root causes. The checklist above is an operational slice of those ideas, not a replacement for the framework. If you must show alignment to a customer, map each item to the practice it supports and keep the evidence together.

What should you automate first?

Start with the checks that fail loudly and cheaply: the dependency scan, the secrets scan and the SBOM generation. They run in minutes, and they catch the problems that cost the most to fix after release. Add provenance and signing next. Leave the human review items as explicit ticks that someone owns.

What to do

1. Copy the list into your release template and delete anything you will not run.
2. Mark each item as automatic or human, and name the owner of each human item.
3. Wire the three fast scans into the release pipeline, with a visible pass or fail.
4. Add an exceptions line to every release record.
5. After each incident or near miss, add or reword one item.
6. Review the whole list each quarter and cut items nobody uses.

Quick check

Sources

• OWASP Application Security Verification Standard
• CISA, Software Bill of Materials (SBOM)
• CISA, Known Exploited Vulnerabilities Catalog
• OpenSSF Scorecard
• SLSA specification, About SLSA
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1

Last reviewed: 18 October 2026.