CSSLP Certified Secure Software Lifecycle Professional Exam Topics and Questions

This domain establishes the foundational vocabulary and principles that the rest of the exam assumes you already hold. Twelve percent means roughly one item in eight, but the concepts here underpin every other topic. A weak grasp of the difference between authentication and authorization, or when integrity controls matter more than confidentiality controls, will cost you marks across the paper.

– Core security properties

Confidentiality, integrity and availability form the classic triad, but the outline pushes further into authentication, authorization, accountability and nonrepudiation. You need to distinguish them cleanly under pressure. Encryption protects confidentiality; hashing and digital signatures protect integrity. Redundancy, replication and clustering address availability, while scalability and resiliency ensure the system adapts to load and recovers from fault. Authentication spans MFA, IAM, SSO, federated identity and biometrics. Authorization means access controls, permissions and entitlements. Accountability lives in auditing and logging. Nonrepudiation relies on digital signatures and blockchain to prove an action occurred and cannot be denied. The exam tests whether you can match the control to the property it protects, especially when a scenario offers multiple plausible answers.

– Governance, risk and compliance

GRC standards appear early in the outline because they shape every downstream decision. Regulatory authority, legal obligation and industry-specific frameworks constrain what you can build and how you must document it. The exam expects you to recognize when compliance drives a design choice and when it merely influences one. Candidates who treat GRC as a checkbox exercise rather than a design input lose marks when a question turns on the priority of a legal requirement over a technical preference.

– Security design principles

Least privilege, segregation of duties, defense in depth, resiliency, economy of mechanism, complete mediation, open design, least common mechanism, psychological acceptability and component reuse form the canon of secure design. Each principle has a name, a definition and a set of implementation patterns. Least privilege includes access control, need-to-know, run-time privileges and Zero Trust. Segregation of duties involves multi-party control, secret sharing and split knowledge. Defense in depth layers controls, geography and technology. Resiliency means fail safe, fail secure, no single point of failure and failover. Economy of mechanism favors SSO, password vaults and resource efficiency. Complete mediation governs cookie management, session management and caching of credentials. Open design embraces Kerckhoffs's principle, peer review, open source and crowd source. Least common mechanism enforces compartmentalization, isolation and allow lists. Psychological acceptability balances password complexity, passwordless authentication, screen layouts and CAPTCHA. Component reuse encourages common controls and libraries. The exam tests whether you can identify which principle applies to a given scenario and why another principle does not.

How Secure Software Concepts is tested

Twelve percent translates to between eight and ten items on a typical sitting, but the concepts reappear in every other domain. Items present a scenario and ask which property is at stake, which control addresses it, or which principle justifies a design decision. The trap is selecting a control that sounds plausible but protects the wrong property. A candidate who confuses hashing with encryption, or who thinks logging provides nonrepudiation, will pick the wrong option. Another common error is choosing a principle by name recognition rather than by fit. Defense in depth is not the answer to every question about layered anything, and least privilege does not apply every time access control is mentioned. The exam rewards candidates who read the scenario, identify the specific property or principle under threat, and match it to the control or pattern that directly addresses it. Vague familiarity with the terminology is not enough. You must know what each term means in practice and when it does not apply.

Where the first domain defined terms, this one addresses the organizational machinery that keeps security visible and funded throughout a project. Eleven percent of the exam turns on whether you understand how security fits into Agile or waterfall, how to measure it, and how to decommission an application without leaving credentials or data behind. The cost comes from candidates who think lifecycle management means writing a policy document and forgetting it.

– Methodology, standards and strategy

Managing security within Agile or waterfall means adapting checkpoints, control gates and break/build criteria to the cadence of the methodology. Identifying and adopting security standards involves implementing frameworks and promoting awareness across teams. Strategy and roadmap work requires defining milestones, checkpoints and the criteria that stop a build from progressing. Documentation, metrics and reporting mechanisms follow. Security documentation must exist, stay current and remain accessible. Metrics include criticality level, average remediation time, complexity, KPIs and objectives and key results. Reporting mechanisms range from dashboards to feedback loops, and the exam expects you to know why each matters and when each is appropriate.

