Before each release, ask ten plain questions: what is in it, who changed it, was it built safely, what known flaws does it carry, are any secrets inside, and can we undo it. A good answer is a record, not a promise. This checklist works for managers as well as engineers.
Why a checklist at all?
Releases are routine, and routine is where steps get skipped. NIST's Secure Software Development Framework (SP 800-218) presents a set of practices that can be built into any development life cycle, and says following them should help producers reduce the number of vulnerabilities in released software. It also gives buyers and builders a shared vocabulary for talking about secure development.
That shared vocabulary is the point of this page. You do not need to read code to ask the questions below. You need to ask for evidence.
The ten questions
- What is in this release? Ask for a software bill of materials. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. A good answer is a file generated by the build, not a hand written list.
- What changed since last time? A good answer is a list of reviewed changes with names against them.
- Who approved it? Look for at least one reviewer who did not write the change.
- Where was it built? SLSA calls the record of how an artifact was produced "provenance". At its first level the package simply has provenance. Higher levels ask for a hosted build platform that signs it, then a hardened platform. A good answer says which level you are at, and honestly, level zero is a valid starting point.
- Does it contain known vulnerable components? A good answer is a scan result dated today, with each serious item either fixed or explained.
- Are any of those flaws being exploited right now? CISA's Known Exploited Vulnerabilities catalog lists flaws confirmed exploited in the wild, and CISA advises using it as an input to prioritization. Anything on that list and present in your release needs a decision before shipping.
- Are there secrets inside? Passwords, keys and tokens do not belong in code or build output. A good answer is a secret scan result for this release.
- Did the tests and checks run? A good answer is a pipeline record showing every required check passing, with no manual skips.
- Can we roll back? A good answer names the previous version, who can trigger the rollback and how long it takes.
- Who is watching after release? A good answer names a person, a channel and what would count as a problem.
How do you make it quotable and repeatable?
Put the ten questions in the release ticket template. Each gets a link to evidence, a date and an initial. If a box cannot be ticked, the release manager records why and who accepted the risk.
Two rules make the list work. Never accept "yes" without a link. And never let the person who wrote the change be the sole person who signs off.
See an inventory example at /demos/sca-dependency-inventory.
What are the honest limits?
A checklist proves a process ran, not that the software is free of defects. Scans find known flaws, and they miss new ones. Provenance shows how something was built, and it does not show the code is correct. Treat the list as a floor that catches common mistakes, and keep code review, testing and monitoring on top.
Tools can fill in several answers automatically. Safeguard generates SBOMs, matches them to known vulnerabilities, adds reachability analysis and scans for secrets, and the CLI can run locally. Whatever tool you use, the checklist stays the same: the evidence matters more than the product.
What to do
- Copy the ten questions into your release template today.
- For each one, decide where the evidence comes from, and automate it where you can.
- Name an owner for each question.
- Run the list on the next release without changing anything, and note which answers were missing.
- Fix the missing ones in order of how often they bite you.
- Review the list every quarter and remove any question that never changes an outcome.
- Keep the filled lists, because they are useful evidence for auditors and customers.
Quick check
Do small releases need the full list?
Yes, but most answers come automatically for small changes. The point is that the records exist, not that people spend hours.
What if we cannot answer the provenance question?
Start by writing down where builds run and who can change the pipeline. That is level zero in SLSA terms, and it is a valid place to begin.
Sources
- NIST SP 800-218: Secure Software Development Framework, fetched 18 October 2026
- CISA: Software Bill of Materials, fetched 18 October 2026
- CISA: Known Exploited Vulnerabilities Catalog, fetched 18 October 2026
- SLSA v1.0 levels, fetched 18 October 2026
Last reviewed: 18 October 2026.
