CISSP Domain 8
Software Development Security
Domain 8 accounts for approximately 10–11% of the CISSP exam and focuses on integrating security throughout the software development lifecycle (SDLC). This domain evaluates your ability to ensure that security is designed, implemented, tested, and maintained within software systems—not added as an afterthought. CISSP emphasizes secure design decisions, risk-aware development practices, third-party software risk, and effective testing strategies. The core mindset tested here is simple: most security failures are born in design and development, not in operations.
8.0 Understand and integrate security in the Software Development Life Cycle (SDLC)
In modern enterprises, security is not a final validation step; it is an architectural requirement. As a CISSP, you must internalize the “Move Left” principle—security controls must be embedded from requirements and design, not bolted on after deployment.
Exam Reality:
Early security integration reduces risk, lowers remediation cost, and prevents systemic design flaws. Fixing a vulnerability during threat modeling costs far less than remediating it in production after compromise.
SDLC vs. SLC (High-Yield Exam Distinction)
Software Development Life Cycle (SDLC):
Focuses on designing, building, testing, and deploying software.System Life Cycle (SLC):
Broader scope including business approval, operations, maintenance, and secure decommissioning and disposal.
Exam Rule: If the question involves retirement, data destruction, or license termination → think SLC, not SDLC.
Security Touchpoints – The Strategic “Why”
Risk Analysis:
Identifies feasibility and risk tolerance before development begins.Threat Modeling:
Conducted during design to identify trust boundaries, attack paths, and required controls.
Coach’s Tip: You cannot secure what you have not modeled.Regulatory Alignment:
Early identification of PCI DSS, HIPAA, GDPR, or data residency requirements enforces Secure-by-Design compliance.
8.1 Identify and apply security controls in software development ecosystems
Security requirements do not change with methodology—only the implementation timing does.
Comparison of Development Methodologies
Methodology | Description | Pros | Cons | CISSP Security Insight |
|---|---|---|---|---|
Waterfall | Linear, sequential | Predictable | Rigid, late testing | Suitable only for stable, low-change projects |
Incremental | Feature-based iterations | Early value delivery | Planning complexity | Security must be enforced per increment |
Prototyping | Early models | Clarifies requirements | Weak analysis risk | Use only for requirements validation |
Spiral | Risk-driven iterations | Strong risk reduction | Requires expertise | Exam Alert: Best for high-risk systems |
JAD / RAD | Fast collaboration | Speed & consensus | User dependency | Controls must not be skipped for speed |
Cleanroom | Mathematical correctness | High reliability | Inflexible | Ideal for safety-critical systems |
Agile, Scrum, and Enterprise Scaling
Product Owner: Owns business value and acceptance criteria
Scrum Master: Facilitates process, removes blockers
Scrum Team: Delivers secure, working increments
For enterprise scale, SAFe enables governance across multiple agile teams.
CISSP Insight: Agile does not remove security gates—it shifts them into every sprint.
8.1.0 Programming Languages, Runtimes, and OOP Principles
Language selection influences attack surface, memory safety, and control strength.
Compiled vs. Interpreted Languages
Feature | Compiled | Interpreted |
|---|---|---|
Execution | Binary | Runtime translation |
Security | Smaller runtime surface | Interpreter dependency risk |
Sandbox | Minimal | JVM provides isolation |
OOP Principles with Security Impact
Encapsulation: Protects data integrity
Inheritance: Reuses validated code
Polymorphism: Controlled flexibility
Polyinstantiation: Prevents inference at different classification levels
Security Selection Checklist
Memory Safety
Garbage Collection
Type Safety
Thread Safety
8.1.1 DevSecOps and Modern Development Ecosystems
DevSecOps embeds security into development, operations, and automation pipelines. Security becomes everyone’s responsibility, not a silo.
CI/CD Pipeline – Why CISSP Cares
Continuous Integration (CI):
Detects defects early through automated testing.Continuous Delivery/Deployment (CD):
Automates secure promotion to production.Security Impact:
Automated SAST, SCA, and configuration checks provide continuous assurance, not periodic snapshots.
Exam Rule: Security controls that block promotion are preventive; controls that only report are detective.
SCM and Repository Security
Repositories are high-value targets and must enforce:
RBAC + MFA
Secret scanning (no hardcoded keys)
Validation of third-party code
Integrated Product Team (IPT)
Cross-functional teams (Dev, QA, Security, Ops, Business) ensure security decisions are balanced, reviewed, and defensible.
8.2 Database Security and Environment Integrity
ACID Model (Transaction Integrity)
Atomicity
Consistency
Isolation
Durability
Environment Separation (Exam Critical)
Environment | Rule |
|---|---|
Development | No production data |
Test | Sanitized data only |
Staging | Production-like, no live dependencies |
Production | Hardened, restricted access |
Coach’s Rule: Production data never belongs outside production.
8.3 Assess security impact of acquired software
Security Testing Methods
Method | When | Strength |
|---|---|---|
SAST | Build | Code-level flaws |
DAST | Runtime | Attacker simulation |
IAST | Runtime | Context-aware detection |
SCA | Continuous | OSS & license risk |
Exam Tip: Use multiple testing types—no single tool is sufficient.
Maturity Models
CMMI: Process maturity
SAMM: Risk-driven assurance
BSIMM: Observational benchmarking
8.3.0 Acquisition Security and Cloud Models
COTS vs OSS
COTS: No source visibility → use code escrow
OSS: Transparency + licensing risk
Cloud Shared Responsibility
Model | Customer Secures |
|---|---|
SaaS | Data, users, configuration |
PaaS | App security + monitoring |
IaaS | OS, network, logging, backup |
8.4 Define and apply secure coding guideli nes and standards
High-Yield Vulnerabilities
Vulnerability | Root Cause | Mitigation |
|---|---|---|
SQLi | Poor validation | Parameterized queries |
XSS | Output encoding gaps | CSP + encoding |
CSRF | Cookie reliance | Anti-CSRF tokens |
Critical Code Risks
TOCTOU → Atomic operations
Buffer Overflow → Bounds checking, ASLR
Backdoors → Code review
Mobile Code → Sandboxing, signing
API Security
Best → OAuth 2.0, OIDC, JWT, mTLS
Worst → No auth or custom tokens
Final Exam Takeaways
Security must be designed, not appended
Threat modeling defines controls
CI/CD enables continuous assurance
Testing must match lifecycle phase
OSS and cloud do not transfer risk
Input validation is deny-by-default
Code signing establishes trust
Secure disposal is part of security