Top of Page
Effective Date: September 15, 2021

CSSLP Certification Exam Outline

View and download the latest PDF version of the CSSLP Certification Exam Outline (Effective September 15, 2021):


The Certified Secure Software Lifecycle Professional (CSSLP) validates that software professionals have the expertise to incorporate security practices – authentication, authorization and auditing – into each phase of the software development lifecycle (SDLC), from software design and implementation to testing and deployment.

The broad spectrum of topics included in the CSSLP Common Body of Knowledge (CBK®) ensure its relevancy across all disciplines in the field of information security. Successful candidates are competent in the following eight domains:

  • Secure Software Concepts
  • Secure Software Requirements
  • Secure Software Architecture and Design
  • Secure Software Implementation
  • Secure Software Testing
  • Secure Software Lifecycle Management
  • Secure Software Deployment, Operations, Maintenance
  • Secure Software Supply Chain

Experience Requirements

A candidate is required to have a minimum of four years of cumulative paid Software Development Lifecycle (SDLC) professional work experience in one or more of the eight domains of the (ISC)² CSSLP CBK, or three years of cumulative paid SDLC professional work experience in one or more of the eight domains of the CSSLP CBK with a four-year degree leading to a Baccalaureate, or regional equivalent in Computer Science, Information Technology (IT) or related fields.

If you don’t have the required experience to become a CSSLP, you may become an Associate of (ISC)² by successfully passing the CSSLP examination. You will then have five years to earn the four years required experience. You can learn more about CSSLP experience requirements and how to account for part-time work and internships at


CSSLP meets the stringent requirements of ANSI/ISO/IEC Standard 17024.

Job Task Analysis (JTA)

(ISC)² has an obligation to its membership to maintain the relevancy of the CSSLP. Conducted at regular intervals, the Job Task Analysis (JTA) is a methodical and critical process of determining the tasks that are performed by CSSLP credential holders. The results of the JTA are used to update the examination. This process ensures that candidates are tested on the topic areas relevant to the roles and responsibilities of today’s practicing information security professionals.

CSSLP Examination Information

Length of exam3 hours
Number of items125
Item formatMultiple choice
Passing grade700 out of 1000 points
Language availabilityEnglish
Testing centerPearson VUE Testing Center

CSSLP Examination Weights