– Integrated risk management and secure operations

Integrated risk management pulls in regulations, standards and guidelines from ISO, PCI, NIST, OWASP, SAFECode, SAMM and BSIMM. Legal concerns include intellectual property and breach notification. Risk management covers risk assessment and risk analysis, and the exam distinguishes technical risk from business risk. Secure operation practices include change management, incident response, verification and validation, and the assessment and authorization process. Candidates lose marks when they treat risk as a one-time exercise rather than a continuous thread, or when they cannot distinguish a technical risk that threatens the system from a business risk that threatens the organization.

– Decommissioning

End of life policies govern credential removal, configuration removal, license cancellation, archiving and SLA termination. Data disposition addresses retention, destruction and dependencies. The exam tests whether you remember that decommissioning is a planned activity with security implications. Leaving credentials in place, failing to remove configuration, or deleting data without checking dependencies all create risk. Candidates who assume decommissioning is someone else's problem, or who think it means turning off a server, will miss these items.

How Secure Software Lifecycle Management is tested

Eleven percent means roughly seven to nine items. They ask how you embed security into a methodology, which metric measures a given outcome, what happens when you decommission an application, or how risk management integrates with development. The trap is choosing the answer that describes what should happen in an ideal world rather than what the outline says must happen in this lifecycle. Another error is confusing a security milestone with a project milestone, or treating a control gate as a formality rather than a decision point. The exam rewards candidates who know that lifecycle management is about timing and accountability, not just documentation. You must know when a checkpoint occurs, what it checks, and who decides whether the project proceeds. Items often present a scenario in which something went wrong and ask what lifecycle control would have prevented it. Picking the most expensive or most comprehensive control is a trap. The correct answer is the control that fits the lifecycle stage and the risk.

Requirements work is where security becomes specific. Thirteen percent of the exam focuses on defining, classifying and tracing security requirements, and on understanding the difference between functional and non-functional demands. The domain also covers compliance, data classification, privacy, access provisioning and third-party vendor requirements. Candidates who skip requirements or treat them as aspirational lose marks here and in every downstream domain, because a missing requirement cannot be tested or deployed.

– Defining and classifying requirements

Software security requirements split into functional and non-functional. Functional requirements include business requirements, use cases and stories. Non-functional requirements cover security, operational, continuity and deployment concerns. Compliance requirements come from regulatory authority, legal obligation, industry-specific frameworks such as defense, healthcare, commercial, financial and PCI, and company-wide standards for development tools, standards, frameworks and protocols. Data classification requirements address data ownership, data labeling by sensitivity and impact, data types such as structured and unstructured, data lifecycle from generation through disposal, and data handling for PII and publicly available information. The exam tests whether you can identify which category a requirement belongs to and why that category matters for downstream design or testing.

– Privacy and access provisioning

Privacy requirements define data collection scope, data anonymization ranging from pseudo-anonymous to fully anonymous, user rights such as data disposal and the right to be forgotten, marketing preferences, sharing and using third parties, terms of service, data retention covering how long, where and what, and cross-border requirements including data residency, jurisdiction and multi-national processing boundaries. Access provisioning covers user provisioning, service accounts and reapproval processes. Candidates who conflate privacy with security, or who think anonymization is a single technique, will choose the wrong control when the exam asks how to meet a privacy requirement.

– Misuse, traceability and third parties

Developing misuse and abuse cases means identifying how an attacker or a careless user might exploit the system, then specifying mitigating controls. The security requirement traceability matrix links each requirement to its implementation and its test. Third-party vendor security requirements ensure that suppliers meet the same standards you impose on your own code. The exam expects you to know that a requirement without traceability is unverifiable, and that third-party code inherits risk unless you specify and enforce security requirements.

How Secure Software Requirements is tested

