Most engineers think…
Domain 8 is just for developers, so as a security manager I can skip the coding details and still pass.
Wrong, and it costs points. The CISSP tests you as the person who governs developers, not replaces them. You must recognize an injection flaw, choose SAST vs DAST for a given gate, demand an SBOM from a vendor, and judge whether a CI/CD pipeline is signing its artifacts. In 2025 the biggest exam and real-world shift is supply chain: you do not write the code, but you are accountable when an unsigned dependency ships a backdoor.
Domain 8, Software Development Security, is 10% of the CISSP exam (trimmed from 11% in the April 2024 refresh), but it punches above its weight because almost every breach eventually traces back to software. This deep-dive treats it the way a real AppSec or DevSecOps engineer would: you build security into the SDLC instead of bolting it on, gate your CI/CD pipeline with the right tests, and stay accountable for code you did not write. We cover the secure SDLC and DevSecOps, OWASP and secure coding, security testing in the pipeline (SAST, DAST, SCA, IAST, fuzzing), and the 2025 frontier, software supply chain, API, and CI/CD security, where unsigned dependencies and poisoned build systems now top the threat list. An AI-angle section closes the loop on securing AI-assisted and AI-generated code.
Domain 8 at a glance
Flip each card for the one-line essence of each area before you dive in.
Shift-left bakes security gates into every SDLC phase; BSIMM benchmarks, SAMM prescribes.
Allowlist input validation + context-aware output encoding kill most OWASP/CWE injection and access-control flaws.
SAST+SCA run early in CI; DAST+fuzzing test the running app; IAST bridges both in QA.
SBOM gives visibility; signing/SLSA gives integrity; scan-and-fail gates the CI/CD pipeline.
Secure SDLC & DevSecOps
Think of building software like building a house: it is far cheaper to move a wall on the blueprint than to demolish a finished room. A Secure SDLC bakes security into every stage instead of bolting it on after launch. The ISC2 2024 outline frames this as integrating security across the whole software development lifecycle, not as a final audit.
Shift-left is the core idea: move security activities earlier, toward the left of the timeline. You threat-model during design, scan code as developers write it, and check dependencies before merge. Finding a flaw in requirements costs cents; finding it in production costs lakhs and reputation. DevSecOps operationalises shift-left by wiring automated security into the CI/CD pipeline, making security everyone's job, not just the security team's.
Each SDLC phase gets a security gate — a checkpoint that blocks promotion until criteria pass. Requirements: define abuse cases and security requirements. Design: threat modeling (STRIDE). Code: SAST and secrets scanning. Build: software composition analysis for vulnerable libraries. Test: DAST and IAST against the running app. Deploy/Operate: configuration hardening and continuous monitoring.
Maturity models measure how disciplined your program is. BSIMM is descriptive — it observes and reports what 100+ real firms actually do, giving you a benchmarking scorecard. SAMM (OWASP) is prescriptive — it tells you which practices to adopt next, across Governance, Design, Implementation, Verification and Operations, with maturity levels 1 to 3.
Remember it with one word each: BSIMM = "Benchmark" (descriptive, data-driven, observe). SAMM = "Self-assess" (prescriptive, free, tells you what to do next).
Priya at HDFC faces this
A payment microservice ships a hardcoded API key to production, caught only by a customer pen-test weeks later.
No security gate in the pipeline — there was no SAST or secrets scan blocking the merge before deploy.
Shift-left: add a pre-merge secrets scanner and SAST gate that fails the build, so flaws die at commit time, not in prod.
In a CISSP context, which maturity model is BEST described as descriptive — it observes and reports what real organizations actually do, producing a benchmarking scorecard?
Pause & Predict
In one line, what is the single most important idea in "Secure SDLC & DevSecOps"? Type your guess.
OWASP & secure coding
Think of OWASP as the "most-wanted poster" for web attacks, and secure coding as the locks you fit on every door before the thief arrives. The OWASP Top 10 (current 2021 edition) ranks the ten broadest application risk categories from real-world breach data. CISSP Domain 8 expects you to treat it as a design checklist, not trivia.
Memorise the list by impact. A01 Broken Access Control is now #1 — users reaching data or actions they should not, via URL tampering, forced browsing, or modified API requests. A02 Cryptographic Failures covers weak or missing encryption. A03 Injection (SQL, NoSQL, OS command, LDAP) happens when untrusted input reaches an interpreter as code. Then A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable/Outdated Components, A07 Identification & Authentication Failures, A08 Software & Data Integrity Failures, A09 Logging & Monitoring Failures, and A10 SSRF.
Two defences carry most of the weight. Input validation means accepting only known-good data — prefer an allowlist (whitelist) of permitted patterns over a denylist. Output encoding means escaping data for its destination context so HTML, JavaScript, or SQL never reads it as code. For SQL, parameterized queries beat string concatenation every time. The CWE Top 25 (2025) puts XSS (CWE-79) at #1 and SQL injection (CWE-89) at #2, both rooted in unvalidated input.
OWASP names risk categories; CWE names the specific weakness. The exam links them: A03 Injection maps to CWE-89. Pick "parameterized query" for SQLi and "context-aware output encoding" for XSS.
Priya at Flipkart faces this
A tester changes orderId=10231 to 10232 in the URL and sees another customer's invoice and address.
Broken Access Control (A01) — the API returns any order by ID without checking it belongs to the logged-in user. This is an IDOR pattern, CWE-639.
Enforce server-side authorization on every object request; deny by default, verify ownership, and log the access attempt. Never rely on the hidden URL alone.
A Wipro developer builds a login that runs: "SELECT * FROM users WHERE name='" + input + "'". A security review flags it. Which single fix most directly removes the OWASP A03 Injection risk here?
▶ A DevSecOps pipeline
Press Play to step through it, then Break it to see how it fails.
Security testing in the pipeline
Think of shipping code like running a busy Mumbai kitchen: you check ingredients before cooking, taste mid-prep, and inspect the final plate before it reaches the table. Security testing in the pipeline works the same way — different tools check different stages, and skipping any one leaves a gap. CISSP Domain 8 expects you to know not just what each tool does, but exactly where it belongs.
SAST (Static Application Security Testing) is white-box testing that reads source code without executing it. It runs earliest — in the IDE and the commit/build stage — catching SQL injection, XSS, and hardcoded secrets before code merges. SAST shifts left but is prone to false positives.
SCA (Software Composition Analysis) inventories your open-source and third-party libraries, then flags known CVEs and risky licences. It also runs early in the CI build, right beside SAST, because most modern apps are 70-90% borrowed code.
DAST (Dynamic Application Security Testing) is black-box testing against a running app in staging. It gives an attacker's-eye view of runtime flaws like misconfigurations and auth bypass.
IAST (Interactive Application Security Testing) places an agent inside the running app, blending SAST's code visibility with DAST's runtime view. It runs during QA/automated regression for low false positives.
Fuzzing feeds malformed, random input to confirm the app fails gracefully instead of crashing — it lives in the dynamic/DAST stage.
Remember the order: SAST + SCA = early (CI build, needs source); DAST + fuzzing = late (staging, needs a running app); IAST = middle (QA, needs an agent). "Earlier = cheaper to fix" is the shift-left principle ISC2 loves.
Sneha at HDFC faces this
Her Jenkins build passed all scans, yet a pen-tester found an authentication bypass in the live payments app at 172.16.4.20.
The pipeline ran only SAST and SCA. Both need source code and never exercise the running app, so a runtime auth flaw stayed invisible.
Add a DAST stage against staging after deploy, and IAST during regression. Combine methods — no single tool gives full coverage.
A DevSecOps lead at a Bengaluru fintech wants to catch vulnerable open-source libraries and known CVEs the moment a developer commits, before any deployment. Which control should be added to the early CI build stage?
Pause & Predict
Without scrolling up: name the biggest difference in "SAST vs DAST vs IAST". Type your guess.
Supply chain, API & CI/CD security
Think of a restaurant that lists every ingredient and its origin on the menu. If a supplier recalls one spice, the chef instantly knows which dishes to pull. Software supply chain security works the same way, and your menu is the SBOM.
Modern apps are 80-90% borrowed code. The CISSP 2024 outline (Domain 8.3) makes you responsible for that borrowed code through software composition analysis (SCA) and supply-chain controls. Three pillars matter for the exam: visibility, verification, hardening.
- Visibility (SBOM): Generate an SBOM (Syft, Trivy) on every build. It tracks direct AND transitive dependencies. When Log4Shell hit, teams with SBOMs found vulnerable Log4j in minutes; teams without spent weeks guessing.
- Verification (signing): Sign artifacts (Sigstore/Cosign) and reject unsigned ones at deploy. SLSA provenance proves the binary came from your real pipeline, not a tampered one.
- Hardening (CI/CD): NIST SP 800-204D wants scanning baked into the pipeline. Run
npm audit/pip auditand Trivy so builds fail on new CVEs.
API security is the other half. Apply OWASP API Top 10 thinking: enforce authentication and per-object authorization (stop BOLA/IDOR), rate-limit, validate every input, and never expose internal stack traces. CI/CD and repos are themselves attack surface: lock branches, require signed commits, scope tokens least-privilege, and scan for hardcoded secrets so a leaked GitHub PAT cannot rewrite your build.
SBOM = visibility (you find it). Signing/SLSA = integrity (you trust it). They are not interchangeable answers — match the verb in the stem.
Priya at HDFC faces this
A pinned npm package got a malicious patch overnight; the build pushed credential-stealing code to staging.
No artifact signing or pinned hashes, so a poisoned transitive dependency entered the pipeline unverified.
Pin by integrity hash, gate deploys on Cosign signature + SLSA provenance, and fail builds on Trivy CVEs.
During a Log4Shell-style zero-day, Aditya at TCS must identify within hours which of 200 microservices ship the vulnerable library, including indirectly. Which control most directly enables this rapid, accurate impact analysis?
Domain 8 in the AI era (2026)
Domain 8 says: bake security into every phase of the SDLC. In 2025-2026, "the software you build" increasingly is AI — LLM-powered apps, RAG pipelines, and code written by Copilot. The CISSP mindset (threat-model early, validate input, control output) maps directly onto the new AI attack surface.
The anchor reference is the OWASP Top 10 for LLM Applications (2025 edition). It is led by LLM01 Prompt Injection — because an LLM reads instructions and data in the same channel, attacker-crafted input can hijack behaviour; OWASP reports ~73% of production AI deployments carry exploitable prompt-injection flaws. LLM05 Improper Output Handling is the AI twin of classic injection: trusting model output and passing it straight into a shell, SQL query, or browser invites RCE/XSS. LLM03 Supply Chain covers poisoned models and LoRA adapters pulled from public hubs (the "PoisonGPT" class of attack).
For the ML pipeline, defenders use MLSecOps and three aligned frameworks: MITRE ATLAS (v5.1.0, Nov 2025 — now 16 tactics, including agent context-poisoning and memory manipulation), the NIST AI RMF (Govern-Map-Measure-Manage), and OWASP itself. Guard the training data against poisoning, sign and verify model artifacts, and isolate the inference layer.
AI-generated code is its own SDLC risk: research in 2026 found ~78% of AI-written code carried at least one exploitable flaw, and AI-assisted commits leaked secrets at over twice the human rate. RoguePilot and CamoLeak (CVSS 9.6) showed Copilot itself weaponised via indirect prompt injection.
Strengths tip: If you already think in input-validation and least-privilege, you will learn LLM security fast — treat the model as an untrusted user.
The AI-era angle, in four cards
What 2026 adds to this domain — flip to see why each matters.
Instructions and data share one channel, so attacker text can hijack the model. Ranked #1 two editions running — mitigate with least-privilege tools, not a single patch.
Trusting model output into a shell, SQL, or DOM = RCE/XSS. It is classic injection wearing an AI mask — so encode and parameterise the output.
Poisoned models and LoRA adapters from public hubs (PoisonGPT-style) inject a pre-compromised brain. So sign, verify, and pin every model artifact.
~78% of AI-written code had an exploitable flaw and leaked secrets 2x more. So gate every AI commit with peer review + SAST, never ship unscanned.
Pause & Predict
Name one thing AI changes about Domain 8 — and one fundamental it does NOT change. Type your guess.
🎯 Prove it — your Domain 8 practice exam
You have read the theory. Now do the reps. This is the free, timed Techclick assessment built for exactly this domain, with full reasoning on every question — plus the full-length mock for when you are close to your exam date.
Part of the 8-part series · start from the CISSP overview → · all assessments live on exam.techclick.in (sign in with your Techclick account).
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from ISC2 docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: In your own words, explain why a CISSP would tell a DevOps team to add SCA and artifact signing to their CI/CD pipeline even though their developers already write secure code and pass SAST. What real risk does that close? Then compare to the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Shift-left
- Moving security testing and review earlier in the SDLC, so defects are found in design/code rather than in production.
- DevSecOps
- Embedding automated security into the CI/CD pipeline so security is a shared, continuous responsibility, not a final gate.
- BSIMM vs SAMM
- BSIMM is descriptive (observes and benchmarks what firms actually do); OWASP SAMM is prescriptive (tells you which practices to adopt next).
- Broken Access Control (A01)
- The #1 OWASP risk: users perform actions or reach data beyond their permitted scope, often via URL or API tampering.
- Output encoding
- Escaping data for its output context (HTML, JS, SQL) so it is rendered as harmless text, not executed as code.
- Parameterized query
- An SQL statement where user input is bound as data, never concatenated as code — the standard defence against SQL injection.
- Shift-left security
- Moving testing as early in the pipeline as possible, because a bug caught at coding costs up to 100x less than one caught in production.
- False positive
- A flagged finding that is not actually a real vulnerability; SAST tools generate many, which can fatigue developers.
- CI/CD pipeline
- The automated chain of build, test, and deploy stages that moves code from a commit to production.
- SBOM
- Software Bill of Materials — a complete, machine-readable inventory of every component, version and license in your software, including transitive dependencies.
- SLSA
- Supply-chain Levels for Software Artifacts — an OpenSSF framework grading build integrity; higher levels require tamper-proof provenance from a hardened build platform.
- SCA
- Software Composition Analysis — automated scanning of third-party and open-source dependencies against CVE/NVD databases to flag known vulnerabilities.
- Prompt Injection
- An attack where crafted input is interpreted by an LLM as a new instruction rather than data; OWASP LLM01. Indirect variants hide the payload in content the model later ingests (web pages, files, repos).
- MLSecOps
- Extending DevSecOps to the machine-learning lifecycle — securing training data, model artifacts, pipelines, and inference, typically mapped to OWASP LLM Top 10, MITRE ATLAS, and NIST AI RMF.
- MITRE ATLAS
- Adversarial Threat Landscape for AI Systems — a MITRE knowledge base of real-world attack tactics/techniques against ML systems; v5.1.0 (Nov 2025) covers 16 tactics and 84 techniques.
📚 Sources
- ISC2 — CISSP Certification Exam Outline (effective April 15, 2024), Domain 8 weighted 10%. isc2.org
- ISC2 — Changes to the CISSP Exam Weighting (Domain 8: 11% to 10%). isc2.org/Insights
- OWASP — OWASP Top 10:2025, A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions. owasp.org/Top10/2025
- OWASP — Software Assurance Maturity Model (SAMM) and Application Security Verification Standard (ASVS). owasp.org
- NIST — SP 800-218, Secure Software Development Framework (SSDF) v1.1. csrc.nist.gov/pubs/sp/800/218/final
- NIST — SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models (July 2024). nvlpubs.nist.gov
- CISA / Open Source Security Foundation — SLSA (Supply-chain Levels for Software Artifacts) provenance and SBOM guidance. slsa.dev / cisa.gov
- Ministry of Electronics & IT, Government of India — Digital Personal Data Protection (DPDP) Act 2023, data-fiduciary security safeguards (s.8) relevant to software handling personal data. meity.gov.in
What's next?
Domain 8 done. You have now covered all eight domains. Sit the full mock to pull it together.