DomainsAverage Weight
1. Secure Software Concepts10%
2. Secure Software Requirements14%
3. Secure Software Architecture and Design14%
4. Secure Software Implementation14%
5. Secure Software Testing14%
6. Secure Software Lifecycle Management11%
7. Secure Software Development, Operations, Maintenance12%
8. Secure Software Supply Chain11%


  • Domain 1: Secure Software Concepts Domain 1: Secure Software Concepts
    Secure Software Concepts

    Domain 1:
    Secure Software Concepts


    Core Concepts

    • Confidentiality (e.g., covert, overt, encryption)
    • Integrity (e.g., hashing, digital signatures, code signing, reliability, modifications, authenticity)
    • Availability (e.g., redundancy, replication, clustering, scalability, resiliency)
    • Authentication (e.g., Multi-Factor Authentication (MFA), Identity and Access Management (IAM), Single Sign-On (SSO), federated identity)
    • Authorization (e.g., access controls, permissions, entitlements)
    • Accountability (e.g., auditing, logging)
    • Nonrepudiation (e.g., digital signatures, block chain)


    Security Design Principles

    • Least privilege (e.g., access control, need-to-know, run-time privileges)
    • Separation of Duties (SoD) (e.g., multi-party control, secret sharing and split knowledge)
    • Defense in depth (e.g., layered controls, input validation, security zones)
    • Resiliency (e.g., fail safe, fail secure, no Single Point of Failure (SPOF))
    • Economy of mechanism (e.g., Single Sign-On (SSO), password vaults, resource efficiency)
    • Complete mediation (e.g., cookie management, session management, caching of credentials)
    • Open design (e.g., Kerckhoffs's principle)
    • Collaborative design (e.g., peer review, open source, crowd source)
    • Least common mechanism (e.g., compartmentalization/isolation, white-listing)
    • Psychological acceptability (e.g., password complexity, screen layouts, Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA), biometrics)
    • Component reuse (e.g., common controls, libraries)
    • Diversity of defense (e.g., geographical diversity, technical diversity, distributed systems)
  • Domain 2: Secure Software Requirements Domain 2: Secure Software Requirements
    Security Operations and Administration

    Domain 2:
    Secure Software Requirements


    Define Software Security Requirements

    • Functional (e.g., business requirements, use cases, stories)
    • Non-functional (e.g., operational, deployment, systemic qualities)


    Identify and Analyze Compliance Requirements


    Identify and Analyze Data Classification Requirements

    • Data ownership (e.g., data owner, data custodian)
    • Labeling (e.g., sensitivity, impact)
    • Types of data (e.g., structured, unstructured data)
    • Data life-cycle (e.g., generation, retention, disposal)


    Identify and Analyze Privacy Requirements

    • Data anonymization
    • User consent
    • Disposition (e.g., right to be forgotten)
    • Data retention
    • Cross borders (e.g., data residency, jurisdiction, multi-national data processing boundaries)


    Develop Misuse and Abuse Cases


    Develop Security Requirement Traceability Matrix (STRM)


    Ensure Security Requirements Flow Down to Suppliers/Providers

  • Domain 3: Secure Software Architecture and Design Domain 3: Secure Software Architecture and Design
    Secure Software Architecture and Design

    Domain 3:
    Secure Software Architecture and Design


    Perform Threat Modeling

    • Understand common threats (e.g., Advanced Persistent Threat (APT), insider threat, common malware, third-party/supplier)
    • Attack surface evaluation
    • Threat intelligence (e.g., Identify credible relevant threats)


    Define the Security Architecture

    • Security control identification and prioritization
    • Distributed computing (e.g., client server, Peer-to-Peer (P2P), message queuing)
    • Service-Oriented Architecture (SOA) (e.g., Enterprise Service Bus (ESB), web services)
    • Rich internet applications (e.g., client-side exploits or threats, remote code execution, constant connectivity)
    • Pervasive/Ubiquitous computing (e.g., Internet of Things (IoT), wireless, location-based, Radio-Frequency Identification (RFID), Near-Field Communication (NFC), sensor networks)
    • Embedded software (e.g., secure update, Field-Programmable Gate Array (FPGA) security features, microcontroller security)
    • Cloud architectures (e.g., Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS))
    • Mobile applications (e.g., implicit data collection privacy)
    • Hardware platform concerns (e.g., side-channel mitigation, speculative execution mitigation, embedded Hardware Security Modules (HSM))
    • Cognitive computing (e.g., Machine Learning (ML), Artificial Intelligence (AI))
    • Control systems (e.g., industrial, medical, facility-related, automotive)


    Performing Secure Interface Design

    • Security management interfaces, Out-of-Band (OOB) management, log interfaces
    • Upstream/downstream dependencies (e.g., key and data sharing between apps)
    • Protocol design choices (e.g., Application Programming Interface (API)s, weaknesses, state, models)


    Performing Architectural Risk Assessment


    Model (Non-Functional) Security Properties and Constraints


    Model and Classify Data


    Evaluate and Select Reusable Secure Design

    • Credential management (e.g., X.509 and Single Sign-On (SSO))
    • Flow control (e.g., proxies, firewalls, protocols, queuing)
    • Data Loss Prevention (DLP)
    • Virtualization (e.g., software defined infrastructure, hypervisor, containers)
    • Trusted computing (e.g., Trusted Platform Module (TPM), Trusted Computing Base (TCB))
    • Database security (e.g., encryption, triggers, views, privilege management)
    • Programming language environment (e.g., Common Language Runtime (CLR), Java Virtual Machine (JVM))
    • Operating System (OS) controls and services
    • Secure backup and restoration planning
    • Secure data retention, retrieval, and destruction


    Perform Security Architecture and Design Review


    Define Secure Operational Architecture (e.g., deployment topology, operational interfaces)


    Use Secure Architecture and Design Principles, Patterns, and Tools

  • Domain 4: Secure Software Implementation Domain 4: Secure Software Implementation
    Secure Software Implementation

    Domain 4:
    Secure Software Implementation


    Adhere to Relevant Secure Coding Practices (e.g., standards, guidelines and regulations)

    • Declarative versus imperative (programmatic) security
    • Concurrency (e.g., thread safety, database concurrency controls)
    • Output sanitization (e.g., encoding, obfuscation)
    • Error and exception handling
    • Input validation
    • Secure logging & auditing
    • Session management
    • Trusted/Untrusted Application Programming Interface (API)s, and libraries
    • Type safety
    • Resource management (e.g., compute, storage, network, memory management)
    • Secure configuration management (e.g., parameter, default options, credentials)
    • Tokenization
    • Isolation (e.g., sandboxing, virtualization, containers, Separation Kernel Protection Profiles (SKPP))
    • Cryptography (e.g., payload, field level, transport, storage, agility, encryption, algorithm selection)
    • Access control (e.g., trust zones, function permissions, Role Based Access Control (RBAC))
    • Processor microarchitecture security extensions (e.g., Software Guard Extensions (SGX), Advanced Micro Devices (AMD) Secure Memory Encryption(SME)/Secure Encrypted Virtualization(SEV), ARM TrustZone)


    Analyze Code for Security Risks

    • Secure code reuse
    • Vulnerability databases/lists (e.g., Open Web Application Security Project (OWASP) Top 10, Common Weakness Enumeration (CWE))
    • Static Application Security Testing (SAST) (e.g., automated code coverage, linting)
    • Dynamic Application Security Testing (DAST)
    • Manual code review (e.g., individual, peer)
    • Look for malicious code (e.g., backdoors, logic bombs, high entropy)
    • Interactive Application Security Testing (IAST)


    Implement Security Controls (e.g., watchdogs, File Integrity Monitoring (FIM), anti- malware)


    Address Security Risks (e.g. remediation, mitigation, transfer, accept)


    Securely Reuse Third-Party Code or Libraries (e.g., Software Composition Analysis (SCA))


    Securely Integrate Components

    • Systems-of-systems integration (e.g., trust contracts, security testing and analysis)


    Apply Security During the Build Process

    • Anti-tampering techniques (e.g., code signing, obfuscation)
    • Compiler switches
    • Address compiler warnings
  • Domain 5: Secure Software Testing Domain 5: Secure Software Testing
    Secure Software Testing

    Domain 5:
    Secure Software Testing


    Develop Security Test Cases

    • Attack surface validation
    • Penetration tests
    • Fuzzing (e.g., generated, mutated)
    • Scanning (e.g., vulnerability, content, privacy)
    • Simulation (e.g., simulating production environment and production data, synthetic workloads)
    • Failure (e.g., fault injection, stress testing, break testing)
    • Cryptographic validation (e.g., Pseudo-Random Number Generator (PRNG), entropy)
    • Regression tests
    • Integration tests
    • Continuous (e.g., synthetic transactions)
    • Unit testing and code coverage
    • Misuse and abuse test cases


    Develop Security Testing Strategy and Plan

    • Functional security testing (e.g., logic)
    • Nonfunctional security testing (e.g., reliability, performance, scalability)
    • Testing techniques (e.g., white box and black box)
    • Environment (e.g., interoperability, test harness)
    • Standards (e.g., International Organization for Standardization (ISO), Open Source Security Testing Methodology Manual (OSSTMM), Software Engineering Institute (SEI))
    • Crowd sourcing (e.g., bug bounty)


    Verify and Validate Documentation (e.g., installation and setup instructions, error messages, user guides, release notes)


    Identify Undocumented Functionality


    Analyze Security Implications of Test Results (e.g., impact on product management, prioritization, break build criteria)


    Classify and Track Security Errors

    • Bug tracking (e.g., defects, errors and vulnerabilities)
    • Risk Scoring (e.g., Common Vulnerability Scoring System (CVSS))


    Secure Test Data

    • Generate test data (e.g., referential integrity, statistical quality, production representative)
    • Reuse of production data (e.g., obfuscation, sanitization, anonymization, tokenization, data aggregation mitigation)


    Perform Verification and Validation Testing

  • Domain 6: Secure Software Lifecycle Management Domain 6: Secure Software Lifecycle Management
    Network and Communication Security

    Domain 6:
    Secure Software Lifecycle Management


    Secure Configuration and Version Control (e.g., hardware, software, documentation, interfaces, patching)


    Define Strategy and Roadmap


    Manage Security Within a Software Development Methodology

    • Security in adaptive methodologies (e.g., Agile methodologies)
    • Security in predictive methodologies (e.g., Waterfall)


    Identify Security Standards and Frameworks


    Define and Develop Security Documentation


    Develop Security Metrics (e.g., defects per line of code, criticality level, average remediation time, complexity)


    Decommission Software

    • End-of-life policies (e.g., credential removal, configuration removal, license cancellation, archiving)
    • Data disposition (e.g., retention, destruction, dependencies)


    Report Security Status (e.g., reports, dashboards, feedback loops)


    Incorporate Integrated Risk Management (IRM)

    • Regulations and compliance
    • Legal (e.g., intellectual property, breach notification)
    • Standards and guidelines (e.g., International Organization for Standardization (ISO), Payment Card Industry (PCI), National Institute of Standards and Technology (NIST), OWASP, Software Assurance Forum for Excellence in Code (SAFECode), Software Assurance Maturity Model (SAMM), Building Security In Maturity Model (BSIMM))
    • Risk management (e.g., mitigate, accept, transfer, avoid)
    • Terminology (e.g., threats, vulnerability, residual risk, controls, probability, impact)
    • Technical risk vs business risk


    Promote Security Culture in Software Development

    • Security champions
    • Security education and guidance


    Implement Continuous Improvement (e.g., retrospective, lessons learned)

  • Domain 7: Secure Software Deployment, Operations, Maintenance Domain 7: Secure Software Deployment, Operations, Maintenance
    Secure Software Deployment, Operations, Maintenance

    Domain 7:
    Secure Software Deployment, Operations, Maintenance


    Perform Operational Risk Analysis

    • Deployment environment
    • Personnel training (e.g., administrators vs users)
    • Safety criticality
    • System integration


    Release Software Securely

    • Secure Continuous Integration and Continuous Delivery (CI/CD) pipeline
    • Secure software tool chain
    • Build artifact verification (e.g., code signing, checksums, hashes)


    Securely Store and Manage Security Data

    • Credentials
    • Secrets
    • Keys/certificates
    • Configurations


    Ensure Secure Installation

    • Bootstrapping (e.g., key generation, access, management)
    • Least privilege
    • Environment hardening
    • Secure activation (e.g., credentials, white listing, device configuration, network configuration, licensing)
    • Security policy implementation
    • Secrets injection (e.g., certificate, Open Authorization (OAUTH) tokens, Secure Shell (SSH) keys)


    Perform Post-Deployment Security Testing


    Obtain Security Approval to Operate (e.g., risk acceptance, sign-off at appropriate level)


    Perform Information Security Continuous Monitoring (ISCM)

    • Collect and analyze security observable data (e.g., logs, events, telemetry and trace data)
    • Threat intel
    • Intrusion detection/response
    • Secure configuration
    • Regulation changes


    Support Incident Response

    • Root cause analysis
    • Incident triage
    • Forensics


    Perform Patch Management (e.g. secure release, testing)


    Perform Vulnerability Management (e.g., scanning, tracking, triaging)


    Runtime Protection (e.g., Runtime Application Self-Protection (RASP), Web Application Firewall (WAF), Address Space Layout Randomization (ASLR))


    Support Continuity of Operations

    • Backup, archiving, retention
    • Disaster Recovery (DR)
    • Resiliency (e.g., operational redundancy, erasure code, survivability)


    Integrate Service Level Objectives (SLO) and Service Level Agreements (SLA) (e.g., maintenance, performance, availability, qualified personnel)

  • Domain 8: Secure Software Supply Chain Domain 8: Secure Software Supply Chain
    Secure Software Supply Chain

    Domain 8:
    Secure Software Supply Chain


    Implement Software Supply

    • Identify
    • Assess
    • Respond
    • Monitor


    Analyze Security of Third-Party Software


    Verify Pedigree and Provenance

    • Secure transfer (e.g., interdiction mitigation)
    • System sharing/interconnections
    • Code repository security
    • Build environment security
    • Cryptographically-hashed, digitally signed components
    • Right to audit


    Ensure Supplier Security Requirements in the Acquisition Process

    • Audit of security policy compliance (e.g., secure software development practices)
    • Vulnerability/incident notification, response, coordination and reporting
    • Maintenance and support structure (e.g., community versus commercial, licensing)
    • Security track record


    Support contractual requirements (e.g., Intellectual Property (IP) ownership, code escrow, liability, warranty, End-User License Agreement (EULA), Service Level Agreements (SLA))

Additional Examination Information

Supplementary References

Candidates are encouraged to supplement their education and experience by reviewing relevant resources that pertain to the CBK and identifying areas of study that may need additional attention.

View the full list of supplementary references at

Examination Policies and Procedures

(ISC)² recommends that CSSLP candidates review exam policies and procedures prior to registering for the examination. Read the comprehensive breakdown of this important information at