Thirteen percent translates to between nine and eleven items. They present a scenario and ask which requirement applies, how to classify data, what privacy obligation governs a cross-border transfer, or how to trace a requirement through design and testing. The trap is selecting an answer that addresses a related concern but not the one the question specified. Another common error is choosing a functional requirement when the scenario calls for a non-functional one, or vice versa. Privacy questions are particularly prone to this: candidates pick the answer that sounds most protective without checking whether it matches the legal or user preference constraint in the scenario. The exam rewards candidates who read the scenario, identify the requirement type, and select the control or process that fulfills it. Traceability questions ask what happens when a requirement changes or when a test fails. The correct answer is the one that preserves the link between requirement, implementation and verification. Guessing based on what seems most rigorous will fail when the question specifies a constraint such as cost, time or regulatory minimum.

Architecture and design carry the highest weight in the exam at fifteen percent. This domain asks you to define security architecture across a wide range of platforms, perform secure interface design, evaluate reusable technologies, model threats, assess architectural risk, and define operational architecture. The breadth is punishing. A candidate who knows cloud architecture but not embedded systems, or who understands threat modeling but not trusted computing, will lose marks.

– Defining security architecture

Security architecture begins with patterns such as SABSA, security chain of responsibility and federated identity. Security controls must be identified and prioritized. Distributed computing includes client-server, peer-to-peer, message queuing and N-tier. Service-oriented architecture covers enterprise service bus, web services and microservices. Rich internet applications bring client-side exploits, remote code execution and constant connectivity. Pervasive and ubiquitous computing includes IoT, wireless, location-based services, RFID, NFC, sensor networks and mesh. Embedded software addresses secure boot, secure memory and secure update. Cloud architectures span SaaS, PaaS and IaaS. Mobile applications introduce implicit data collection privacy concerns. Hardware platform concerns include side-channel mitigation, speculative execution mitigation, secure element, firmware and drivers. Cognitive computing covers AI, virtual reality and augmented reality. Industrial IoT includes facility-related systems, automotive, robotics, medical devices and software-defined production processes. The exam expects you to recognize the security implications of each platform and to know which controls apply.

– Interface design and reusable technologies

Secure interface design addresses security management interfaces, out-of-band management, log interfaces, upstream and downstream dependencies such as key and data sharing between applications, and protocol design choices including API weaknesses, state and models. Evaluating and selecting reusable technologies means understanding credential management using X.509 and SSO, flow control through proxies, firewalls, protocols and queuing, data loss prevention, virtualization including IaC, hypervisor and containers, trusted computing with TPM and TCB, database security covering encryption, triggers, views, privilege management and secure connections, programming language environments such as common language runtime, Java VM, Python and PowerShell, operating system controls and services, secure backup and restoration planning, and secure data retention, retrieval and destruction. Candidates who pick a technology because it is familiar rather than because it fits the architecture will choose the wrong answer when the exam specifies a constraint such as platform, performance or trust boundary.

– Threat modeling and risk assessment

Threat modeling methodologies include STRIDE, PASTA, Hybrid Threat Modeling Method and CVSS. Common threats cover APT, insider threat, common malware and third-party suppliers. Attack surface evaluation identifies where the system is exposed. Threat analysis examines how an attacker might exploit that surface. Threat intelligence identifies credible relevant threats and predicts future ones. Architectural risk assessment and design reviews follow. Modeling non-functional security properties and constraints ensures that performance, scalability and other operational concerns do not undermine security. Defining secure operational architecture addresses deployment topology, operational interfaces and CI/CD. The exam tests whether you can apply a threat modeling methodology to a scenario, identify the most credible threat, and select the architectural control that mitigates it.

How Secure Software Architecture and Design is tested

Fifteen percent means between ten and thirteen items, the largest share of any domain. Items present an architecture or a platform and ask which control applies, what threat is most significant, or how a design decision affects security. The trap is choosing a control that works in general but not on the specified platform. Another error is selecting a threat modeling methodology by name recognition rather than by fit to the scenario. The exam rewards candidates who can map a platform to its specific risks. Cloud architecture questions turn on shared responsibility. Embedded systems questions turn on resource constraints. Mobile questions turn on implicit data collection. IoT questions turn on physical access and update mechanisms. Cognitive computing questions turn on data provenance and model integrity. Candidates who answer based on web application security defaults will miss items that specify a different platform. Threat modeling questions ask which methodology applies or what the highest-priority threat is. The correct answer depends on the system's exposure, the attacker's capability, and the consequence of compromise.

