9.6. Reflection Checkpoint

Key Takeaways

• Security defects found in requirements cost 1× to fix; in production, 100×. Shift-left is a financial argument, not just a best practice.
• Threat modeling (STRIDE) belongs in design — identify risks before code is written.
• Secure SDLC: security requirements → threat modeling → SAST + code review + SCA → DAST + IAST → config scan → monitoring.
• OWASP Top 10: Broken Access Control (#1), Cryptographic Failures (#2), Injection (#3). SQL injection is prevented by parameterized queries — not input filtering alone.
• Buffer overflow prevention: memory-safe languages, ASLR, DEP, stack canaries.
• Input validation: allowlist is stronger than denylist. Client-side validation is not a security control — server-side is required.
• Fail secure: on error, deny access. Secure defaults: applications secure out of the box.
• API security: BOLA is the #1 API risk. Enforce authorization at the object level, not just the endpoint level. Rate limiting, schema validation, and API gateways provide centralized enforcement.
• Open source is not inherently less secure than COTS — the key factor is active maintenance and vulnerability response processes, not source code visibility.
• Vendor due diligence: SOC 2 Type II > Type I. Require right-to-audit, breach notification timelines, data destruction on termination, and SBOM.
• SBOM enables rapid vulnerability response: "are we affected by Log4Shell?" answered in minutes rather than weeks.
• Software supply chain attacks (SolarWinds, dependency confusion, typosquatting, XZ Utils) compromise the build pipeline to distribute malicious code through trusted channels.
• SCA detects vulnerable third-party components. Pin dependencies. Use private artifact repositories. SLSA framework provides build integrity maturity levels.
• CI/CD pipeline security: scan at every stage (pre-commit → commit → build → test → deploy → runtime). Secure the pipeline infrastructure itself, not just what flows through it.
• Secrets in git history persist forever. Secret scanning must cover full commit history, not just current HEAD.
• Code review is a security control — requires reviewers trained in secure coding. Branch protection and signed commits prevent unauthorized code reaching production.
• Code signing verifies source and integrity — not safety.

Connecting Forward

Phases 1–9 have built a complete CISSP knowledge foundation: from first principles through all eight domains. The next phase (Exam Readiness) synthesizes this content into exam strategy, cross-domain connections, and practice questions.

Self-Check Questions

• A developer argues that their application is secure from SQL injection because it validates user input to reject single quotes and other special characters. Explain why this defense is insufficient, provide a specific bypass technique an attacker might use, and describe the correct defense that addresses the vulnerability structurally.
• An organization purchases a commercial SaaS application to process employee medical records. The vendor provides a SOC 2 Type II report. From a software development security perspective, what does the SOC 2 report tell you about the vendor's software development practices, and what additional software security due diligence should you require?