CISSP Domain 8: Software Development Security explained

Domain 8 at a glance

The subdomains in plain words

1. 8.1 Security in the development lifecycle: waterfall, agile, spiral and DevOps models, maturity models, and where security fits in each.
2. 8.2 Controls in development ecosystems: languages, libraries, repositories, CI/CD pipelines, application security testing and databases.
3. 8.3 Assessing software security: change and configuration management, testing as risk reduction, and who accepts residual risk.
4. 8.4 Acquired software: commercial, open-source, outsourced and cloud software, and the supply chain behind it.
5. 8.5 Secure coding: common weaknesses, the OWASP Top 10, API security and coding standards.

What the exam tends to test

• Earlier is cheaper. The best point to add security is during requirements and design.
• Security keeps pace with delivery. DevSecOps puts checks into the pipeline rather than at the end.
• Bought is not safe. Acquired software and cloud services still need review, testing, patching and monitoring.
• Separation of duties. Developers do not move their own code to production, and live data stays out of test environments.
• The owner accepts risk. A business owner, not the developer, signs off on residual risk.

How deep to go

You need vocabulary and judgement, not code. Know the shape of each development model, what each testing approach can and cannot find, and the common weaknesses with their primary fixes. Questions often put you in the buyer's or the manager's seat: what assurance to ask for, who approves a release, who accepts the remaining risk.

Common traps

• Relying on client-side validation. Input must be validated on the server; client-side checks are a convenience.
• Reading code signing as "safe". It proves who published the code and that it was not changed, not that it is free of flaws.
• Mixing up SAST and DAST. Static testing reads code without running it; dynamic testing exercises the running application.
• Assuming SaaS removes your duties. You still own your data, access decisions and compliance.
• Matching the wrong fix to an attack. Parameterised queries for SQL injection, output encoding for cross-site scripting, tokens for request forgery.

How to study it

1. Learn one development model well, then compare the others to it. Most questions need only the shape of each model.
2. Make a two-column list of common attacks and their primary fix.
3. Think as the manager buying software: what assurance do you ask for before purchase, and what do you watch afterwards? Escrow and SOC reports appear here as well as in Domain 6.
4. Connect change management to Domain 7; the exam treats code releases as changes.
5. From 15 April 2027 the outline names the Secure Software Development Framework, SBOM requirements and shift-left practice under 8.1, and memory-safe languages under 8.2; see what changes in 2027.

Worked example: thinking it through

Our own illustration, not an exam item.

The situation. A senior developer finds a bug in the customer portal on a Friday evening and wants to push a one-line fix straight to production. It looks harmless. What is the best response?

• Allow it, since the developer is senior and the change is small.
• Block it until the next monthly release.
• Route it through the emergency change process: a quick review and test by someone other than the author, deployment by operations, and documentation afterwards.
• Let the developer deploy it but ask for a written explanation on Monday.

The reasoning. Seniority does not remove the need for separation of duties, and small changes cause plenty of outages. Waiting a month may leave customers exposed for no good reason. A written note after the fact records the change but skips the review that might catch a mistake. The emergency change process exists for exactly this: it keeps the speed while keeping a second pair of eyes and a record. The exam treats code releases as changes, and change control as a security control.

Next steps

Check the weights on the domains overview, then try our own practice questions on the development lifecycle and secure coding.