Implementation is where design meets code, and fourteen percent of the exam tests whether you know how to write secure code, analyze it for risk, implement controls, integrate components and secure the build process. The domain assumes you understand the difference between declarative and imperative security, and that you can identify when a coding practice prevents a vulnerability and when it merely obscures one.

– Secure coding practices

Adhering to secure coding standards, guidelines and regulations begins with understanding declarative versus imperative security. Concurrency covers thread safety and database concurrency controls. Input validation and sanitization prevent injection attacks. Error and exception handling must not leak information. Output sanitization includes encoding and obfuscation. Secure logging and auditing protect confidentiality and privacy. Session management prevents hijacking. Trusted and untrusted APIs and libraries must be distinguished. Resource management addresses compute, storage, network and memory. Secure configuration management includes baseline security configuration and credentials management. Tokenization replaces sensitive data with non-sensitive equivalents. Isolation uses sandboxing, virtualization, containerization and Separation Kernel Protection Profiles. Cryptography spans payload, field level, transport, storage, agility, encryption and algorithm selection. Access control includes trust zones, function permissions, RBAC, DAC and MAC. Processor microarchitecture security extensions mitigate side-channel and speculative execution attacks. The exam expects you to know which practice prevents which vulnerability, and to recognize when a practice is misapplied.

– Code analysis and risk identification

Analyzing code for security risks starts with secure code reuse. Vulnerability databases and lists such as OWASP Top 10, CWE and SANS Top 25 provide a reference for known weaknesses. SAST includes automated code coverage and linting. Manual code review involves peer review. Inspecting for malicious code looks for backdoors, logic bombs and high entropy. The exam tests whether you can identify which analysis technique finds which class of vulnerability, and whether you understand the limits of each technique. SAST finds certain pattern-based flaws but not logic errors. Manual review finds logic errors but scales poorly. Malicious code inspection requires knowledge of what normal code looks like.

– Controls, integration and build security

Implementing security controls includes watchdogs, file integrity monitoring and anti-malware. Addressing identified security risks requires choosing a risk strategy: mitigate, accept, transfer or avoid. Evaluating and integrating components involves systems-of-systems integration with trust contracts, security testing and analysis, and reusing third-party code or open-source libraries securely through software composition analysis. Applying security during the build process includes anti-tampering techniques such as code signing and obfuscation, compiler switches, and addressing compiler warnings. The exam expects you to know that integration is a trust boundary and that the build process itself is an attack surface.

How Secure Software Implementation is tested

Fourteen percent translates to between nine and twelve items. They present a code scenario, a coding practice, or a build process and ask which vulnerability is present, which control prevents it, or what the risk is. The trap is choosing the answer that prevents a different vulnerability. Another error is selecting a control that sounds strong but does not fit the scenario. The exam rewards candidates who can map a coding practice to the vulnerability it prevents. Input validation prevents injection. Output sanitization prevents cross-site scripting. Error handling prevents information disclosure. Session management prevents hijacking. Cryptography prevents eavesdropping and tampering. Access control prevents unauthorized access. Candidates who confuse these mappings will pick the wrong answer. Code analysis questions ask which technique finds a given flaw or which flaw a technique misses. The correct answer depends on the flaw's nature: pattern-based, logic-based, or malicious. Integration questions ask where the trust boundary is and what happens when it is violated. Build security questions ask how an attacker might compromise the build and what control prevents it.

Testing carries fourteen percent of the exam and addresses how you prove that the security controls you designed and implemented actually work. The domain covers test strategy, test case development, documentation verification, undocumented functionality, test result analysis, error tracking and test data security. Candidates who think testing means running a scanner and reading the report will lose marks when the exam asks about test environment design, test data provenance, or how to classify a finding.

– Strategy, standards and test case development

