Security Gates for a Practical Software Development Lifecycle
Security gates work when they make a delivery decision with clear input and owner, not when they become a document ceremony. NIST SSDF organizes secure development practices; SAMM and ASVS help choose maturity and verification depth.
Place gates where change is cheapest
At design, identify data and trust boundaries. At build, protect dependencies and secrets. Before release, test high-risk flows. After release, accept vulnerability signals and preserve evidence. A payment feature needs authorization design review; a library upgrade needs provenance and vulnerability triage.
Phase gate checklist
| Phase | Evidence | Release decision |
|---|---|---|
| design | threat assumptions | risky boundary has owner |
| build | dependency and secret checks | blocked issue triaged |
| test | abuse-case results | critical flow verified |
| operate | alert and fix owner | issue tracked to closure |
NIST SSDF, OWASP SAMM, and ASVS are scope references.
Decision rule: block release only on explicit risk conditions with a named exception owner and expiry.
Improve next
Start with one gate per high-risk change, measure false positives, and automate evidence collection later. A gate does not certify software or replace independent testing. Source review can supply code-level evidence.
Gate decisions, not paperwork
Define gate trigger from change risk: sensitive data, privilege change, external integration, deployment boundary, or dependency change. Each gate has required artifact, accountable owner, reviewer, pass condition, fail condition, and exception path. At design, capture trust boundaries and abuse cases. At build, inspect secrets and dependency diffs. Before release, exercise critical controls. In operation, assign vulnerability intake and closure.
Sample gates against real changes and prove that a failed gate blocks promotion until an approved exception exists. Evidence fields: change ID, gate, risk condition, artifact link, owner, reviewer, result, exception ID, expiry, remediation, and retest. Owner: delivery owner. Pass: required evidence is current and accountable decision exists. Fail: promotion proceeds without required condition or exception. Exceptions need risk owner approval, compensating controls, target date, and automatic review before expiry.
Gate cadence
Keep evidence close to delivery work: issue, pull request, pipeline record, or release checklist. A gate should not force a meeting when clear reviewer and artifact exist. Review false positives and missed conditions after several changes, then tune trigger or evidence requirement. Measure whether high-risk change received an accountable decision.
Gate decision packet
Expected output: change ID, risk trigger, required artifact, reviewer, gate verdict, release action, exception ID, expiry, retest link. This packet ties a release decision to concrete change risk and evidence.
Worked failure: A change adds a privileged export endpoint without an abuse-case artifact. Promotion must stop until owner supplies review or approved exception.
Edge case: A low-risk documentation edit should not be forced through the same gate. Record why trigger did not apply so omissions are explainable.
Closure test: Attempt promotion with an expired exception. Closure passes when pipeline or reviewer rejects it and remediation status is visible.
Trigger calibration review
A gate trigger must be observable from change metadata. Define examples: new internet-facing endpoint, credential handling change, privilege expansion, external data fetch, infrastructure identity change, or dependency with known exploit signal. Give teams a short route for declaring no trigger, with reviewer confirmation. This prevents security work from becoming a hidden requirement discovered only at release.
Evidence should be produced where work happens. A design boundary note can live with the issue; a dependency scan with build record; an abuse-case test with automated suite; an exception with release approval. Reviewers should reject stale links and artifacts from another environment. After several releases, compare gate failures against incidents and near misses. Remove gates that provide no decision value, and strengthen gates that repeatedly discover late risk.
Exception expiry must be machine-readable where promotion automation exists. Test that an approval attached to one change cannot authorize unrelated later change. The expected output is a blocked release record naming expired exception and accountable remediation owner.
Gate ownership should survive team changes. Assign role-based owner and escalation path instead of a personal inbox. If reviewer cannot decide, route to risk owner with stated deadline and preserve current release state as blocked or conditional. Periodically sample completed gates for artifact quality and exception expiry. This quality check should produce findings about process evidence, not invent product security claims. A gate becomes credible when teams can predict its trigger and receive timely, traceable decisions.
Final gate review ties release decision to specific change, evidence version, accountable owner, and exception state. Expected result: incomplete required evidence blocks or conditions promotion predictably. Edge case: emergency change needs expedited path; retain equivalent approval and later review. Close only when deployed release record cannot be confused with a different build or approval.