Secure release checklist: gates worth having in the pipeline

A security gate that adds twenty minutes to every deployment will be removed within a quarter. The gates that survive are fast, automated and almost never wrong - and the checks that are slow or noisy belong earlier in the cycle, not at the release door.

Gates that belong in the pipeline

• Secret scanning - fast, high signal, and prevents a permanent problem. Run pre-commit as well.
• Dependency scanning against known vulnerabilities, failing only on severity thresholds you have agreed.
• Infrastructure-as-code checks - public storage, permissive security groups, missing encryption. Catches whole classes of misconfiguration before they exist.
• Container image scanning and signature verification at deploy.
• Required review with self-approval blocked - your change control evidence depends on this.
• Automated tests passing, with results retained.

Checks that belong earlier

Static analysis with a high false-positive rate, full dynamic scanning and manual review are valuable but too slow or noisy to gate a release. Run them on a schedule or at merge, feed findings into the backlog, and keep the release path fast.

The failure mode to avoid: adding a slow check to the release gate, watching teams request exemptions, granting them routinely, and ending up with a gate that exists on paper and is bypassed in practice.

Before a significant release

• Does it change the attack surface? New endpoints, new integrations, new data collected, new permissions requested.
• Does it change authorisation logic? The highest-risk category of change, and worth a human look every time.
• Does it touch personal data? New fields or purposes may need the processing record updated, and possibly a DPIA.
• New third-party dependency or sub-processor?
• Are secrets and configuration handled correctly for the target environment?
• Is logging adequate to investigate a problem in the new code path?

Rollback readiness

Confirm before deploying, not after something breaks: a tested rollback path, whether database migrations are reversible, feature flags to disable new functionality without a full rollback, and who is authorised to trigger a rollback out of hours.

Irreversible migrations deployed alongside application changes are the most common reason a rollback is not actually available when needed.

After release

• Verify the deployed version matches what was approved.
• Check error rates and authentication failures for a period after.
• Confirm new endpoints are not unintentionally public.
• Confirm the change record reflects what actually shipped.

That last one matters for audit: reconciling deployment logs against approvals in both directions is exactly what auditors do, and it finds changes that bypassed the process.

Emergency releases

Define the reduced path in advance - what may be skipped, who authorises, and the mandatory retrospective review within a set window. Emergency changes are legitimate; missing retrospective approval is the finding.

Key takeaways

• Gate on fast, high-signal checks; move slow ones earlier.
• Authorisation changes deserve human review every time.
• Confirm rollback is genuinely available before deploying.
• Reconcile deployments against approvals in both directions.