cisspSoftware Development Security· 10 min read· 20 May 2026
Secure SDLC: DevSecOps, Agile Security, and Shifting Left
Software development security is the practice of integrating security throughout the software development lifecycle rather than treating it as an afterthought or a final gate. For the CISSP exam, Domain 8 tests the governance and process aspects of software security: how security fits into different development methodologies, how to assess and improve software security maturity, and what security activities belong in each phase of development.
Development Methodology Overview
Different software development methodologies integrate security in different ways, and the exam tests which methodology is being described and how security fits within each.
Waterfall is a linear, sequential development process: requirements → design → implementation → testing → deployment → maintenance. Each phase must be completed before the next begins. Security in waterfall is typically treated as a phase (security review/testing before deployment) rather than an integrated activity. This late-stage security approach means vulnerabilities discovered during security testing are expensive to fix because the code is already complete.
Agile is an iterative development approach that delivers software in short cycles (sprints, typically 2-4 weeks). Each sprint produces working software, allowing security to be incorporated incrementally. Security activities in Agile include: security stories (user stories that describe security requirements), threat modeling as part of sprint planning for significant new features, security testing within each sprint, and security acceptance criteria in the definition of done.
DevOps is a culture and practice that integrates development (Dev) and operations (Ops) teams to shorten the delivery cycle through automation, collaboration, and continuous delivery. DevOps enables rapid deployment through CI/CD (Continuous Integration/Continuous Delivery) pipelines but can create security risks if security is not integrated into the automated pipeline.
DevSecOps extends DevOps by integrating security (Sec) as an equal partner throughout the pipeline. The goal is to automate security checks so that security does not become a bottleneck to rapid delivery. Security becomes everyone's responsibility, not just the security team's.
Shift-Left: Integrating Security at Design, Not Testing
Shift-left is a security philosophy that advocates moving security activities earlier in the development lifecycle. The term comes from viewing the SDLC as a left-to-right timeline — shifting security "left" means addressing it earlier.
The economic argument for shift-left is compelling: the cost to fix a security defect increases dramatically with each phase in which it is discovered. A design flaw identified in threat modeling during requirements/design costs orders of magnitude less to fix than the same defect discovered in production after deployment.
Shift-left security activities include: security requirements definition (defining what the software must do and not do from a security perspective, derived from threat modeling and compliance requirements), threat modeling during design (identifying threats before code is written), security-focused code review and IDE plugins that flag insecure code patterns in real time, automated SAST in the CI/CD pipeline (scanning every code commit), and security unit tests that verify security properties of code as it is written.
For the exam: shift-left means security is integrated from the beginning of development, not added at the end. The exam favours "security by design" over "bolt-on security" in all Domain 8 questions.
DevSecOps: Integration Throughout the Pipeline
DevSecOps integrates security into every stage of the CI/CD pipeline:
In the planning/design phase: threat modeling and security requirements. Threats are identified before code is written.
In the development phase: secure coding guidelines, IDE security plugins (real-time SAST), peer code review with security focus, and pre-commit hooks that reject code with known security issues.
In the build phase: automated SAST runs on every code commit. Dependency scanning (SCA — Software Composition Analysis) checks open-source dependencies for known vulnerabilities. Build integrity checks verify that build tools have not been tampered with.
In the testing phase: DAST runs against the deployed application in a test environment. Penetration testing for significant releases. Security regression testing to ensure that previously fixed vulnerabilities have not been reintroduced.
In the deployment phase: infrastructure as code security scanning (checking cloud configurations for misconfigurations before deployment), deployment approval gates that require security sign-off for high-risk changes.
In the operations phase: runtime application self-protection (RASP), continuous security monitoring, and vulnerability management for the deployed application.
For the exam: DevSecOps integrates security throughout — not at the end. Every phase has associated security activities. The pipeline automates as many security checks as possible to provide speed without sacrificing security.
SAMM and CMMI: Software Security Maturity Models
Maturity models provide frameworks for assessing and improving software security practices. Two maturity models appear in CISSP contexts.
SAMM (Software Assurance Maturity Model), developed by OWASP, is specifically designed for software security. It defines five business functions (Governance, Design, Implementation, Verification, Operations) and three security practices for each. Each practice has three maturity levels. SAMM allows organisations to assess their current software security maturity, identify gaps, and plan improvements.
CMMI (Capability Maturity Model Integration), originally developed for process improvement, is applied to software development maturity broadly. The five maturity levels are: Initial (processes are unpredictable, reactive), Managed (processes are planned and tracked), Defined (processes are standardised across the organisation), Quantitatively Managed (processes are measured and controlled), and Optimising (processes are continuously improved through feedback).
For the exam: SAMM is the software-specific security maturity model. CMMI is the broader process maturity model. Both can be used to assess and improve development practices.
CI/CD Pipeline Security: Securing the Build Process
The CI/CD pipeline automates the building, testing, and deployment of software. Securing the pipeline itself is essential — a compromised build system can insert malicious code into otherwise secure applications (as demonstrated by the SolarWinds attack).
Pipeline security includes: access control to the pipeline (only authorised developers can trigger builds and deployments), integrity verification of build tools and dependencies (preventing dependency confusion or supply chain attacks), secrets management (API keys, certificates, and credentials used by the pipeline must not be hardcoded in code or pipeline configurations), build immutability (signed build artefacts that can be verified before deployment), and audit logging of all pipeline activities.
Change Management in Software Development
Change management in software development ensures that code changes are reviewed, approved, and documented before being deployed to production. Key change management activities include: code review (human review of all changes before merge), automated testing gates (CI/CD pipeline must pass all tests before deployment is allowed), change advisory board (CAB) approval for significant releases, and rollback procedures (the ability to quickly revert to the previous version if a deployment causes issues).
For the exam: change management gates in software development are a preventive control that catches security issues before they reach production. Bypassing change management — even for urgent fixes — increases risk.
Exam Tip
DevSecOps integrates security throughout — CISSP favours 'security by design' over bolt-on security. Shift-left means finding and fixing security issues during design and development, not during testing or production. The exam will ask which phase security activities belong to: threat modeling belongs to design, SAST belongs to development/build, DAST belongs to testing. The correct answer is always the earliest phase where the activity can be performed effectively.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Software Development Security
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.