CISSP
Domain 8 · 10%
Software Development Security
Security folded into how software gets built, not bolted on after — the process controls (SDLC, change management) and the technical patterns (secure coding, common vulnerability classes) that keep applications from becoming the weakest link.
SDLC models
- Waterfall — sequential phases (requirements → design → implementation → verification → maintenance), each gated before the next starts. Predictable, rigid, security requirements defined upfront are hard to revise later.
- Agile/iterative — short cycles, continuous feedback; security has to be woven into each sprint rather than saved for a final gate.
- DevSecOps — security integrated directly into CI/CD (automated SAST/DAST/SCA in the pipeline, infrastructure as code scanned like application code) — "shift left," catching issues at commit time rather than in production.
- Maturity models — frameworks like the Software Assurance Maturity Model assess and improve an organization's secure-development practices over time, independent of which SDLC methodology is used.
Change and configuration management
Same discipline as Domain 7, applied to code: version control, code review/approval before merge, and a documented, tested rollback path. Configuration management ensures deployed systems match an approved, known-good baseline — configuration drift is itself a vulnerability, since it means production no longer matches what was tested.
Secure coding and common vulnerability classes
The OWASP Top 10 is the standard reference vocabulary for web application risk — know the categories and the root cause each represents, not a specific year's exact ranking:
- Injection (SQL, command, LDAP) — untrusted input concatenated into a command/query instead of parameterized. Fix: parameterized queries/prepared statements, input validation.
- Broken access control — the application fails to enforce what an authenticated user should actually be allowed to do (e.g. IDOR — Insecure Direct Object Reference, changing an ID in a URL to access another user's data).
- Cryptographic failures — sensitive data transmitted or stored without adequate encryption, or using broken/outdated algorithms.
- Cross-Site Scripting (XSS) — untrusted input rendered back into a page without proper output encoding, executing attacker script in a victim's browser. Reflected, stored, and DOM-based variants.
- Security misconfiguration — default credentials, unnecessary features enabled, verbose error messages leaking internals.
- Vulnerable and outdated components — using libraries/frameworks with known CVEs; this is what SCA tooling targets directly.
- SSRF (Server-Side Request Forgery) — the application is tricked into making a request to an unintended destination (often internal infrastructure) on the attacker's behalf.
General defensive principles: input validation (allow-list over deny-list), output encoding (context-appropriate — HTML vs. URL vs. JS encoding aren't interchangeable), parameterization, and least privilege for the application's own service accounts and database permissions.
Database and data-layer security
Normalization reduces redundancy and improves integrity, but can be deliberately traded off (denormalization) for performance. Aggregation (combining non-sensitive data points to infer something sensitive) and inference (deducing restricted information from accessible data) are database-specific confidentiality risks distinct from a direct access-control failure — the individual queries are each authorized, but the combination isn't supposed to be possible.
Third-party and open-source software risk
Modern applications are assembled more than written — a Software Bill of Materials (SBOM) inventories every component and its version, making it possible to answer "are we affected by this new CVE" in minutes instead of weeks. Supply-chain risk extends to build pipeline integrity (a compromised CI/CD system can inject malicious code into an otherwise-clean codebase) and vendor due diligence for any commercial dependency.