CSSLP

CSSLP Exam Details

Domain Weight Breakdown

Who Should Take This Exam

• Software developers and architects who need to embed security throughout the software development lifecycle
• Application security engineers who perform secure code reviews, threat modeling, and security testing
• DevSecOps engineers who integrate security tooling and practices into CI/CD pipelines
• QA engineers and testers who validate security requirements and perform security-focused testing
• Software project managers who need to understand secure SDLC practices and manage security requirements

Tip: CSSLP covers the entire software lifecycle from requirements through deployment and supply chain. Unlike application-specific certifications, it is technology-agnostic and focuses on secure software development principles that apply to any language, platform, or methodology.

Core Security Concepts

Secure Design Principles

• Least Privilege: Grant only the minimum permissions needed to perform a function. Every process, user, and module should operate with the fewest privileges necessary
• Separation of Duties: Critical operations require multiple parties to complete. Prevents single-point-of-compromise scenarios in both code and operations
• Defense in Depth: Layer multiple security controls so that failure of one does not compromise the system. Combine network, application, data, and physical controls
• Fail Secure (Fail Safe): When a system fails, it should default to a secure state. Deny access by default rather than granting it when errors occur
• Economy of Mechanism: Keep security mechanisms as simple as possible. Complex code is harder to audit and more likely to contain vulnerabilities
• Complete Mediation: Every access to every resource must be verified against the access control mechanism. No bypass paths should exist
• Open Design: Security should not depend on the secrecy of the implementation (Kerckhoffs' principle). The algorithm can be public; the key must be secret
• Psychological Acceptability: Security mechanisms should not make the resource significantly harder to use. If security is too burdensome, users will circumvent it

Secure SDLC Models

Tip: Know the difference between prescriptive models (Microsoft SDL tells you what to do) and descriptive models (BSIMM describes what organizations actually do). OWASP SAMM is both prescriptive and measurable, making it ideal for maturity assessment.

Security Requirements Types

Security requirements define the security capabilities that software must have to protect against threats and comply with regulations. They should be gathered alongside functional requirements and traced throughout the development lifecycle. Incomplete or missing security requirements are a leading cause of software vulnerabilities because developers cannot implement controls they are not aware of.

Threat Modeling

Tip: STRIDE is the most commonly tested threat modeling methodology on the CSSLP exam. Memorize each category and its corresponding mitigation: Spoofing → Authentication, Tampering → Integrity, Repudiation → Audit Logging, Info Disclosure → Encryption, DoS → Availability, EoP → Authorization.

Secure Architecture Patterns

• Defense in Depth: Multiple layers of security controls (network, host, application, data) so that compromise of one layer does not expose the entire system
• Zero Trust Architecture: Never trust, always verify. Every request is authenticated and authorized regardless of network location. Microsegmentation and continuous verification
• Sandboxing: Isolate untrusted code in a restricted environment to limit the impact of exploitation. Used for plugins, user-uploaded content, and third-party code
• Microservices Security: Each service has its own security boundary, authentication, and authorization. API gateways handle cross-cutting security concerns
• Secure API Design: Authentication (API keys, OAuth tokens), rate limiting, input validation, output encoding, versioning, and TLS enforcement for all API endpoints

Data Protection in Architecture

OWASP Top 10 Vulnerabilities

Secure Coding Practices

• Input Validation: Validate all input on the server side using allowlists (not denylists). Check data type, length, range, and format. Reject invalid input rather than attempting to sanitize it
• Output Encoding: Encode all output based on the context (HTML encoding, URL encoding, JavaScript encoding, CSS encoding) to prevent XSS and injection attacks
• Parameterized Queries: Use prepared statements with parameterized queries for all database interactions. Never concatenate user input into SQL strings
• Error Handling: Implement centralized error handling that logs detailed errors internally but shows generic messages to users. Never expose stack traces, database details, or internal paths
• Session Management: Use cryptographically random session IDs, enforce timeouts, regenerate IDs after authentication, protect with Secure and HttpOnly flags
• Memory Management: Prevent buffer overflows by using safe functions, bounds checking, and memory-safe languages where possible. Clear sensitive data from memory after use

Tip: The most effective defense against injection attacks is parameterized queries (prepared statements). Input validation is important but should be a secondary defense. The CSSLP exam favors defense-in-depth approaches that combine multiple controls.

Cryptography in Software

Security Testing Methods

Security in CI/CD Pipelines

• Pre-Commit: IDE security plugins, secret scanning (detect API keys, passwords in code), pre-commit hooks for security linting
• Build Phase: SAST scanning integrated into build process, SCA for dependency vulnerabilities, container image scanning, SBOM generation
• Test Phase: DAST scanning against deployed test environment, IAST during automated functional tests, security-focused unit and integration tests
• Release Phase: Final security gate review, sign artifacts with digital signatures, verify compliance with security policies before deployment approval
• Deploy Phase: Infrastructure as Code (IaC) security scanning, runtime application self-protection (RASP), configuration validation
• Monitor Phase: Runtime monitoring, WAF, SIEM integration, anomaly detection, vulnerability disclosure program

Tip: The CSSLP exam tests the concept of “shifting security left” — integrating security testing as early as possible in the SDLC. Finding a vulnerability in code review costs 10x less than finding it in production. SAST in the IDE is the earliest possible point.

Secure Deployment Practices

Secure Operations and Maintenance

• Patch Management: Establish patching SLAs based on severity (critical: 24-48 hours, high: 7 days, medium: 30 days). Test patches before production deployment
• Vulnerability Management: Regular scanning, risk-based prioritization, tracking to remediation, and verification of fixes
• Incident Response: Documented procedures for security incidents affecting the application. Include containment, evidence collection, and communication plans
• End of Life (EOL): Secure decommissioning procedures including data sanitization, certificate revocation, DNS cleanup, and user notification

Software Supply Chain Security

Software supply chain security has become a critical domain following high-profile attacks like SolarWinds, Log4Shell, and Codecov. The CSSLP exam tests your understanding of risks inherent in using third-party components, open-source libraries, and development tools, as well as the controls needed to secure the entire software supply chain from development to delivery.

SAST vs DAST vs IAST vs SCA

Exam Day Strategy

• Lifecycle mindset: Every question relates to a phase of the secure SDLC. Identify which phase is being discussed to narrow your answer choices
• Defense in depth: When multiple controls are listed, prefer the answer that combines preventive and detective controls rather than relying on a single mechanism
• Prevention over detection: Input validation prevents injection. WAFs detect and block. Parameterized queries eliminate the vulnerability entirely. The CSSLP prefers elimination over mitigation
• Know STRIDE thoroughly: Be able to map any threat to its STRIDE category and recommend the corresponding countermeasure
• OWASP Top 10 mastery: Know each vulnerability, its root cause, and the primary mitigation. This knowledge applies across multiple domains
• Supply chain is growing: This domain is gaining importance. Know SBOM, SCA, code signing, and the concept of software provenance

Tip: The CSSLP exam is challenging because it covers both security concepts and software development practices. Unlike the CISSP which is management-focused, the CSSLP expects technical depth in areas like cryptography, secure coding, and testing methodologies. Focus on understanding WHY each control works, not just what it does.