SDLC Security Integration

Where Most Organizations Get This Wrong

A development team ships a new customer portal on schedule. Three weeks later, a penetration test reveals SQL injection, broken authentication, and an exposed administrative endpoint. The team scrambles to patch in production. The fix takes longer than the original feature build. Management asks: “Why didn’t we catch this earlier?”

Security added after development is always more expensive, more disruptive, and less effective than security built into the process from the start. The SDLC is where this principle either succeeds or fails.

This module covers CISSP exam objective 8.1: understand and integrate security in the software development lifecycle. ISC2 expects you to know how different SDLC models accommodate security activities, where those activities belong in each phase, and how a security manager governs development practices without writing a single line of code.

SDLC Models and Security Implications

Each development methodology presents different opportunities and constraints for integrating security. The exam expects you to recognize which model is in play and what that means for security governance.

Waterfall

Sequential phases: requirements, design, implementation, testing, deployment, maintenance. Each phase completes before the next begins. Security activities map neatly to specific phases, but defects discovered late are expensive to fix because you cannot easily return to earlier phases.

• Security advantage — Clear, documented checkpoints where security reviews can be mandated
• Security weakness — Security defects found in testing require costly rework because the design phase is closed

Agile

Iterative development in short sprints (typically 2–4 weeks). Features are delivered incrementally. Security must be integrated into every sprint rather than concentrated in a single phase.

• Security advantage — Frequent delivery cycles mean security feedback comes sooner and defects are caught in smaller increments
• Security weakness — Speed can pressure teams to skip security activities; no dedicated “security phase” exists unless governance mandates it

Spiral

Risk-driven model that repeats four phases in cycles: planning, risk analysis, engineering, evaluation. Each loop through the spiral addresses a higher level of elaboration.

• Security advantage — Risk analysis is built into every cycle, making it naturally security-aware
• Security weakness — Complexity can make governance difficult; each spiral may introduce new risk dimensions

DevOps and DevSecOps

DevOps merges development and operations into a continuous pipeline. DevSecOps extends this by embedding security into every stage of that pipeline — not as a gate that blocks releases, but as an automated participant in every build, test, and deployment cycle.

• Security advantage — Automation enables security checks at every commit, build, and deploy without slowing the pipeline
• Security weakness — Requires organizational commitment; if security tooling is treated as optional or is poorly configured, the automation produces noise rather than signal

The exam treats DevSecOps as a cultural and governance shift, not a product you buy. When a question presents a DevOps team that is experiencing security failures, the answer almost always involves embedding security into the existing pipeline rather than creating a separate security review stage.

Security Activities by Phase

Regardless of the methodology, software moves through conceptual phases. Each phase has specific security activities that a security manager should govern.

Requirements Gathering

This is where security requirements originate. If security is absent from requirements, it will be absent from the product.

• Abuse cases and misuse cases — Traditional use cases describe what the system should do. Abuse cases describe what an attacker would try to do. Misuse cases describe how legitimate users might unintentionally cause harm. Both are documented alongside functional requirements.
• Security requirements — Authentication strength, authorization model, data protection requirements, audit logging, regulatory compliance needs, and privacy constraints are defined here.
• Security acceptance criteria — Define what “done” means from a security perspective. A feature is not complete until it meets its security acceptance criteria, not just its functional criteria.

Design

Architecture and design decisions have the greatest influence on the final security posture of the software.

• Threat modeling — Structured analysis of the system design to identify threats, vulnerabilities, and countermeasures before code is written. Methods include STRIDE, PASTA, and VAST. The exam expects you to know that threat modeling belongs in design and should be updated when the design changes.
• Secure design principles — Least privilege, defense in depth, fail secure, separation of duties, economy of mechanism. These principles are applied during architectural decisions.
• Attack surface analysis — Identify and document every point where the system accepts input, exposes data, or interacts with external systems. The goal is to minimize the attack surface through design.

Development (Implementation)

• Secure coding standards — Developers follow approved coding standards (OWASP, CERT, MISRA) that address common vulnerability patterns
• Peer code review — Security-focused review of code changes before merge
• Static analysis — Automated tools scan source code for known vulnerability patterns during development

Testing

• Security testing — Dynamic analysis (DAST), fuzz testing, and penetration testing validate that the running application resists attack
• Regression testing — Security fixes are tested to confirm they did not introduce new vulnerabilities or break existing security controls
• Security acceptance validation — The security acceptance criteria defined in requirements are formally verified

Deployment and Release

• Change management — Every release goes through the organization’s change management process. Emergency changes still require documentation and post-deployment review.
• Configuration validation — The production environment is verified against security baselines before deployment
• CI/CD security gates — Automated checkpoints in the deployment pipeline that block releases failing security criteria (vulnerability scan thresholds, code signing verification, compliance checks)

