CISSP cheat sheet · Domain 8 · 10% of exam
Software Development Security
Building security into software from requirements to retirement: SDLC models, secure coding, application and API attacks, databases, third-party code and AI-assisted development.
Rule cards
| SDLC | Requirements → Design → Code → Test → Deploy → Maintain → Dispose. A secure product = security in EVERY phase. Cheapest fix = requirements/design. Threat modelling in design. |
|---|---|
| Certification & accreditation | Certification = technical evaluation of controls → Accreditation = management formally accepts the risk (authority to operate). Testing done → accreditation next. |
| Maturity | CMMI: 1 Initial (chaotic) → 2 Managed → 3 Defined → 4 Quantitatively managed → 5 Optimizing · OWASP SAMM = prescriptive · BSIMM = descriptive. |
| OWASP fixes | SQLi → parameterised queries · XSS → output encoding + CSP · CSRF → anti-CSRF tokens + SameSite · IDOR/broken access → server-side authorisation · insecure deserialisation → sign/validate objects · session hijack → new session ID, Secure/HttpOnly cookies. |
| Databases | ACID = Atomicity (all or nothing), Consistency, Isolation, Durability · aggregation / inference = the problem → polyinstantiation, views, cell suppression = fixes. |
| Supply chain | Code signing = publisher authenticity + integrity · software escrow = source code if the vendor fails · SBOM + SCA = know your components · acquired software → independent assurance + contract terms. |
| AI-assisted coding | Treat AI output as untrusted: code review, SAST/SCA, approved package registry (hallucinated package names = slopsquatting), no secrets in prompts. |
| Environments | Separate dev / test / production · developers do not deploy their own code to production · version control + peer review · change control for releases. |
Development models — hard words made simple
| Term | Simple meaning | Example / analogy | Exam hook |
|---|---|---|---|
| Waterfall | Phases one after another; no going back | Building a house floor by floor | Rigid, sequential |
| V-model | Each development phase has a matching test phase | Requirements ↔ acceptance test | “matching test phase” |
| Spiral | Repeating loops with risk analysis every loop | Prototype → risk check → improve | “risk analysis each iteration” |
| Agile | Build in small pieces, adapt to feedback | A feature every 2 weeks | Flexible, customer feedback |
| Scrum / sprint | Agile framework; a sprint is a 1–4 week time-box | “This sprint we build login” | Short iteration |
| Backlog / user story | Prioritised to-do list / feature from the user’s view | “As a user I want to reset my password” | — |
| RAD / prototyping | Quick working models for fast feedback | Mock-up app | Speed over documentation |
| DevOps / DevSecOps | Dev + Ops with automation; DevSecOps adds security to the pipeline | Security scan on every build | Security automated in CI/CD |
| CI/CD | Continuous integration / delivery: automatic build-test-deploy | Push → auto-tested → deployed | The pipeline |
| Polyinstantiation | Two versions of a record at different classification levels | Low users see a cover story | Stops inference |
| Aggregation / inference | Combining harmless data reveals secrets / deducing secrets from clues | Troop food orders reveal troop count | Problem; fix = polyinstantiation |
| TOCTOU | Time-of-check vs time-of-use race condition | File swapped between check and use | Race condition |
| Deadlock | Two processes waiting on each other forever | Two cars blocking a narrow lane | Concurrency, not DoS |