Security reviews that happen only before a release tend to produce the same frustrating result: a long list of findings, a delayed launch and a team that feels punished for work it did months ago. The alternative is to attach a small safeguard to each hand-off in the delivery process so that problems are caught at the point they are introduced. This article gives engineering and platform leads a practical checklist for doing exactly that. It is not a scoring exercise. Each item is a concrete control you can wire into your workflow, grouped by the moment in delivery where it belongs.
How to use this per-step security checklist
Work through the sections in order and treat each item as a yes/no question about your current workflow. For every “no”, decide whether to adopt the control now, schedule it, or consciously accept the gap. Three principles apply throughout:
- Keep every check fast. A control that adds seconds will run on every change. One that adds an hour will be skipped under pressure.
- Prefer automation over memory. If a safeguard depends on someone remembering to do it, assume it will eventually be forgotten.
- Fail loudly and early. A blocked commit with a clear message is far cheaper than a finding in a pre-release report.
Section 1: Before work begins
The cheapest security fix is the one that never has to be made, because the risky design was questioned before it existed.
- [ ] New features that touch authentication, payments, personal data or external integrations get a short threat-modelling discussion before development starts.
- [ ] The outcome of that discussion (identified risks and agreed mitigations) is recorded in the same ticket or design document as the feature.
- [ ] Acceptance criteria include at least one security condition where relevant, for example “users can only view records belonging to their own organisation”.
- [ ] A named owner exists for each third-party service the feature will depend on.
Section 2: Before a change merges
This is the point at which a developer still has full context, so feedback here is most effective.
- [ ] Secret detection runs automatically on every commit or pull request and blocks merges when credentials are found.
- [ ] Static application security testing runs on every pull request, with results shown inline to the author rather than in a separate report.
- [ ] Findings are tuned so that a blocking result genuinely warrants attention; noisy rules are adjusted or downgraded, not silently ignored.
- [ ] Code review guidelines include a short list of security questions specific to your stack.
- [ ] Credentials used by applications are stored in a secrets manager, never in source files or pipeline variables visible to all contributors.
For a gentler introduction to moving these controls earlier, see our beginner-oriented explanation of moving security work towards the start of development.
Section 3: While artefacts are assembled
Builds are where your own code meets everyone else’s, and where your infrastructure definitions become real.
- [ ] Every build scans third-party dependencies for known vulnerabilities and fails on agreed severity thresholds.
- [ ] A software bill of materials is produced for each build and stored alongside the artefact.
- [ ] Container images are built from approved base images and scanned before they are pushed to a registry.
- [ ] Infrastructure-as-code templates are scanned for misconfigurations, such as publicly readable storage or overly broad network rules, using a tool such as Checkov.
- [ ] Build environments use short-lived credentials and are not shared with unrelated workloads.
- [ ] Artefacts are signed or checksummed so later stages can confirm they have not been altered.
Section 4: Before anything reaches users
The release step should confirm, not discover. If earlier sections are in place, this stage is mostly about enforcing agreed rules consistently.
- [ ] Release policies are written as code, for example with Open Policy Agent, so the same rules apply to every deployment rather than depending on who approves it.
- [ ] A release cannot proceed if any earlier blocking check failed without a recorded, time-limited exception.
- [ ] Dynamic testing runs against a staging environment for applications exposed to the internet.
- [ ] Production configuration (debug flags, open ports, admin interfaces) is verified automatically as part of deployment.
- [ ] Rollback is tested, so that a security fix can be shipped or a bad release reversed quickly.
Section 5: After release
A safeguard-per-step mindset continues after deployment, because the environment and the threat landscape keep changing.
- [ ] Newly disclosed vulnerabilities in deployed components trigger an alert to the owning team, not only to a central security mailbox.
- [ ] Runtime anomalies, such as unexpected outbound connections, generate alerts with enough context to act on.
- [ ] Audit logs for privileged actions are retained and reviewed on a defined schedule.
- [ ] Every security incident or near miss ends with one question: which earlier step could have caught this, and what small check should be added there?
Section 6: People and process
Controls only hold if the people around them understand their purpose.
- [ ] Every engineer knows what each automated check protects against and how to resolve its common findings.
- [ ] Exceptions to blocking checks have an owner and an expiry date.
- [ ] Security responsibilities are written into role descriptions rather than assumed.
- [ ] There is a clear route for engineers to propose new checks or retire ones that no longer add value.
Teams moving through this list for the first time often stumble over the same issues; our article on early missteps organisations make with DevSecOps covers the most frequent ones.
Worked example: tracing one finding back to its step
Suppose a pre-release penetration test reports that an internal reporting endpoint is reachable from the internet without authentication. Using this checklist, the team traces the finding backwards rather than simply patching it:
- Section 1 question: did the feature that added the endpoint get a threat-modelling discussion? It did not, because it was classed as “internal only”.
- Section 3 question: did the infrastructure template exposing it get scanned? It did, but the rule flagging public load balancers had been muted months earlier as noisy.
- Section 4 question: did deployment verify production exposure? No automated check covered it.
The fix is then threefold and small: classify “internal” features as in scope for threat modelling, re-enable and tune the muted rule, and add an exposure check to deployment. Next time, the same mistake is stopped within minutes of being made, instead of weeks later by an external tester.
Filling the gaps this checklist reveals
Most teams find that sections 2 and 3 are the quickest wins, while sections 1 and 6 take longer because they involve habits rather than tools. Closing those gaps usually requires either building skills internally or bringing in experienced help for the first implementation.
DevSecOpsSchool’s training and consulting for secure delivery covers both paths. Its role-based certifications separate the hands-on work, such as wiring scanning and compliance checks into pipelines, from the leadership work of governance and team enablement, which suits organisations assigning different people to different sections of a list like this one. Its services also include custom curricula, tool-focused workshops, help designing a secure CI/CD roadmap and implementation of security automation. For a deeper technical walkthrough of the pipeline items above, our guide to placing security controls inside CI/CD pipelines goes further into configuration choices.
Final note
No team ticks every box on day one, and that is not the goal. The goal is to move each important check to the step where the underlying problem is created, so your final release review becomes a brief confirmation. Revisit the list each quarter, add controls where incidents or near misses point, and remove those that no longer earn their place.