Developing a security testing strategy and plan starts with standards from ISO, Open Source Security Testing Methodology Manual and the Software Engineering Institute. Functional security testing addresses logic. Nonfunctional security testing addresses reliability, performance and scalability. Testing techniques include known environment testing, unknown environment testing, functional testing and acceptance testing. The testing environment must support interoperability and test harness. Security researcher outreach includes bug bounties. Developing security test cases covers attack surface validation, automated vulnerability testing with DAST and IAST, penetration tests of security controls, known vulnerabilities and known malware, fuzzing with generated or mutated inputs, simulation of production environment and production data with synthetic transactions, failure testing through fault injection, stress testing and break testing, cryptographic validation of pseudorandom number generators and entropy, unit testing and code coverage, regression tests, integration tests, continuous testing, and misuse and abuse test cases.

– Documentation, undocumented functionality and analysis

Verifying and validating documentation includes installation and setup instructions, error messages, user guides and release notes. Identifying undocumented functionality means finding features, interfaces or behaviors that were not specified and that might represent risk. Analyzing security implications of test results affects product management, prioritization and break/build criteria. The exam expects you to know that documentation is part of the attack surface, that undocumented functionality is a red flag, and that test results drive decisions, not just reports.

– Error tracking and test data security

Classifying and tracking security errors involves bug tracking for defects, errors and vulnerabilities, and risk scoring using CVSS. Securing test data requires generating test data with referential integrity, statistical quality and production representativeness, and reusing production data with obfuscation, sanitization, anonymization, tokenization and data aggregation mitigation. Performing verification and validation testing includes independent or internal verification and validation, and acceptance testing. The exam tests whether you understand that test data is sensitive, that production data in test environments creates privacy and compliance risk, and that error classification drives remediation priority.

How Secure Software Testing is tested

Fourteen percent means between nine and twelve items. They ask which test technique finds a given flaw, how to secure test data, what a test result means for the project, or how to classify an error. The trap is choosing a test technique that sounds thorough but does not find the specified flaw. Another error is assuming that any production data can be used in testing, or that obfuscation alone satisfies privacy requirements. The exam rewards candidates who know which test technique finds which flaw. DAST finds runtime vulnerabilities. SAST finds code-level flaws. IAST combines both. Penetration tests validate controls. Fuzzing finds input-handling errors. Fault injection finds resilience failures. Cryptographic validation finds weak randomness. Regression tests find whether a fix broke something else. Integration tests find trust boundary violations. Test data questions ask how to generate realistic data or how to reuse production data safely. The correct answer depends on the sensitivity of the data, the regulatory environment, and the technical capability of the obfuscation method. Error tracking questions ask how to classify a finding or what its CVSS score means for priority.

Deployment, operations and maintenance account for eleven percent of the exam and cover the period from release through ongoing operation, patching, incident response and continuity. The domain assumes that security does not end when the software ships, and that operational risk, configuration management, continuous monitoring, incident response, vulnerability management, runtime protection and continuity planning are all examinable. Candidates who focus only on development and testing will lose marks here.

– Operational risk, configuration and release

Performing operational risk analysis addresses deployment environment including staging, production and QA, personnel training for administrators versus users, legal compliance covering adherence to guidelines, regulations, privacy laws and copyright, and system integration. Secure configuration and version control covers hardware, baseline configuration, version control and patching, and documentation practices. Releasing software securely involves a secure CI/CD pipeline in a DevSecOps model, an application security toolchain, and build artifact verification using code signing and hashes. Storing and managing security data includes credentials, secrets, keys, certificates and configurations. Ensuring secure installation addresses secure boot with key generation, access and management, least privilege, environment hardening through configuration hardening, secure patches and updates, and firewall, secure provisioning of credentials, configuration, licensing and IaC, and security policy implementation. Obtaining security approval to operate requires risk acceptance and sign-off at the appropriate level.

– Monitoring, incident response and patch management

