CISSP Domain 8 Revision: Software Development Security

Domain 8 closes the CBK by asking whether security has been built into software from the start, rather than tested for and patched in afterwards. It's a smaller domain in weighting, but it sits close to Domain 6's testing concepts and Domain 3's system architecture, so weakness here tends to compound weakness elsewhere. Treat it as the domain that ties the whole development side of the syllabus together.

Security in the Software Development Life Cycle

Development methodologies shape how and when security activity actually happens. Waterfall's sequential structure allows security requirements to be defined clearly upfront, but makes late-stage security findings expensive to address since earlier phases are effectively closed by the time testing occurs. Agile's iterative structure allows security to be revisited every sprint, but risks being deprioritised under delivery pressure if it isn't deliberately built into each iteration's definition of done. DevOps blends development and operations into a continuous delivery pipeline, and DevSecOps extends that further by embedding security activity directly into the pipeline itself rather than treating it as a separate gate. The Scaled Agile Framework applies agile principles across larger, multi-team programmes, and the security challenge there is consistency, ensuring security practice doesn't fragment differently across teams working at scale.

Maturity models give organisations a way to measure how consistently secure development practice is actually applied, rather than assuming good intentions translate automatically into good outcomes. The Capability Maturity Model assesses process maturity generally, while the Software Assurance Maturity Model applies that same thinking specifically to secure software development practice, letting an organisation benchmark itself against defined maturity levels rather than relying on a vague sense that things are "going well."

Operation and maintenance extends security responsibility well past initial release, since a system that was secure at launch can still accumulate risk over its operational life if it isn't maintained with the same discipline. Change management, reappearing from Domain 7, applies equally to software changes, and Integrated Product Teams bring security expertise directly into development teams rather than treating it as an external function reviewing work after the fact.

Security controls in software development ecosystems

This objective covers the practical tooling and environment surrounding development, and the exam expects awareness of where risk enters at each stage.

Programming languages carry inherent security characteristics, memory-unsafe languages like C introduce risks that memory-safe languages largely avoid by design, and language choice is itself a security decision worth making deliberately rather than by default. Libraries introduce third-party code and, with it, third-party risk, connecting directly to the software composition analysis concept later in this objective. Tool sets and Integrated Development Environments need appropriate access control and configuration, since a compromised development environment can inject malicious code before it ever reaches a repository. Runtime environments need hardening in production just as much as the code running inside them does.

Continuous Integration and Continuous Delivery pipelines automate build, test and deployment, and security needs to be embedded within that automation rather than bolted on as a manual step at the end, since a manual gate at the end of an automated pipeline tends to become the first thing skipped under delivery pressure. Software configuration management tracks changes to code and configuration over time, giving traceability when something needs to be rolled back or investigated. Code repositories need their own access control and audit logging, since the repository itself is a high-value target, holding not just current code but often historical secrets accidentally committed and never fully removed.

Application security testing spans four distinct techniques worth being able to distinguish clearly:

• Static Application Security Testing (SAST): analyses source code without executing it, catching issues early but sometimes producing false positives since it lacks runtime context.
• Dynamic Application Security Testing (DAST): tests a running application from the outside, without access to source code, catching issues that only manifest at runtime but unable to pinpoint the exact line of code responsible.
• Software Composition Analysis (SCA): identifies known vulnerabilities in third-party libraries and dependencies, increasingly critical given how much modern software is assembled from open source components rather than written from scratch.
• Interactive Application Security Testing (IAST): combines elements of both SAST and DAST, instrumenting an application during runtime testing to get visibility into both the code and its actual execution behaviour.

Assessing the effectiveness of software security

Auditing and logging of changes provides the evidence trail that shows security practice is genuinely being followed, mirroring the process data collection covered in Domain 6. Risk analysis and mitigation applied specifically to software means treating identified vulnerabilities the same way Domain 1's risk framework treats any other risk: assessed, prioritised, and either remediated, accepted, transferred, or avoided, rather than defaulting to fixing everything with equal urgency regardless of actual impact.

Assessing the security impact of acquired software

Not all software risk originates internally, and this objective covers the risk introduced by software an organisation didn't build itself.

Commercial-off-the-shelf software carries risk tied to vendor patching practice and support lifespan, echoing the End of Support concerns from Domain 2. Open source software offers transparency, since the code itself can be reviewed, but that transparency doesn't guarantee anyone has actually reviewed it, and the exam expects awareness that popularity isn't the same as security scrutiny. Third-party software more broadly needs the same supply chain diligence introduced in Domain 1. Managed services and enterprise applications shift some operational burden to a vendor but don't eliminate the organisation's own accountability for the data those services process. Cloud services, SaaS, IaaS and PaaS specifically, bring the shared responsibility model back into play, since the security boundary between what the provider secures and what the customer must secure themselves varies by service type and needs to be understood precisely rather than assumed.

Defining and applying secure coding guidelines and standards

The final objective grounds the domain in the actual practice of writing code securely.

Security weaknesses and vulnerabilities at the source-code level cover the recurring categories that appear across nearly every major vulnerability list: injection flaws, buffer overflows, improper input validation, and insecure handling of sensitive data within the code itself. Security of APIs deserves particular attention given how much modern software architecture, echoing the microservices point from Domain 3, depends on APIs as the primary interface between components, making API authentication, input validation and rate limiting a first-order security concern rather than an afterthought. Secure coding practices, input validation, output encoding, proper error handling that doesn't leak sensitive information, and the principle of never trusting client-side validation alone, form the day-to-day discipline that prevents most of the source-code-level weaknesses from occurring in the first place. Software-defined security applies the broader software-defined infrastructure concept from Domain 4 to security specifically, expressing security policy and controls as code that can be version-controlled, tested and deployed with the same rigour as the application itself.

Where AI now sits in Domain 8

Software development security has to reckon with AI from two directions at once. The first is AI as a development tool: AI-assisted coding is now common enough that this domain expects awareness of its specific failure modes, code that looks plausible but references functions or libraries that don't exist, or insecure patterns generated with the same confidence as secure ones. Neither failure mode announces itself the way a compiler error would, which is exactly why the application security testing techniques covered earlier in this domain, SAST and DAST especially, need to sit in the CI/CD pipeline regardless of whether the code in front of them was written by a person or generated by a tool.

The second direction is AI as a target. Machine learning libraries and frameworks are now part of the software supply chain this domain already treats as a risk category, and they carry their own specific attack types worth knowing by name: model hijacking, where a deployed model is manipulated to serve an attacker's purpose, and inference attacks, where an attacker extracts sensitive information the model was never meant to expose simply by querying it cleverly enough. Both sit at the software layer rather than the data layer covered back in Domain 2, which is the distinction worth holding onto if a scenario question tries to blur the two.

Final thought for revision

Domain 8's underlying argument is a simple one, even though the terminology across its five objectives can feel dense: security applied at the end of a development process is more expensive and less effective than security built into every stage of it. Nearly every concept in this domain, from maturity models to SAST and DAST to the acquired software risk categories, is really just a different lens on that same argument. Hold onto that thread while revising the specific terminology, and the domain becomes considerably easier to reason through under exam pressure.