Security should be assigned to the phase where the risk is introduced, with clear ownership and evidence that the work happened. Requirements need abuse cases, design needs threat modeling and infrastructure review, development needs code checks and secrets detection, testing needs security testing, deployment needs pipeline hardening, and maintenance needs continuous triage and patching.
Why This Matters for Security Teams
Embedding security into each SDLC phase prevents the common failure mode where risk is discovered only at release time, when remediation is slower, more expensive, and more likely to disrupt delivery. A phase-aligned approach supports traceability, clearer ownership, and earlier evidence collection, which is consistent with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls. The practical goal is not to add bureaucracy, but to make security work part of normal engineering flow.
Teams often get this wrong by treating security as a separate approval step, which creates bottlenecks and encourages superficial sign-off instead of real risk reduction. A better model is to define one or two security outcomes per phase, then verify them with lightweight artefacts such as abuse cases, threat models, review records, test results, and deployment checks. That keeps security visible without making it a final obstacle.
In practice, many security teams encounter the real issue only after a release has already been delayed by a late-found defect, rather than through intentional phase-based planning.
How It Works in Practice
The most effective pattern is to map security activities to the moment risk is introduced. Requirements should capture misuse or abuse cases, data sensitivity, and trust boundaries. Design should review architecture, third-party dependencies, identity flows, and infrastructure assumptions. Development should enforce secure coding checks, dependency scanning, and secrets detection. Testing should validate control effectiveness through security testing, not just functional checks. Deployment should harden pipelines and release permissions. Maintenance should focus on continuous vulnerability triage, patching, monitoring, and incident feedback loops.
This is usually implemented as a set of phase-specific exit criteria, but those criteria should be proportional to the system’s risk. A low-risk internal tool may need lightweight reviews and automated checks, while a customer-facing or regulated workload needs deeper evidence and formal approval paths. The key is that security work happens in the same workflow as delivery work, not after it.
- Requirements: define abuse cases, security stories, and data handling constraints.
- Design: perform threat modeling and review trust boundaries, identity, and dependencies.
- Build: scan code, infrastructure-as-code, and secrets before merge.
- Test: run security testing, including negative testing and validation of control coverage.
- Deploy: restrict pipeline permissions, review artefacts, and verify rollback readiness.
- Maintain: monitor findings, patch quickly, and feed lessons back into the next sprint.
For organisations building cloud-native systems, these expectations often align with the control families in CISA Secure by Design and the implementation themes in OWASP Top 10, especially where application weakness, access control, and dependency risk are involved. The practical challenge is to automate evidence wherever possible so engineers are not forced to produce manual proof for every change.
These controls tend to break down when release pipelines are fragmented across many teams because ownership, evidence, and enforcement points become inconsistent.
Common Variations and Edge Cases
Tighter phase-gated security often increases coordination overhead, requiring organisations to balance delivery speed against assurance. That tradeoff becomes especially visible in high-change environments, regulated systems, and product teams that ship frequently.
Best practice is evolving toward risk-based enforcement rather than identical controls for every change. For example, a documentation update does not need the same scrutiny as an authentication workflow change, and a low-impact internal service should not be forced through the same approvals as a payment or identity platform. Current guidance suggests tailoring evidence to impact, while keeping the security objective constant.
There is also an important edge case in DevSecOps-heavy environments: automation can make security feel “embedded” while still missing the real control objective if the checks are shallow or misconfigured. In those cases, teams should review whether they are measuring activity completion or actual risk reduction. The same problem appears in outsourced development and platform-managed services, where security responsibilities are split across vendors and internal teams. Clear ownership and handoff points are essential.
Where identity is part of the SDLC, the same principle applies to credentials, service accounts, secrets, and privileged workflows. Those elements should be reviewed when they are created, changed, or integrated, not only during a final security sign-off. That is where phase-based security becomes operationally meaningful rather than procedural.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Ongoing oversight fits phase-based security rather than final-stage review. |
| MITRE ATT&CK | T1190 | Attack surface exploitation often maps to missed design and testing controls. |
| CIS Controls | 8 | Audit logs and monitoring evidence support continuous assurance across SDLC stages. |
Define security checkpoints by phase and track whether controls are working throughout delivery.
Related resources from NHI Mgmt Group
- How should security teams use trust signals without turning them into proof?
- How should security teams phase out password-based authentication without disrupting operations?
- How should security teams phase out SMS OTP without breaking access?
- How should security teams phase out passwords without breaking access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
