Software Development Security: Secure Design, Threat Modeling, and Pipeline Gates
What this domain tests
Domain 8 tests whether security is built into how software is specified, designed, built, tested, and acquired. Questions focus on design principles, threat modeling, the classes of defect that keep appearing in real applications, and controls that belong in a CI/CD pipeline rather than in a late review.
Core rules
- Secure design principles include least privilege, defense in depth, fail-safe defaults, complete mediation, economy of mechanism, open design, least common mechanism, and psychological acceptability. Separation of duties and least privilege apply to code, service accounts, and deployment pipelines.
- Threat modeling identifies assets, entry points, and trust boundaries, then enumerates threats. STRIDE classifies spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege; DREAD-style scoring is one way to rank them.
- Recurring defect classes map closely to the OWASP Top 10: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, logging and monitoring failures, and server-side request forgery.
- Validate input on the server and encode output for its destination context. Use parameterized queries for database access. Never rely on client-side validation, and never treat blocklists as sufficient sanitization.
- Secrets belong in a managed secret store, not in source code, build logs, or container images. Supply chain controls include dependency scanning, SBOMs, signed artifacts, and pinned versions from trusted sources.
- DevSecOps gates include static analysis, software composition analysis, secret scanning, and dynamic testing in the pipeline. Acquired software needs security requirements in the contract and the right to assess.
Worked example
A login form is vulnerable to SQL injection. The root cause is string concatenation of user input into a query, so the fix is parameterized queries plus a least-privilege database account that cannot read unrelated tables. Input validation reduces the attack surface, and a WAF rule is useful as a compensating control while remediation is deployed, but it is not the fix. A regression test is added, and pipeline gates for static analysis and composition scanning help prevent the same class from returning. The reasoning separates root-cause remediation from mitigation and detection.
Traps that cost marks
- Accepting client-side validation as a security control.
- Sanitizing with a blocklist instead of parameterizing queries or encoding output.
- Committing secrets to a repository and assuming deletion from history removes exposure; rotate the secret.
- Assuming a static analysis pass proves the absence of defects.
- Buying software without security requirements, patching obligations, or assessment rights in the contract.