Operations and Maintenance

• Vulnerability management — Ongoing scanning and patching of production software
• Security monitoring — Runtime monitoring for anomalous behavior, unauthorized access, or exploitation attempts
• Periodic reassessment — Threat models and security requirements are revisited when the threat environment changes or the system is significantly modified

CI/CD Security Gates

In modern development pipelines, continuous integration and continuous deployment (CI/CD) automate the path from code commit to production deployment. Security gates are automated checkpoints within this pipeline.

A well-governed CI/CD pipeline includes:

• Pre-commit hooks — Prevent secrets (API keys, passwords) from being committed to version control
• Build-time scanning — Static analysis and dependency checks run during every build
• Pre-deployment gates — Automated policy checks that block deployment if critical vulnerabilities exist or compliance requirements are unmet
• Post-deployment verification — Automated smoke tests and security checks confirm the deployed application behaves as expected

The governance question for CI/CD is: who defines the gate criteria, who can override a failed gate, and what documentation is produced when an override occurs? These are management controls, not technical ones.

Change Management for Releases

Every software release is a change to the production environment. Change management ensures that changes are authorized, tested, documented, and reversible.

• Standard changes — Pre-approved, low-risk changes that follow a documented procedure (e.g., routine patch deployments)
• Normal changes — Changes that require review and approval through the change advisory board (CAB) or equivalent
• Emergency changes — Changes deployed under urgent circumstances with abbreviated approval. Emergency changes still require post-implementation review and documentation.

The exam tests whether you understand that speed of deployment does not remove the need for change management. DevOps pipelines automate change management; they do not eliminate it.

Pattern Recognition

SDLC security integration questions on the CISSP tend to follow these structures:

• Vulnerability discovered late — The root cause is a missing security activity in an earlier phase. The answer points to the phase where it should have been caught.
• “When should security be involved?” — The answer is always “from the beginning” — specifically, during requirements gathering. If requirements is not an option, look for the earliest available phase.
• Agile security challenge — The answer integrates security into existing sprint activities rather than creating a separate security sprint or phase.
• CI/CD pipeline failure — The answer adds automated security checks to the pipeline rather than adding manual review stages that slow delivery.

Trap Patterns

Watch for these wrong answers:

• “Add a security testing phase after development” — This is the old-school approach. The exam prefers security integrated throughout, not bolted on at the end.
• “Security review by a dedicated team before release” — While not inherently wrong, this creates a bottleneck. The exam prefers answers that distribute security responsibility across the development process.
• “Developers should not be responsible for security” — Everyone who touches the software shares responsibility. Security teams govern and guide; developers implement secure code.
• “Skip change management for automated deployments” — Automation changes the mechanism of change management, not the requirement for it.

Scenario Practice

Question 1

A company using waterfall methodology discovers a critical authentication bypass during user acceptance testing, two weeks before the scheduled production release. The development team says redesigning the authentication module would delay the release by six weeks.

What should the security manager recommend?

A. Release on schedule and patch the vulnerability in the next version
B. Delay the release until the authentication module is redesigned to address the vulnerability
C. Release with compensating controls and schedule an emergency fix within 30 days
D. Transfer the risk by purchasing cyber insurance before the release

Question 2

An Agile development team completes 10 sprints without any security review. A newly hired security architect proposes adding a mandatory two-week security review between every sprint.

What is the BEST alternative approach?

A. Accept the proposal to ensure thorough security review
B. Integrate security user stories, automated security testing, and security acceptance criteria into each sprint
C. Conduct security reviews only for sprints that include high-risk features
D. Hire security-focused developers to replace the current team

Question 3

A DevOps team deploys to production 15 times per day using a fully automated CI/CD pipeline. A compliance auditor asks how change management is handled. The team responds that “automation eliminates the need for change management.”

What is the CORRECT assessment?

A. The team is correct — automated pipelines replace traditional change management
B. The auditor should accept the automation as equivalent to change management controls
C. The pipeline automates change management execution, but governance requirements (authorization, documentation, rollback capability) must still be met
D. The organization should reduce deployment frequency to allow manual change review

Key Takeaway

The SDLC is not a technical process that security observes from the outside. It is a governance framework where security activities are assigned to specific phases, measured against defined criteria, and enforced through policy. The exam will not ask you to write a threat model or configure a CI/CD pipeline. It will ask you where security activities belong, who is responsible for them, and what happens when they are missing. Remember: the cost of fixing a security defect multiplies with every phase it passes through undetected. Requirements are cheap. Production fixes are not.