CISSP Mastery

CISSP Mastery · Module 8 / 8

Domain 8: Software Development Security

Building security into the code: from requirement analysis to secure deployment (DevSecOps).

Your progress

Domain 8 of 8 100%

Module 8

10%

Exam weight

SDLC

Secure lifecycle

8 / 8

Domain focus

CI/CD

Shift left

Open preview · Domain overview

Why Domain 8 decides whether controls survive compilation

Policies and architectures fail silently when code ignores them. Domain 8 is where confidentiality, integrity, and availability become syntax, libraries, pipelines, and runbooks — the exam rewards lifecycle thinking from requirements to production telemetry.

Domain 8 is where intent becomes implementation: threat-informed requirements, defensive APIs, and automated gates in CI/CD. It pairs with Domain 3 (secure architecture), Domain 5 (identity in apps), and Domain 7 (detecting bad releases in production).

Security is a property of the SDLC

Waterfall gates vs Agile iterations — either way, abuse cases and security requirements must be traceable to tests and releases.
Controls beat slogans

Input validation, safe error handling, and disciplined session semantics beat checkbox compliance when attackers fuzz your edge.
Know the failure modes

Injection, broken access control, and cryptographic misuse show up as OWASP-flavored scenarios — pattern-match to root causes, not buzzwords.
Automate evidence in CI/CD

SAST, DAST, and dependency scanning are gates that scale; human review stays for design flaws automation cannot see.

Module 1 · SDLC models

Waterfall, Agile, and Secure SDLC

Delivery methodology changes cadence, not accountability. A Secure SDLC embeds threat modeling, secure coding standards, and measurable test gates so security survives velocity — whether you ship quarterly or every commit.

Waterfall & gated phases

Requirements → design → implementation → verification → maintenance. Security reviews at phase boundaries catch architectural flaws early but can bottleneck if risk acceptance is vague.
Agile & iterative delivery

Sprints demand lightweight threat modeling, Definition of Done that includes security tasks, and backlog hygiene so vulnerabilities are not endlessly reprioritized away.
Secure SDLC (SSDLC)

Trace security requirements to tests, use secure defaults in frameworks, manage secrets outside source control, and feed production incidents back into design — the loop is the control.
Exam lens: lifecycle placement

CISSP asks where an activity belongs: abuse-case workshops belong early; pen-test validation belongs late; dependency scanning belongs in build — mis-ordered answers are common traps.

Module 2 · Application security controls

Input validation, error handling, and session management

These controls are the daily workhorses of application security: they reduce injection and broken-authentication classes of flaws without requiring exotic cryptography — but only when implemented at the right trust boundary.

Input validation & trust boundaries

Validate on the server, canonicalize encodings, enforce type/range/format, and treat all client input as hostile — allow-lists beat deny-lists for exam-ready answers.
Error handling & information leakage

Generic errors to users, rich logs to defenders. Stack traces, enumeration signals, and timing side-channels are all “integrity of intent” failures.
Session management hygiene

Cryptographically random session IDs, secure + HttpOnly cookies, rotation on privilege elevation, idle and absolute timeouts, and server-side invalidation on logout.

Module 3 · Software vulnerabilities

Common flaws and secure coding discipline

The exam rewards recognizing failure modes and picking controls that remove entire classes of bugs — not memorizing CVE numbers. Map scenarios to root causes (trust, state, data flow), then to prevention and detection.

OWASP Top 10 concepts (exam framing)

Expect story-based questions: access control on object IDs, SSRF from server-side fetches, deserialization gadgets, and misconfigurations in cloud-native defaults — think mechanism, not acronym recall.
Secure coding standards

Language-specific guides (e.g., CERT, OWASP ASVS levels) translate policy into concrete rules: parameterized queries, constant-time comparisons where needed, and safe API usage.
Supply chain & dependencies

Third-party libraries inherit risk: version pinning, SBOM visibility, signed commits, and registry hygiene are now part of “software development security,” not a side quest.

Module 4 · DevSecOps

Automating security tests in CI/CD

DevSecOps shifts security left without pretending humans can review every line at speed. Policy-as-code, ephemeral test environments, artifact signing, and quality gates turn “hope we scanned it” into an auditable pipeline. The diagram below shows where security gates concentrate risk reduction before release.

Hover the Test · Security Gates stage to emphasize SAST, DAST, and IAST touchpoints — the exam loves contrasting what each technique can and cannot see.

DevSecOps pipeline

Plan

Threat model · reqs
Code

Branches · review
Build

Compile · image
Test

SAST DAST IAST
Release

Deploy · sign
Monitor

RUM · IR hooks

Pipeline

Hover, tap, or Tab each stage for pipeline focus and an exam cue.

Security gates cluster in Test: static checks see the recipe; dynamic checks exercise running behavior; IAST blends runtime context. Hover that stage to emphasize the gate.

SAST in the build

Static analysis on source/bytecode — fast feedback on dangerous APIs and injection sinks; tuned rules reduce noise; cannot fully reason about runtime configuration.
DAST against running targets

Dynamic testing of deployed behavior — great for authZ mistakes and HTTP-level issues; needs a representative environment and may miss deep business-logic flaws.
IAST & runtime instrumentation

Agents combine execution context with data flow — fewer false positives than naive DAST for some classes; requires careful performance and privacy boundaries.
Gates, waivers, and metrics

Fail the build on criticals, time-bound risk acceptance with owners, and trend metrics (MTTR for vulns, escape rate) keep security from becoming a checkbox sprint.

CISSP Exam Pro-Tip

SAST vs DAST — what each actually sees

SAST (Static Application Security Testing) inspects code or binaries without executing the app. It excels at unsafe API usage, injection sinks, and hard-coded secrets early in the pipeline, but struggles with runtime-only misconfigurations and business-logic flaws.

DAST (Dynamic Application Security Testing) exercises a running system over the wire — strong for deployment mistakes, session handling, and HTTP-visible behavior, weaker when the defect is invisible without deep internal state.

Exam trick: if the stem stresses source/build-time feedback, lean SAST; if it stresses black-box behavior against staging/production, lean DAST. Neither replaces threat modeling — they narrow different aperture windows.

Exam cue

One line to remember

SAST reads the recipe; DAST tastes the soup. CISSP wants the when and what blind spot, not the vendor name.

Quick check

Domain 8 quiz

One question at a time — instant feedback. Pair it with the diagrams and Pro-Tip callouts above.

Quiz progress

Question 1 of 5 · 20%

Q 1

Question 1 of 5

1.For a new public API, the best first secure-design activity is:

Blueprint complete — ready for the capstone?

You have worked through all eight ISC² domains — including Secure SDLC, application controls, and the DevSecOps pipeline. Every module stays free to revisit. When you are ready, take the Final Mock Exam for randomized questions, domain diagnostics, and a readiness score — the first five questions are free.

Back to Domain 7 · Security Operations Final Mock Exam