Domain 8 is not “write secure code.” It is put security in the lifecycle, then pick the test that can see the flaw, then prove what you shipped. Requirements and a threat model come first. Human code review reads intent and business logic. SAST reads source without running it. DAST attacks a running build. SCA inventories libraries. An SBOM tells you where a CVE lives; signing / SLSA provenance tells you the binary came from your pipeline. OWASP Top 10:2025 names the failure classes — Broken Access Control is still first; Software Supply Chain Failures is now A03. A WAF is not a parameterized query. Input validation is not authorization.
I do not bolt a scanner on Friday. I put a control in the phase that can still change the design. Review sees logic. SAST sees source. DAST sees runtime. SCA sees the bill of materials. I do not ship what I cannot name and sign.
1. Why Domain 8 matters
ISC2 weights Software Development Security at 10% of the CISSP CAT (exam outline effective 15 April 2024; this domain dropped from 11%). The official verbs are five: integrate security in the SDLC, apply controls in the development ecosystem, assess whether those controls work, assess acquired software, and apply secure coding guidelines. The exam — and a real change-advisory board — punish the same mistake: treating security as a test phase.
That is the ticket in this lesson. A payment API ships because “SAST was green.” The flaw is an IDOR. SAST never executed the request. DAST was skipped “to make the window.” There is no SBOM when the next library CVE lands. The scanner did not fail. The program did.
Manager lens
When is security allowed to stop a release, who owns residual risk on a known vuln, and what evidence (SBOM, sign-off, exception) exists after go-live.
Engineer lens
Which tool can actually see this class of flaw, where it sits in CI/CD, and what a green gate is allowed to prove — and what it is not.
8.1 SDLC methods (Agile, Waterfall, DevOps, DevSecOps, SAFe), maturity models (CMM, SAMM), operations, change management, Integrated Product Team. 8.2 Languages, libraries, tools, IDE, runtime, CI/CD, configuration management, repositories, SAST / DAST / SCA / IAST. 8.3 Audit of changes, risk analysis. 8.4 COTS, open source, third-party, managed and cloud services. 8.5 Source-level weaknesses, API security, secure coding, software-defined security. Source: ISC2 CISSP Certification Exam Outline.
Shift-left — move a control to the earliest phase that can still change the design, not “run every tool on commit.”
Code review — a human (or pair) reads source for intent, authorization, and business logic. White-box. Does not prove runtime.
SAST — static analysis of source or bytecode without executing the app.
DAST — dynamic testing of a running application, usually as a black box.
IAST — instrumentation inside a running app; sees both code paths and live requests.
SCA — software composition analysis: inventory of third-party components and known CVEs / licences.
SBOM — a list of what is in a build, including transitive dependencies. Visibility, not integrity.
Provenance / SLSA — evidence of how and where the artifact was built. Signing is how you verify it.
2. Mental model — SDLC, methods, maturity
Hold three parts. Interviews fail when people treat “secure SDLC” as a slogan, treat SAMM as CMM, or treat DevOps speed as a reason to skip a gate.
Part 1 · security has a job in every phase
An SDLC is just the order in which you turn an idea into running software and then retire it. Domain 8’s claim is narrower: each phase has a security deliverable, or defects become 10–100× more expensive to fix. NIST’s Secure Software Development Framework (SP 800-218) groups the work into four outcomes, not a vendor pipeline: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV).
Read left → right, then the two ops boxes. The FIRST answer on a new feature is almost always Requirements or Design, not a late DAST ticket.
Part 2 · the method changes when the gate fires, not whether it exists
Outline 8.1 names five methods. Waterfall is sequential — security that waits for a UAT phase is late by construction. Agile puts work in sprints — security belongs in the definition of done, not in a hardening sprint after demo. DevOps is CI/CD speed. DevSecOps is the same pipeline with security as an automated gate and a shared responsibility, not a throw-over-the-wall team. SAFe scales Agile across trains — security has to live at team, program, and portfolio, or one ART ships around the control.
An Integrated Product Team (IPT) is the outline’s name for the cross-functional group — developer, tester, security, operations, business — that owns the product. Security as a visitor at sprint 11 is not an IPT.
| Method | Where security usually dies | Manager move |
|---|---|---|
| Waterfall | Security testing after code-complete | Security requirements and design review are exit criteria for those phases. |
| Agile | “We’ll harden next sprint” | Abuse cases and review in the definition of done. No story is done if the gate is red. |
| DevOps | Pipeline has no fail-closed security job | Fund the gates. Speed without a stop is just faster defect delivery. |
| DevSecOps | Gates exist but are warning-only | Severity policy: critical CVE / secret / unsigned artifact blocks merge or deploy. |
| SAFe | One team opts out of the ART standard | Portfolio non-functional requirement. Local waivers expire and are signed. |
Part 3 · maturity models are not interchangeable
Outline 8.1 names CMM and SAMM. CMM / CMMI measures whether your process is repeatable (Level 1 chaotic through Level 5 optimizing). It is not a security catalogue. OWASP SAMM is prescriptive: it tells you which security practices to grow, by business function, at a maturity you choose. Well-known CBK also contrasts BSIMM, which is descriptive — it observes what real firms do and scores you as a benchmark. SAMM says “do this next.” BSIMM says “here is what peers actually do.” Do not mix the verbs on the exam.
Calling CMMI Level 3 “secure software.” Process maturity without secure-coding standards, review, and pipeline gates is a well-run factory that still ships injection. SAMM (or an equivalent AppSec program) is the security overlay. CMM is the factory floor.
Waterfall, Agile, and DevOps change the calendar. They do not delete the job. SAMM prescribes security practices. CMM grades process discipline. BSIMM benchmarks what others already do.
3. Decision flow — review vs DAST vs SCA
Draw this before you buy a scanner or write a standard. First decide what field you must see. Source? A running request? A library name? Human intent? Then pick the control that can see that field. Then place it in the earliest pipeline stage that still has that field.
Read the diamond first. Code review is the answer when the flaw is intent (IDOR design, double-spend, missing authz). DAST is the answer when the flaw only appears while the app runs. SCA never reads your if-statement.
Code review is white-box and early. A reviewer can see that accountId from the client is trusted, that a coupon can apply twice, that a TODO disables authz, that an AI assistant pasted a hardcoded token. Review cannot prove a misconfigured TLS cipher on the staging host.
DAST is black-box and later. It sends real requests to a running build and sees auth bypass, XSS that only appears after a template renders, default creds, and directory listings. DAST cannot read the source, so it is weak on hidden business logic and on code paths the crawler never hit.
If the stem says “logic,” “intent,” “design,” or “peer,” pick review. If it says “running,” “staging,” “misconfiguration,” or “as an outsider,” pick DAST. Layer them. Do not retune the one you already have.
4. How to choose tests and OWASP controls
Outline 8.2 names the test family explicitly: SAST, DAST, SCA, IAST. Outline 8.5 names the coding problem: source-level weaknesses, API security, secure coding practices, software-defined security. Use the first table to pick a test. Use the second to pick the control that actually closes the OWASP class.
| You need to know… | Pick | When it runs | It will miss |
|---|---|---|---|
| Does this function authorize the owner? Can a coupon fire twice? | Code review (peer, pair, IPT) | Before merge. Cheapest. | Runtime config, environment drift, paths nobody read. |
| Is there a sink that concatenates SQL? A secret in source? | SAST | Commit / PR. No running app. | Authz that is logically wrong but syntactically fine. Live misconfig. |
| Which libraries, including transitive, have a CVE or a bad licence? | SCA + emit SBOM | Build / merge. Needs lockfiles. | Your own business logic. Zero-days not yet in the feed. |
| What happens if an outsider hits the running app? | DAST | Deployed QA / staging. | Dead code, unauthenticated-only crawl gaps, design intent. |
| Which line of code handled this live request? | IAST | Instrumented test / QA. | Anything the test suite never exercised. Agents add cost. |
| What if we smash unexpected inputs for hours? | Fuzzing (well-known CBK; sits with DAST-family) | After a build exists. | Authorization policy. Needs a harness. |
OWASP Top 10:2025 is the current awareness list. Two 2025 moves matter on this exam: A03 Software Supply Chain Failures is now its own category, and A10 Mishandling of Exceptional Conditions is new. Injection dropped to A05 — it did not become safe.
| OWASP Top 10:2025 | What it looks like in a ticket | Control that actually closes it |
|---|---|---|
| A01 Broken Access Control | Change accountId / role and see another tenant (IDOR). | Server-side authorization on every object. Deny by default. Review the check — scanners often miss a missing if. |
| A02 Security Misconfiguration | Default creds, directory listing, debug left on, cloud bucket public. | Hardened baseline + DAST / config scan of the running stack. SAST cannot see the host. |
| A03 Software Supply Chain Failures | Dependency confusion, poisoned package, unsigned build, missing SBOM. | Pinned hashes, private registry first, SCA, SBOM, signed provenance, verify before deploy. |
| A04 Cryptographic Failures | Home-grown crypto, TLS 1.0, secrets in source. | Standard libraries, current TLS, secret scan + vault. Not “we hash passwords” as a slogan. |
| A05 Injection | "SELECT * FROM users WHERE name='" + input + "'" | Parameterized queries / prepared statements. Allowlist where you must interpolate. A WAF is a seatbelt, not the fix. |
| A06 Insecure Design | No threat model. Feature cannot be made safe later. | Threat model and abuse cases in Design. You cannot SAST your way out of a missing control. |
| A07 Authentication Failures | Credential stuffing, session fixation, missing MFA on the admin API. | Proven auth library, MFA, session hygiene. Test it with DAST + review of the session code. |
| A08 Software or Data Integrity Failures | Auto-update without signature, insecure CI, deserialized untrusted blob. | Sign artifacts, lock the pipeline, verify on install. Integrity is not “we have backups.” |
| A09 Logging and Alerting Failures | Login failures not logged; alert never fires. | Log authz denials and admin actions; alert on them. Logging is not a compliance checkbox. |
| A10 Mishandling of Exceptional Conditions | Catch-all returns a stack trace; fail-open on auth error. | Fail closed. Generic errors to the user. Review exception paths — DAST may only see the 500. |
UNSAFE db.query("SELECT * FROM users WHERE name='" + user + "'")
SAFE db.query("SELECT * FROM users WHERE name = ?", [user])
The unsafe line mixes code and data. The safe line binds input as a value. Encoding output in the right context (HTML, URL, JS) is the sibling control for XSS. Neither is “a longer denylist of words.”
An IDOR request is often well-formed: an integer, a UUID, a JSON body that passes the schema. A01 is “does this subject own that object?” That check lives on the server after authentication. Tightening the regex does not close it. This is why code review of the authorization path beats another DAST crawl that never guesses the other tenant’s id — and why a DAST that does guess it still cannot tell you why the check is missing.
APIs and software-defined security (8.5)
API security on this domain is the same judgment with a smaller surface: authenticate the caller, authorize the object, validate the schema, rate-limit, and do not leak stack traces. Software-defined security is security expressed as code — policy-as-code, infrastructure-as-code scans, pipeline gates that fail closed. If the control only exists as a wiki page, it is not software-defined.
AI-assisted coding — official Domain 8 note
ISC2 now interweaves AI across the eight domains. For Domain 8 the official point is narrow: AI coding assistants can emit insecure snippets and “hallucinated” dependencies. Treat the model as an untrusted author. The control set does not change: peer review, SAST, secret scanning, SCA for packages the model invented. Banning the tool is not the BEST answer; shipping its output ungated is not due care. NIST SP 800-218A is the SSDF community profile for generative-AI development — same four groups, extra tasks for models and training data.
5. Runbook — design, gate, acquire
This is not a vendor console path. It is the Domain 8 operating path you walk on a new service, a new library, or a Copilot-heavy team. Each side cites one primary source.
Side A · design the requirement (shift-left)
Primary source: NIST SP 800-218, SSDF v1.1 — Prepare (PO) and Produce (PW), plus outline 8.1.
-
Write security requirements with the story
Who may call this API? What is the object owner? What must fail closed? If the story has no abuse case, it is not ready for design. This is the FIRST move on a new feature stem.
-
Threat-model the design before code
STRIDE or a lighter data-flow sketch is enough. Insecure Design (A06) is the class you close here. A scanner will not invent a missing control.
-
Stand up an Integrated Product Team
Developer, reviewer, security, QA, operations, product. Security as a visitor after demo is not 8.1.
-
Lock change management
Production deltas — including “tiny” hotfixes and pipeline YAML — go through the same review and logging (8.1, 8.3). Emergency changes get a retroactive ticket the same day, not a shrug.
Side B · gate the ecosystem
Primary source: ISC2 outline 8.2 and OWASP SAMM (Verification + Implementation practices).
-
Harden the place code is written
IDE plugins catch secrets early. Repositories enforce signed commits or at least protected branches and required reviews. Language and library choices are an 8.2 control — memory-unsafe C for a parse-heavy internet service is a risk decision, not a taste.
-
On every pull request: review + SAST + secret scan
A human reads authorization and business logic. SAST reads sinks and sources. Neither replaces the other. AI-authored diffs get the same review, not a lighter one.
-
On every build: SCA, SBOM, fail closed on policy
Pin versions and hashes. Prefer the internal registry so a public package of the same name cannot win (dependency confusion). Emit an SBOM per artifact. Critical CVEs block merge. Warnings that never fail are decoration.
-
On a running build: DAST / IAST, then sign
Staging must look like production enough for DAST to be meaningful. Sign the artifact (Cosign / Sigstore or your enterprise equivalent) and keep the provenance with the SBOM. Configuration management (8.2) means the pipeline definition is reviewed like code.
Side C · acquire software and prove the release
Primary source: outline 8.4 and SLSA / CISA SBOM.
-
Assess before you import
COTS, open source, third-party, managed services, and cloud (SaaS / PaaS / IaaS) are all 8.4. Ask for an SBOM, a vulnerability-handling SLA, where data lives, and who can push updates. A free library is still acquired software.
-
Trust the pipeline, not the file share
Only artifacts built by the official CI, with verified signatures and matching SBOMs, may reach production. A jar copied from a laptop is an A03 / A08 finding even if SCA was clean last month.
-
Log the change and name residual risk
8.3 is auditing of changes plus risk analysis. A known CVE you chose to ship needs an owner, a date, and a compensating control. Silence is not acceptance.
The story had an abuse case. A reviewer saw the authz path. SAST and SCA ran and could fail the build. A running-environment test covered the live surface. The artifact has an SBOM and a signature you verified. Residual risk has a name and a date. Change is in the log.
6. Runtime path after go-live
Release is not the end of 8.1. Operation, maintenance, and change management are on the outline. A CVE published on Thursday is an RV (Respond to Vulnerabilities) event: find the component, patch or mitigate, then fix the root cause so the next service does not repeat it.
Read left → right. The magenta box is why you kept the SBOM. Without inventory, Log4Shell-style response is archaeology.
Domain 6 (assessment) still owns pen-tests, SOC reports, and coverage metrics. Domain 8 owns whether the product team can find and fix the same classes before an external tester does. If testers keep finding runtime auth-bypass after a clean SAST gate, the missing control is DAST/IAST — not a fiercer static ruleset.
7. Traps and proof
| Stem pattern | What ISC2 is testing | Engineer trap | Manager move |
|---|---|---|---|
| What do you do FIRST on a new feature / API? | 8.1 sequencing. Design before tools. | Stand up DAST or buy a WAF. | Security requirements and a threat model. Then the gates. |
| SAST is green; testers still find auth bypass. | 8.2 — what each test can see. | Tune SAST harder. Disable the findings. | Add DAST/IAST against a running build. SAST cannot execute the request. |
Well-formed accountId reads another tenant. |
8.5 A01 vs input validation. | Tighten the regex / WAF. | Server-side authorization. Review the check. |
| Coupon applies twice; SAST and DAST are quiet. | Code review vs scanners. | More crawls. Ban the feature. | Human review of the business-logic path (misuse case). |
| Which of 200 services ship library X? | 8.4 / A03 visibility. | SSH to boxes. Hope the WAF holds. | Query the SBOM. If you have none, that is the finding. |
| Catch CVEs before merge. | Shift-left placement. | Annual pen-test. DAST in prod. | SCA on the build, fail closed. |
| Only official CI binaries in prod. | Integrity / provenance. | Scan more often. | Sign artifacts; verify SLSA / provenance on deploy. |
| CMM Level 3, so we are secure. | 8.1 maturity-model verbs. | Treat CMM as SAMM. | CMM is process. SAMM (prescriptive) is the security overlay. BSIMM only benchmarks. |
| Copilot / LLM wrote the patch. | AI as untrusted author. | Ban the tool, or trust it because “AI is trained on good code.” | Same gates: review, SAST, secret scan, SCA for hallucinated packages. |
- I can name a security deliverable for requirements, design, code, build, test, release, and operate.
- I can pick review vs SAST vs DAST vs SCA from one sentence of a stem.
- I can say why IDOR is authorization, not validation.
- I can say why parameterized queries beat a WAF for A05.
- I can tell SBOM (inventory) from a signature (integrity).
- I can tell SAMM (prescribe) from BSIMM (describe) from CMM (process).
- I did not quote a made-up “this subtopic is X% of the exam.” Domain 8’s official weight is 10% of the whole exam — that is the only percentage this page uses.
Weak: “Domain 8 is OWASP and SAST.” Strong: “I put the control in the phase that can still change the design. Review sees logic. SAST sees source. DAST sees runtime. SCA plus an SBOM is how I survive the next library CVE. I will not ship an unsigned artifact from a laptop. If an assistant wrote the code, it still goes through the same gates.”
Knowledge check
Six judgment items. Map each one to a FIRST/BEST stem, not a definition. Check answers, then reset and retry the misses.
Sources
- ISC2 — CISSP Certification Exam Outline (effective 15 April 2024). Domain 8 weight 10%. Objectives 8.1–8.5 are the spine of this lesson. AI-in-Domain-8 note taken from the same outline page. No other exam percentages are claimed.
- OWASP — Top 10:2025 (A01–A10, including A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions).
- OWASP — Software Assurance Maturity Model (SAMM) (prescriptive maturity). Contrast: CMM/CMMI as process maturity (named in 8.1); BSIMM as well-known descriptive benchmark, not an ISC2-named requirement.
- OWASP — Query Parameterization Cheat Sheet (A05 control).
- NIST — SP 800-218, Secure Software Development Framework (SSDF) v1.1 (PO / PS / PW / RV).
- NIST — SP 800-218A, SSDF community profile for generative AI and dual-use foundation models.
- CISA — Software Bill of Materials (SBOM).
- OpenSSF / community — SLSA (Supply-chain Levels for Software Artifacts) provenance.
Related: CISSP overview (all 8 domains) · Domain 7: Security Operations · Domain 6: Assessment and Testing · Domain 8 assessment · 8-week roadmap