Overview
Software Development Security covers how organizations make software secure whether they build it or buy it. Its five sub-objectives are integrating security into the software development life cycle (methodologies such as Agile, Waterfall, DevOps, DevSecOps and the Scaled Agile Framework; maturity models such as CMM and SAMM; operations, maintenance, change management and integrated product teams); applying security controls across development ecosystems (languages, libraries, tool sets, IDEs, runtimes, CI/CD, software configuration management, code repositories and application security testing); assessing software security effectiveness; assessing the security impact of acquired software; and defining secure coding guidelines.
Candidates need a manager's view of development: where in the lifecycle a control belongs, which testing tool finds which flaw, and how to govern third-party, open-source and SaaS risk. The domain extends Domain 3's system lifecycle and design principles into code, and it relies on Domain 6 testing concepts and Domain 1 supply chain risk management.
How it's tested
Domain 8 questions ask where security belongs in development and which control or test fits a situation. Expect scenarios about choosing a testing tool, responding to a vulnerable open-source component, securing a CI/CD pipeline, evaluating a vendor's software, or fixing a class of coding flaw. Clues include whether source code is available, whether the application is running, and whether software is built or bought.
-
Earliest effective control
A security problem was found late, and the right answer moves a control earlier in the lifecycle, such as security requirements or threat modeling during design.
-
Match the test to the access
Source code, a running application, or both are available, and you choose SAST, DAST, IAST or software composition analysis.
-
Govern acquired software
COTS, open-source, SaaS or managed services are being adopted, and you choose the assessment or contract control that addresses their risk.
A company buys a commercial application without source code access and must find injection flaws before launch. SAST needs source code, and software composition analysis inventories components but does not test the running application's logic. DAST tests the running application from the outside by sending crafted inputs, which works without source code. Combined with contractual security requirements for the vendor, DAST is the best answer.
Sub-objectives 5
Official sub-objectives from the ISC2 outline, in outline order.
8.1 Understand and integrate security in the Software Development Life Cycle (SDLC)Methodologies, maturity models, operation and maintenance, change management and integrated product teams.
- What it means
- This covers development methodologies (Agile, Waterfall, DevOps, DevSecOps, Scaled Agile Framework), maturity models such as the Capability Maturity Model (CMM) and the Software Assurance Maturity Model (SAMM), operation and maintenance, change management and integrated product teams.
- What to understand
- Security requirements belong in the first phase, because fixing a design flaw after release costs far more than preventing it. In Agile and DevSecOps, security is built into each sprint and automated in the pipeline rather than gated at the end. CMM levels run from Initial (1) through Repeatable or Managed (2), Defined (3) and Quantitatively Managed (4) to Optimizing (5).
- How it shows up
- A security review at the end of each release keeps delaying launches, and the BEST fix is integrating security requirements, threat modeling and automated testing into each iteration.
- Common confusion
- Treating DevSecOps as a tool purchase; it is a cultural and process change that shares security responsibility across development, security and operations.
8.2 Identify and apply security controls in software development ecosystemsLanguages, libraries, tool sets, IDEs, runtime, CI/CD, SCM, code repositories and application security testing.
- What it means
- The development ecosystem includes programming languages, libraries, tool sets, integrated development environments, runtimes, continuous integration and continuous delivery (CI/CD), software configuration management, code repositories and application security testing: SAST, DAST, software composition analysis and IAST.
- What to understand
- SAST analyzes source or binaries without running them and finds flaws early; DAST tests a running application from outside; IAST instruments the running application to observe code paths during testing; software composition analysis identifies third-party components and their known vulnerabilities and licenses. CI/CD pipelines need protected secrets, signed artifacts, least-privilege build agents and branch protection, because a compromised pipeline delivers malicious code to every user.
- How it shows up
- Developers committed API keys to a public repository, and the answer combines secret scanning in the pipeline, key revocation and a secrets vault.
- Common confusion
- Expecting SAST to find runtime configuration flaws, or DAST to point to the exact vulnerable line of code.
8.3 Assess the effectiveness of software securityAuditing and logging of changes, and risk analysis and mitigation.
- What it means
- Assessing software security effectiveness means verifying that security controls in software work and continue to work, through auditing and logging of changes, and through risk analysis and mitigation of identified weaknesses.
- What to understand
- Change logs in repositories and pipelines provide accountability for who changed what and when, which supports both incident investigation and audit. Findings from testing must feed a risk-based remediation process, with severity and exploitability guiding priority rather than finding counts alone.
- How it shows up
- Unauthorized code reached production and nobody can tell who introduced it, pointing to missing change auditing and logging in the repository and pipeline.
- Common confusion
- Measuring software security by the number of findings closed rather than by risk reduction.
8.4 Assess security impact of acquired softwareCOTS, open source, third-party, managed services and cloud services.
- What it means
- Acquired software includes commercial off-the-shelf (COTS) products, open-source components, third-party developed code, managed enterprise applications, and cloud services in SaaS, IaaS and PaaS models.
- What to understand
- You cannot test or fix acquired software the way you can your own, so assurance comes from vendor assessments, contracts, certifications, SBOMs, testing what you can, and monitoring. Under shared responsibility, SaaS leaves the customer responsible mainly for data, identities and configuration, while IaaS leaves the customer responsible for operating systems and applications as well.
- How it shows up
- A business unit wants to adopt a SaaS tool, and the FIRST step is a security assessment of the provider, including its attestations and contract terms.
- Common confusion
- Assuming open source is either inherently secure because many eyes review it, or inherently unsafe; it needs the same composition analysis and patching as any dependency.
8.5 Define and apply secure coding guidelines and standardsSource-code weaknesses, API security, secure coding practices and software-defined security.
- What it means
- This covers security weaknesses and vulnerabilities at the source-code level, API security, secure coding practices and software-defined security, where security controls are expressed and enforced as code.
- What to understand
- Most injection flaws are prevented by parameterized queries and server-side input validation, and cross-site scripting by context-aware output encoding. APIs need authentication, authorization on every object, rate limiting and input validation. Guidelines such as the OWASP Top 10 and CWE give a shared vocabulary for weaknesses.
- How it shows up
- A login form is vulnerable to SQL injection, and the BEST fix is parameterized queries rather than a web application firewall rule alone.
- Common confusion
- Relying on client-side validation, which attackers bypass by sending requests directly to the server.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Shift left
Moving security activities such as requirements, threat modeling and testing earlier in the development lifecycle.
- Remember
- Defects are cheapest to fix when found early, especially design flaws.
- Tested as
- Where-should-security-go questions.
- Trap
- Choosing a pre-release penetration test as the primary control.
-
SAST
Static application security testing analyzes source code or binaries without executing them.
- Remember
- Needs code access, runs early, pinpoints the line, but produces false positives and misses runtime issues.
- Tested as
- Tool selection questions.
- Trap
- Choosing SAST when only a running third-party application is available.
-
DAST
Dynamic application security testing probes a running application from the outside, like an attacker.
- Remember
- No source code needed; finds runtime and configuration issues but cannot show the vulnerable line.
- Tested as
- Testing acquired or deployed applications.
- Trap
- Expecting it early in development before anything runs.
-
IAST
Interactive application security testing uses agents inside a running application to observe code execution during tests.
- Remember
- Combines runtime context with code-level detail and lower false positives.
- Tested as
- Advanced testing questions.
- Trap
- Confusing it with runtime protection that blocks attacks in production.
-
Software composition analysis
Identifies open-source and third-party components, their versions, known vulnerabilities and license obligations.
- Remember
- It produces or checks against an SBOM and is the answer for vulnerable library questions.
- Tested as
- Dependency and supply chain risk.
- Trap
- Choosing SAST to find vulnerable third-party libraries.
-
DevSecOps
Integrating security into DevOps culture and automation so security checks run continuously in the pipeline.
- Remember
- Shared responsibility and automation, not a separate gate at the end.
- Tested as
- Methodology questions.
- Trap
- Treating it as adding a security team sign-off before each release.
-
CMM levels
Initial, Repeatable (or Managed), Defined, Quantitatively Managed and Optimizing.
- Remember
- Level 3 means organization-wide standard processes; level 5 means continuous process improvement.
- Tested as
- Maturity model questions.
- Trap
- Mixing up levels 4 and 5.
-
SAMM
The OWASP Software Assurance Maturity Model measures and improves secure development practices across governance, design, implementation, verification and operations.
- Remember
- It is specific to software security, unlike general process maturity models.
- Tested as
- Maturity assessment questions.
- Trap
- Using CMM when the question is specifically about software assurance practices.
-
CI/CD pipeline security
Protecting build and deployment automation through secrets management, signed artifacts, branch protection and least-privilege build agents.
- Remember
- A compromised pipeline can push malicious code to every deployment.
- Tested as
- Development ecosystem questions.
- Trap
- Securing production servers while leaving build servers with broad credentials.
-
Injection prevention
Parameterized queries or prepared statements keep user input from being interpreted as commands.
- Remember
- Fix at the code level; WAFs and input filtering are supplementary.
- Tested as
- Secure coding questions.
- Trap
- Choosing a WAF as the complete fix.
-
API security
Authenticate callers, authorize access to each object and function, validate input, rate-limit and log API use.
- Remember
- Broken object-level authorization, where an ID can be changed to access another user's record, is a leading API flaw.
- Tested as
- Secure coding and design questions.
- Trap
- Assuming an API is safe because it is not linked from the user interface.
-
Acquired software assurance
Gaining confidence in COTS, open-source, third-party and cloud software through assessments, contracts, SBOMs, testing and monitoring.
- Remember
- Contract security requirements before purchase; leverage is lost after signing.
- Tested as
- Procurement scenarios.
- Trap
- Relying on a vendor's marketing claims without independent evidence.
-
Software-defined security
Expressing security controls as code, such as policy-as-code and automated security configuration, managed through the same pipelines as software.
- Remember
- Policy code needs version control, review and testing like application code.
- Tested as
- Modern development ecosystem questions.
- Trap
- Exempting security code from change control because security owns it.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SAST vs. DAST vs. IAST vs. SCA
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SAST | Analyzes code without running it | Needs source or binaries; earliest in lifecycle; shows exact location | Using it to test a vendor application without code |
| DAST | Attacks the running application from outside | No code needed; finds runtime and configuration flaws | Expecting it to identify the faulty line of code |
| IAST | Agents observe code during runtime testing | Combines runtime behavior with code-level insight | Confusing it with production blocking tools |
| Software composition analysis | Inventories third-party components and known vulnerabilities | Focuses on dependencies and licenses, not custom code | Expecting it to find flaws in the organization's own code |
Waterfall vs. Agile vs. DevSecOps
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Waterfall | Sequential phases with formal sign-off | Security fits naturally at phase gates but late changes are costly | Assuming security can be added only at testing |
| Agile | Short iterative sprints delivering working software | Security must be built into each sprint's stories and definition of done | Deferring security to a final hardening sprint |
| DevSecOps | Development, security and operations share responsibility with automation | Security checks run continuously in CI/CD | Treating it as a tool rather than a culture and process change |
SaaS vs. PaaS vs. IaaS customer responsibility
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SaaS | Provider runs the full application | Customer manages data, identities and configuration | Assuming the provider controls who in your company has access |
| PaaS | Provider runs the platform; customer deploys code | Customer secures application code and data | Ignoring secure coding because the platform is managed |
| IaaS | Provider runs infrastructure | Customer secures operating systems, middleware, applications and data | Expecting the provider to patch guest operating systems |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Test security in at the end
- What candidates pick
- A thorough penetration test just before release as the main security control.
- Why it looks right
- It finds real, exploitable issues.
- Why it's wrong
- Late testing finds problems when they are most expensive to fix; security requirements and design review prevent them.
Clue to watch for The question asks where security is MOST effective or how to reduce recurring late findings.
-
SAST without source
- What candidates pick
- Running SAST on a purchased product delivered without source code.
- Why it looks right
- SAST is a well-known application testing tool.
- Why it's wrong
- SAST needs source or binaries the organization may not have; DAST works against the running application.
Clue to watch for Commercial or vendor software, no code access.
-
WAF as the fix
- What candidates pick
- Adding a web application firewall rule to fix SQL injection permanently.
- Why it looks right
- It is fast and does not need developer time.
- Why it's wrong
- A WAF is a compensating control that can be bypassed; parameterized queries fix the root cause.
Clue to watch for The question asks for the BEST or most effective long-term fix.
-
Scan our code for library flaws
- What candidates pick
- SAST to identify vulnerable open-source libraries.
- Why it looks right
- SAST scans the code base.
- Why it's wrong
- Software composition analysis is designed to identify components and match them to known vulnerabilities.
Clue to watch for Third-party or open-source dependencies and a published CVE.
-
DevSecOps means a security gate
- What candidates pick
- Adding a mandatory manual security approval before every deployment.
- Why it looks right
- It looks like strong control.
- Why it's wrong
- DevSecOps automates security in the pipeline and shares responsibility; manual end gates slow delivery and push teams to work around them.
Clue to watch for Frequent releases and a goal of integrating security into DevOps.
-
Client-side validation is enough
- What candidates pick
- Relying on JavaScript input checks to block malicious input.
- Why it looks right
- It gives users immediate feedback.
- Why it's wrong
- Attackers bypass the browser and send requests directly; validation must happen on the server.
Clue to watch for Input validation implemented only in the browser or mobile app.
Answer framework
For Domain 8 scenarios, decide whether the software is built or bought and where in the lifecycle you are before choosing a control.
- Determine whether the software is developed in-house, acquired as COTS or open source, or consumed as a cloud service, since your control options differ sharply for each.
- Place the problem in the lifecycle and prefer the earliest effective control: requirements, design and threat modeling before code, and code fixes before compensating controls.
- Match testing to available access: SAST for source, DAST for running applications, IAST for instrumented test environments and software composition analysis for dependencies.
- Protect the development ecosystem itself, including repositories, secrets, build agents and CI/CD pipelines, with least privilege, signing and change logging.
- Govern acquired software through assessments, contracts, SBOMs and shared responsibility, and track remediation by risk rather than by finding counts.
Practice question
Want more like this? The CISSP practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the SDLC and methodologies (8.1) so you know where each control belongs, then study the development ecosystem and testing tools (8.2) using a comparison table for SAST, DAST, IAST and software composition analysis. Follow with acquired software (8.4), which ties into Domain 1 supply chain risk, and finish with secure coding (8.5) and assessing effectiveness (8.3).
High-priority concepts are shift left, the testing tool distinctions, CI/CD pipeline security, CMM levels and shared responsibility for acquired cloud services. Commonly underestimated areas are software configuration management and change logging, which feel administrative but appear in scenarios about unauthorized code, and the 2024 additions such as the Scaled Agile Framework and software-defined security.
You do not need to write code for this domain. Focus on the security outcome of each practice and on the manager's question of where to invest effort. After this domain, revisit Domain 6 code testing and coverage analysis and Domain 3 secure design principles, then practice mixed sets so you recognize when a question that looks like Domain 8 is really asking a governance question.
FAQ
Do I need to be a developer to pass Domain 8?
No. The exam tests how to govern and secure development, such as where controls belong, which test fits a situation and how to assess acquired software. Understanding common flaw types helps, but you will not write code.
What is the difference between SAST and DAST?
SAST analyzes code without running it and finds issues early with exact locations. DAST tests a running application from the outside, needs no source code and finds runtime and configuration issues.
Which maturity models should I know?
The outline names the Capability Maturity Model (CMM) and the Software Assurance Maturity Model (SAMM). Know the five CMM levels and that SAMM focuses specifically on software security practices.
How does DevSecOps change security's role?
Security becomes a shared responsibility built into automated pipelines and team practices, rather than a separate gate at the end. Security teams provide tooling, guardrails and expertise instead of approving every release manually.
How is acquired software assessed if I cannot see the code?
Through vendor security assessments, contract requirements, independent attestations, SBOMs, testing the running product with DAST, and monitoring for vulnerabilities after deployment.
How does Domain 8 overlap with Domain 1?
Domain 1 covers supply chain risk management, including SBOMs and third-party assessment. Domain 8 applies those ideas to software specifically, through software composition analysis and acquired software assessment.
How long should I study Domain 8?
Our editorial planning estimate is 20 to 30 hours within a 250-hour plan. Candidates new to development should budget toward the top of that range.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 8 knowledge
You have covered the secure SDLC, development ecosystem controls, testing tools, acquired software and secure coding. Check whether you can pick the earliest effective control in development scenarios.