CISSP Domain 8, Software Development Security, is weighted at 11% of the exam and is the domain most affected by the shift to DevOps, cloud-native development, and continuous delivery. The trap is treating Domain 8 as a coding exam. The (ISC)² CBK does not test syntax; it tests how a security manager makes development organisations safer by design - by integrating security into the SDLC, choosing development models that fit their context, and managing the inherited and ongoing risk of every line of code their teams write or import.
This guide collects the 14 in-depth Domain 8 articles on Threat on the Wire into one structured reference. Use it as a study path or a topic index. Every article assumes you understand modern software delivery and want clarity on how the manager-mindset frame applies to it.
What Domain 8 is really testing
CISSP lens: the right answer makes secure development the default path. Pick the option that builds security in early rather than bolting it on late.
Domain 8 has three big themes. First, the lifecycle: how secure SDLC practices fit into different development models (waterfall, agile, DevOps). Second, the controls: what security testing techniques, secure coding practices, and architectural patterns reduce risk in software. Third, the governance: how a manager runs a software security program with metrics, third-party risk management, and privacy and compliance obligations baked in.
You will be tested on:
- Secure SDLC fundamentals across development models.
- Secure coding foundations and the manager's role.
- Threat modeling for software systems.
- Application access control and identity inside applications.
- Database and data-layer security.
- Secure deployment, configuration, and environment management.
- DevSecOps and continuous security in real teams.
- Security testing in the SDLC without breaking the release train.
- Software security governance, metrics, and reporting.
- Third-party and open-source software risk.
- Legacy systems and technical debt management.
- Privacy and compliance integrated into the SDLC.
How Domain 8 fits into the rest of the CBK
Domain 8 is where the architectural reasoning of Domain 3 meets the operational realities of Domain 7 at the application level. The application access control patterns here mirror the IAM work in Domain 5. The testing techniques (SAST, DAST, IAST, SCA) are the application-side of Domain 6 testing. The privacy and compliance requirements come from Domain 1 and Domain 2.
If a Domain 6 question is about SAST in a CI pipeline, you are answering it with Domain 8 reasoning. The lines blur deliberately on the exam.
Core concepts at a glance
| Concept | What it is | Why it matters on the exam |
|---|---|---|
| Secure SDLC | Security activities built into each phase of the SDLC | Domain 8's organising idea |
| Shift left | Catch security issues earlier in the lifecycle | Cheaper, faster, more effective than late testing |
| SAST | Static analysis of source code | Catches known patterns early |
| DAST | Dynamic analysis of running applications | Catches runtime issues a SAST tool cannot see |
| SCA | Software Composition Analysis | Open-source dependency vulnerability scanning |
| SBOM | Software Bill of Materials | Manifest of components for incident scoping |
| Threat modeling | Structured analysis of how a system can be attacked | STRIDE / PASTA / attack trees |
| Secure-by-default | Out-of-the-box configuration is safe | Tested as a design principle |
| Privacy by design | Privacy obligations baked into design | Cross-listed with Domain 2 |
| DevSecOps | Security integrated into DevOps practice | Cultural and technical; tested as both |
| Technical debt | Accumulated maintenance and security work deferred | Tested with legacy-system scenarios |
| SCRM | Supply Chain Risk Management for software | Domain 1 + Domain 8 overlap |
Secure SDLC fundamentals
Modern development takes many shapes - waterfall in regulated industries, agile in product teams, DevOps in cloud-native shops, hybrids everywhere. Each model has different security integration points.
Start with Secure SDLC Without the Buzzwords: Making Security Part of How You Build. Then read Waterfall, Agile, DevOps: Where Security Fits in Each Development Model for the model-by-model breakdown.
Where security fits in each model
| Model | Security integration points | Strengths and risks |
|---|---|---|
| Waterfall | Requirements, design, code review, formal testing, sign-off | Strong for regulated environments; slow to adapt |
| Agile | Story-level threat modeling, in-sprint code review, sprint security reviews | Adaptive; risk of skipping security in sprint pressure |
| DevOps / DevSecOps | Pipeline-integrated SAST/DAST/SCA, IaC scanning, runtime protection | Fastest feedback; needs cultural and tooling investment |
Secure coding for managers
You do not need to write code to manage software security, but you do need to recognise the categories of code-level vulnerability and the controls that prevent each. Secure Coding Foundations for Managers covers OWASP Top 10 patterns, input validation, output encoding, parameterised queries, secrets handling, and the secure-coding-standard discipline that turns vulnerability lists into team behaviour.
Threat modeling that teams will actually do
Threat modeling is the bridge between architecture and code. Threat Modeling That Busy Teams Will Actually Do covers STRIDE, attack trees, and the lightweight ceremony that fits into agile cadence without grinding feature work to a halt.
Application access control and identity
The IAM concepts from Domain 5 show up at the application level too. Access Control and Identity Inside Applications covers authentication and authorisation patterns inside web and API applications: session management, JWT validation, RBAC vs ABAC at the code level, multi-tenant isolation, and the OWASP-listed access-control failure modes the exam tests.
Database and data-layer security
The most valuable target in any application is its data. Database and Data Layer Security in Applications covers parameterised queries, ORM safety, encryption at the data layer (TDE, application-level encryption, tokenisation), and the data-layer governance that prevents an SQL injection from becoming a regulator-reportable breach.
Secure deployment and configuration
Code that is secure in development can become insecure in deployment. Secure Deployment, Configuration, and Environment Management covers infrastructure-as-code security, secrets management, environment parity, and the deployment-pipeline controls that prevent "it worked in staging" from becoming "it leaked in production."
DevSecOps in real teams
DevSecOps is more than tooling; it is a cultural shift in how security and development relate. DevSecOps and Continuous Security in Real Teams covers the cultural patterns (security champions, paved paths, secure-by-default tooling), the metrics that prove it is working, and the failure modes that make a "DevSecOps program" theatre.
Security testing in the SDLC
Application testing is the application-side of Domain 6 testing. Security Testing in the SDLC Without Breaking the Release Train covers SAST, DAST, IAST, SCA, and the fuzz-testing and manual review that complement automated tools.
Software security governance and metrics
A software security program needs governance, just like any other security program. Software Security Governance and Metrics covers the program structure, the metrics that track progress (escape rate, MTTR for vulnerabilities, security-debt trend), and the executive reporting that keeps the program funded.
Third-party and open-source software risk
Most modern software is mostly third-party software. Managing Third-Party and Open-Source Risk in Software covers SBOM, SCA, license compliance, vulnerability tracking on dependencies, and the program-level decisions that prevent the next Log4j-style incident from being your next incident. This material overlaps with the supply-chain governance in Domain 1's SCRM article.
Legacy systems and technical debt
The biggest software-security risks usually live in the systems nobody owns and nobody wants to touch. Managing Legacy Systems and Technical Debt Securely covers the assessment, the migration vs. compensating-controls trade-off, and the programmatic approach to retiring or hardening legacy code paths over time.
Privacy and compliance in the SDLC
Privacy obligations from GDPR, HIPAA, CCPA, and local regulations end up in the SDLC sooner or later. Privacy and Compliance in the Software Development Lifecycle covers privacy by design, data-minimisation requirements, consent-handling patterns, and the integration with the privacy-by-design material in Domain 2.
Real-world software-security scenarios
An app-sec lead is told a critical CVE has been disclosed in a logging library used across the company. The technical instinct is to push patches everywhere. The lead instinct is broader. First, identify scope - which applications and services use the affected library? An SBOM makes this trivial; without one, you are scanning code repositories. Second, prioritise - internet-exposed services first, internal services second, batch and offline workloads third. Third, deploy - patch where possible, deploy compensating controls (WAF rules, network restrictions) where patching is slow. Fourth, monitor - look for exploitation attempts in the meantime. Fifth, post-incident review the SBOM gap and the response time. Domain 8 questions reward this SBOM-aware, prioritised response.
A second example: a security manager is reviewing the proposal to migrate a legacy monolith to microservices. The technical instinct is to applaud. The manager instinct adds a security overlay: the new architecture has more attack surface (more service-to-service communication, more deployments, more secrets), more identity complexity (service-to-service auth), and more visibility blind spots (distributed tracing required to see what was once a single process). The right answer is not "do not migrate" but "build security into the migration plan from day one - threat model the new architecture, instrument observability before cut-over, and budget for the security work explicitly."
Common exam traps in Domain 8
- Picking SAST when the question wants runtime issues. SAST analyses source code; DAST analyses the running application. The right tool depends on the issue.
- Treating DevSecOps as tooling alone. DevSecOps is a cultural and process shift. Tools alone produce DevSec-Theatre.
- Choosing late testing as the answer. The exam favours shifting security left whenever possible.
- Ignoring SBOM and SCA. Open-source vulnerability management is a Domain 8 testable topic. The exam will offer "we use SAST" as a wrong answer to "how do you find vulnerable open-source components."
- Confusing parameterised queries with input validation. Parameterised queries prevent SQL injection by separating code from data. Input validation prevents broader categories of bad input. Both are needed; the exam tests them as distinct controls.
- Treating threat modeling as a one-time activity. Threat modeling is iterative. The exam favours teams that update threat models as systems evolve.
- Skipping the cultural side of DevSecOps. Security champions, paved paths, and secure-by-default tooling are program-level answers; "we have SAST in the pipeline" is not enough.
The full Domain 8 reading order
SDLC foundations
- Secure SDLC Without the Buzzwords
- Waterfall, Agile, DevOps: Where Security Fits
- Secure Coding Foundations for Managers
Threat modeling
Application controls
Deployment and DevSecOps
- Secure Deployment, Configuration, and Environment Management
- DevSecOps and Continuous Security in Real Teams
- Security Testing in the SDLC
Governance and metrics
Supply chain and legacy
Privacy and compliance
Exam scenario practice
Related CISSP domains
Threat on the Wire publishes a long-form pillar for every CISSP domain. The eight domains are interlocked - mastering any one of them is easier when you can see how it connects to the others. Here's how this domain relates to the other seven, with a one-line summary of the relationship and a link to the pillar.
| Pillar | How it relates to this domain |
|---|---|
| Domain 1: Security and Risk Management | Domain 1 supply-chain governance extends into Domain 8 third-party software risk. |
| Domain 2: Asset Security | Privacy-by-design from Domain 2 is integrated into the SDLC here. |
| Domain 3: Security Architecture and Engineering | Secure software architecture from Domain 3 frames the secure SDLC in Domain 8. |
| Domain 4: Communication and Network Security | Application network design integrates Domain 4 networking with the SDLC. |
| Domain 5: Identity and Access Management | Application access control is Domain 5 reasoning applied at the code level. |
| Domain 6: Security Assessment and Testing | Application security testing (SAST, DAST, SCA) is a Domain 6 plus Domain 8 overlap. |
| Domain 7: Security Operations | Application-level operations (deployment, patching) bridge Domain 7 and Domain 8. |
For the full CISSP overview, exam structure, and 12-week study plan, see the CISSP Study Hub.
Frequently asked questions
How much of the CISSP exam covers Domain 8?
Domain 8 is weighted at 11% of the exam. Out of roughly 100-150 items, expect 11-17 from Domain 8. The reasoning shows up in Domain 6 testing questions, Domain 7 operational questions, and Domain 5 IAM questions where applications meet identity.
Do I need to be a programmer to pass Domain 8?
No. The exam tests management-level reasoning, not syntax. You should recognise the categories of code-level vulnerability (OWASP Top 10), understand what each test type catches, and know how to integrate security into different SDLC models. You do not need to write or read code on the exam.
What does "shift left" mean for security?
It means moving security activities earlier in the SDLC - from "find bugs in production" to "find bugs in design and code review." Cheaper, faster, and more effective than catching issues at deploy time. The exam favours shift-left answers in scenario questions about SDLC integration.
What is an SBOM and why does it matter?
A Software Bill of Materials is a manifest of every component (libraries, frameworks, OS packages) that goes into a piece of software. It matters because when a vulnerability like Log4Shell is disclosed, an SBOM lets you answer "are we affected?" in minutes instead of weeks. The exam increasingly tests SBOM and SCA as program-level answers to supply-chain risk.
Is DevSecOps just adding security tools to the CI/CD pipeline?
No. Tools without process, culture, and ownership produce noise: alerts that nobody triages, broken builds that get bypassed, and metrics that nobody acts on. DevSecOps is the cultural and process shift that makes the tooling produce outcomes. The exam tests both layers.
Key takeaways
- Domain 8 is software security at the manager level. The exam does not test syntax; it tests how you make development organisations safer.
- Secure SDLC integrates security into every phase, regardless of development model. Waterfall, agile, and DevOps each have different integration points.
- Shift left: catch security issues earlier. SAST, code review, and threat modeling at design time beat late-stage penetration tests.
- Test types pair to questions: SAST for source code patterns, DAST for runtime behaviour, IAST for hybrid context, SCA for dependencies.
- Threat modeling is iterative. STRIDE and PASTA are testable frameworks; the exam tests their use as ongoing practice, not one-time activity.
- SBOM, SCA, and dependency management are first-class concerns. Most modern software is mostly third-party software.
- DevSecOps is cultural and technical. Security champions, paved paths, and secure-by-default tooling matter as much as the scanners.
If you take one thing away from Domain 8, take this: the cheapest secure code is the secure code your developers write by default. Build the program so the secure path is also the easy path, and software security stops being a cost centre and starts being an asset.