Performing information security continuous monitoring involves observable data such as logs, events, telemetry, trace data and metrics, threat intelligence, intrusion detection and response, regulation and privacy changes, and integration analysis with SIEM. Executing the incident response plan covers incident triage, forensics, remediation and root cause analysis. Performing patch management includes secure release and testing. Performing vulnerability management covers tracking, triaging and CVE. Incorporating runtime protection includes RASP, WAF, ASLR and dynamic execution prevention. The exam expects you to know that monitoring is continuous, that incident response is planned, and that patch management is a security activity, not just an operational one.

– Continuity and service levels

Supporting continuity of operations includes backup, archiving, retention, disaster recovery plan, resiliency through operational redundancy, erasure code, survivability and denial-of-service mitigation, and business continuity plan. Integrating service level objectives and SLA covers maintenance, performance, availability and qualified personnel. The exam tests whether you understand that continuity is not just about backup, and that SLA commitments have security implications.

How Secure Software Deployment, Operations, Maintenance is tested

Eleven percent translates to between seven and nine items. They ask how to perform operational risk analysis, what secure configuration requires, how to monitor a running system, what the incident response plan says to do, or how to maintain continuity. The trap is choosing the answer that describes the ideal state rather than the minimum required by the outline. Another error is assuming that operational security is someone else's job, or that monitoring means watching a dashboard. The exam rewards candidates who know that operational risk includes personnel and legal compliance, that configuration management is version-controlled and documented, that monitoring generates data that must be analyzed, that incident response is a planned process with defined roles, that patch management includes testing, that vulnerability management is continuous, that runtime protection is layered, and that continuity planning addresses multiple failure modes. Candidates who think backup equals continuity, or who assume monitoring equals security, will miss these items. The exam often presents a scenario in which an incident occurred and asks what operational control would have detected or prevented it.

The final domain accounts for ten percent of the exam and addresses the risk introduced by third-party components, vendors and the supply chain itself. The domain covers supply chain risk management, security analysis of third-party software, pedigree and provenance, supplier security requirements, and contractual obligations. Candidates who assume that third-party code is someone else's problem, or who think a contract absolves them of responsibility, will lose marks across this domain.

– Risk management and third-party analysis

Implementing software supply chain risk management follows frameworks from ISO and NIST. It includes identification and selection of components, risk assessment of those components with decisions to mitigate or accept, maintaining a third-party components list such as a software bill of materials, and monitoring for changes and vulnerabilities. Analyzing security of third-party software examines certifications, assessment reports such as cloud controls matrix, and origin and support. The exam expects you to know that supply chain risk is continuous, that a bill of materials is a living document, and that third-party analysis is not a one-time check.

– Pedigree, provenance and supplier requirements

Verifying pedigree and provenance involves secure transfer with chain of custody, authenticity and integrity, system sharing and interconnections, code repository security, build environment security, cryptographically-hashed and digitally-signed components, and the right to audit. Ensuring and verifying supplier security requirements in the acquisition process includes audit of security policy compliance covering secure software development practices, vulnerability and incident notification, response, coordination and reporting, maintenance and support structure distinguishing community from commercial and licensing, security track record, scope of testing under a shared responsibility model, and log integration into SIEM. Supporting contractual requirements addresses intellectual property ownership, code escrow, liability, warranty, EULA and SLA. The exam tests whether you understand that provenance is about trust, that supplier requirements must be verified, and that contracts allocate risk but do not eliminate it.

How Secure Software Supply Chain is tested

Ten percent translates to between six and eight items. They ask how to manage supply chain risk, what to check in a third-party component, how to verify provenance, what to require in a contract, or what a supplier's security track record tells you. The trap is assuming that a certification or a contract means the component is safe. Another error is thinking that supply chain risk is static, or that a bill of materials is optional. The exam rewards candidates who know that supply chain risk management is a process, that third-party analysis includes origin and support, that pedigree and provenance require cryptographic verification, that supplier requirements must be audited, and that contracts define obligations but do not transfer all risk. Candidates who think a vendor's certification is sufficient, or who assume that open-source code is inherently more or less risky than commercial code, will miss the nuance the exam tests. Items often present a scenario in which a third-party component introduced a vulnerability and ask what supply chain control would have detected it. The correct answer is the one that verifies provenance, monitors for changes, or audits supplier practices.