FREE CSSLP Study Guide 2026: All 8 Domains

This free CSSLP study guide walks through every content domain the Certified Secure Software Lifecycle Professional exam tests, organized to the current ISC2 exam outline (effective September 15, 2023).^[1]

It’s interactive, not a wall of text: every module has built-in checkpoint quizzes, flashcards, and practice questions, so you learn by doing — not just reading.

The CSSLP tests eight official domains that follow the secure software lifecycle. We teach all eight in five study modules, grouping closely related lifecycle phases, and we invest most where the exam does — Architecture & Design, Implementation, and Testing.

Read a module, test yourself at each checkpoint, then drill gaps with our free practice test and flashcards. This guide is a high-yield overview that maps the official content — not a full secure-coding textbook.

CSSLP is one of the 9 ISC2 certifications — explore our ISC2 study guides to compare and prep across the whole family.

CSSLP Exam Snapshot

The CSSLP covers eight domains arranged along the secure software lifecycle. Unlike a flat split, the weights cluster in the middle of the lifecycle: Architecture & Design is the largest at 15%, with Implementation and Testing close behind at 14% each.^[1] Study by weight:

Because the domains map to phases of the lifecycle, it helps to see them as a sequence — and to remember that the Secure SDLC idea behind the whole exam is to build security in at every phase, not bolt it on at the end:^[3]

Module 1 · Secure Software Concepts & Lifecycle Management

Two official domains, 23% of the exam combined: Secure Software Concepts (12%) and Secure Software Lifecycle Management (11%). This module is the foundation — the security goals and design principles every other domain applies, and how you weave them through the development process.

1.1 Core Security Concepts & Principles

Everything starts with the CIA triad. Confidentiality prevents unauthorized disclosure (encryption, access control); Integrity prevents unauthorized change (hashing, digital signatures, input validation); and Availability keeps software reachable (redundancy, resilience). Three more pillars round it out: authentication (prove identity), authorization (what you may do), and Non-repudiation (you can’t deny an action).

The CSSLP leans hard on the classic secure design principles— they are the “best answer” behind countless questions. Know them: Least privilege, Defense in depth, Separation of duties, Fail-secure, Complete mediation, Open design (no security through obscurity), and Economy of mechanism (keep it simple). Each one exists to shrink the Attack surface or contain a failure.^[4]

1.2 Governance, Risk & Compliance

Software security lives inside GRC — governance, risk, and compliance. Governance sets policy and accountability; compliance maps legal and contractual obligations (GDPR, HIPAA, PCI DSS) onto the software; and risk management runs continuously.

Risk is the chance a threat exploits a vulnerability and the resulting impact. You assess it qualitatively (high/medium/low) or quantitatively (dollar-based, e.g., ALE = SLE × ARO), then choose a treatment — mitigate, transfer, avoid, or accept — knowing some Residual risk always remains.^[5]

1.3 Secure SDLC & Lifecycle Management

The central idea of the CSSLP: build security into every phase of the SDLC, not as a final test. That is the Secure SDLC, and the discipline of Shift left — moving threat modeling and testing earlier, where flaws are cheapest to fix. Security must fit your methodology: Waterfall (sequential gates), Agile (security embedded in each sprint), and DevSecOps (automated security inside CI/CD).^[3]

Programs are measured and improved with maturity models — BSIMM (descriptive, based on what real firms do) and OWASP SAMM (prescriptive). The NIST SSDF (SP 800-218) gives methodology-agnostic practices grouped into Prepare, Protect, Produce, and Respond. Across the lifecycle you also need security gates, security metrics, Configuration management, and a plan for secure decommissioning at end of life.

Module 2 · Secure Software Requirements

One official domain, 13% of the exam. You can’t build security you never specified. This domain is about capturing security as real, testable requirements — and the privacy and compliance obligations that drive them.

2.1 Functional & Non-Functional Requirements

Security requirements come in two flavors. A Functional security requirement says what the system must do (“lock the account after five failed logins”). A Non-functional security requirement is a quality the system must have — confidentiality, integrity, resilience. To find them, model the dark side: a Misuse case or Abuse case describes how a hostile actor would attack, and each one yields a security requirement and, later, a security test.^[1]

Tie it all together with a Requirements Traceability Matrix (RTM) — a grid that maps every security requirement to its design, code, and test, so nothing is dropped and everything is verified.

2.2 Data Classification & Privacy

Requirements depend on knowing your data. Data classification labels data by sensitivity (public, internal, confidential, restricted) so the right controls — encryption, access, retention, destruction — are applied across its lifecycle.

Privacy adds its own duties around PII: collect only what you need (data minimization), honor consent and retention limits, and respect cross-border transfer rules. The cleanest way to meet them is Privacy by design — bake privacy into requirements from the start.^[4]

Compliance obligations become requirements: GDPR (EU personal data), HIPAA (US health data), and PCI DSS (payment cards) each impose specific controls. Third-party and supplier security specifications are captured here too.

Module 3 · Secure Software Architecture & Design

One official domain, 15% — the largest on the exam. This is where you decide, on paper, how the software will resist attack. Get the architecture right and implementation becomes a matter of executing a secure plan; get it wrong and no amount of secure coding can save it.

3.1 Threat Modeling (STRIDE & PASTA)

Threat modeling is the heart of this domain: systematically identifying, enumerating, and prioritizing threats during design so controls are chosen before code exists. You model the system with a Data flow diagram (DFD), mark trust boundaries, then walk each element through a methodology. STRIDE is the most common taxonomy; the risk-centric PASTA adds attacker simulation, and attack trees break a goal into steps.^[8]

STRIDE is worth memorizing cold — each letter is a threat category that maps to a security goal and a class of control:

3.2 Secure Design & Cryptography

Good design reuses proven solutions — security design patterns — and runs an architectural risk assessment to prioritize controls. Cryptography choices are made here.

Symmetric encryption uses one shared key (AES) — fast but hard to distribute; Asymmetric encryption uses a public/private key pair (RSA, ECC) — slower but it solves key exchange and enables signatures. Real systems are hybrid.

For integrity, Hashing gives a one-way digest; a Digital signature adds authenticity and non-repudiation; and all of this trust is managed by PKI.^[4]

Architecture also means choosing for the platform: cloud (shared responsibility, multitenancy isolation), mobile/IoT/embedded (constrained, physically exposed), and microservices (per-service identity, mutual TLS, zero trust). And cryptography is only as strong as its Key management.

Module 4 · Secure Implementation & Testing

Two official domains, 28% of the exam combined — the heaviest pairing: Secure Software Implementation (14%) and Secure Software Testing (14%). This module turns a secure design into secure code, then proves it.

4.1 Secure Coding & Implementation

Secure coding comes down to a handful of habits. Input validation against an allowlist is the single most important defense — never trust user input. Output encoding stops data from being executed as code.

The two attacks they stop lead the OWASP Top 10: SQL injection (fixed with a Parameterized query) and Cross-site scripting (XSS) (fixed with output encoding and a Content Security Policy). In lower-level code, buffer overflows demand bounds checking and memory-safe practices.^[7]

You catch what review misses with code analysis: SAST reads source code without running it, and manual peer review finds the logic and auth flaws tools miss. Finally, protect the build itself with Code signing and anti-tampering, and never hardcode secrets — keep them in a vault. MITRE’s CWE/SANS Top 25 catalogs the dangerous coding errors to avoid.^[9]

4.2 Secure Software Testing

Testing proves the controls work. Build a security test strategy, then use complementary techniques. SAST (static, white-box, early) and DAST (dynamic, black-box, on a running app) find different bugs — use both. IAST instruments a running app to combine them. Fuzzing throws malformed input to trigger crashes, and a Penetration test actively exploits weaknesses under rules of engagement.^[3]

Round it out with negative/abuse-case testing (test what should be rejected), the distinction between Verification (built it right) and Validation (built the right thing), test data management (use anonymized or synthetic data — never real PII in test), and prioritizing findings by CVSS severity.

Module 5 · Deployment, Operations & Supply Chain

Two official domains, 21% of the exam combined: Secure Software Deployment, Operations & Maintenance (11%) and Secure Software Supply Chain (10%). Security doesn’t end at release — this module keeps software secure in production and accounts for the third-party code it’s built on.

5.1 Secure Deployment, Operations & Maintenance

Deploy securely: Hardening strips unnecessary services and accounts, and every deployment must match an approved Secure baseline — with Continuous monitoring to catch configuration drift. Protect the CI/CD pipeline that ships the software, and run services under least privilege. In operations you handle incident response, Patch management, and Vulnerability management, backed by runtime defenses like RASP and a WAF.^[4]

Resilience matters too: a business continuity plan (BCP) keeps functions running and disaster recovery (DR) restores them, governed by the recovery objectives RTO (time to recover) and RPO (acceptable data loss). At end of life, decommission securely — revoke access and keys, sanitize data, and remove the system from inventory.

5.2 Secure Software Supply Chain

Most modern software is mostly third-party code, so the Software supply chain is a major risk surface. Supply chain risk management (SCRM) manages it across the lifecycle. The foundation is the SBOM — a complete inventory of every component — so when a new flaw is disclosed you know instantly what is affected. Software composition analysis (SCA) tooling flags vulnerable and badly-licensed dependencies, and you verify a component’s Pedigree and provenance before trusting it.^[6]

Defend against supply-chain attacks like dependency confusion and typosquatting by pulling only from trusted registries, ensure build integrity (e.g., the SLSA framework) so artifacts come from trusted source via a tamper-resistant pipeline, and impose security requirements, contracts, and audits on suppliers. NIST SP 800-161 is the reference for SCRM practices.

How to Use This CSSLP Study Guide

This guide is built to be worked, not just read. The most efficient path to a pass:

• Study by weight. Architecture & Design (15%), Implementation (14%), and Testing (14%) are the heaviest — spend the most time there — but cover all eight domains.
• Think across the lifecycle. CSSLP questions ask for the best answer at a given phase. The recurring theme is “build security in early,” so favor design-time fixes over late patches.
• Check off as you go. Use the Study Guide Contents to mark each section done; it raises your exam-readiness score.
• Take every checkpoint. The end-of-module quizzes show you exactly which domains need another pass.
• Drill the weak domain. Send your weak area into the flashcards and a practice test until the score climbs comfortably above 700.

CSSLP Glossary

The high-yield CSSLP terms in one place — hover any dotted term in the guide, or flip the whole deck here as a self-grading flashcard set.

Abuse case

A deliberate, hostile interaction with the system used to surface threats and the controls needed to stop them.

Asymmetric encryption

Encryption using a public/private key pair (e.g., RSA, ECC); slower, but it solves key exchange and enables signatures.

Attack surface

The total set of points (inputs, interfaces, code paths) where an attacker could try to enter or extract data.

Attack tree

A diagram that breaks an attacker's goal into the steps and sub-steps needed to achieve it.

Availability

Ensuring authorized users have timely, reliable access to software and data; supported by redundancy and resilience.

BSIMM

Building Security In Maturity Model — a descriptive model that measures a software security program against observed real-world practices.

Buffer overflow

Writing past the bounds of a memory buffer to corrupt data or execute code; prevented by bounds checking and safe languages.

CIA triad

The three core goals of information security: Confidentiality (no unauthorized disclosure), Integrity (no unauthorized modification), and Availability (timely, reliable access for authorized users).

Code signing

Digitally signing a build so users can verify it came from the real publisher and has not been altered.

Complete mediation

Checking authorization on every access to an object, every time — never relying on a cached or prior decision.

Confidentiality

Preventing the unauthorized disclosure of data; protected primarily by encryption and access control.

Configuration management

Controlling and tracking changes to code, builds, and environments so the system stays in a known, secure state.

Continuous monitoring

Ongoing collection and analysis of logs, events, and metrics to detect security issues in operations.

Cross-site scripting (XSS)

Injecting malicious script into web output so it runs in another user's browser; prevented by output encoding and CSP.

CVSS

Common Vulnerability Scoring System — a 0–10 standard for rating the severity of a vulnerability.

CWE/SANS Top 25

MITRE's list of the 25 most dangerous software weaknesses — a coding-error reference.

DAST

Dynamic Application Security Testing — testing a running application from the outside to find runtime vulnerabilities.

Data classification

Labeling data by sensitivity so the right level of protection is applied throughout its lifecycle.

Data flow diagram (DFD)

A model of how data moves between processes, stores, and external entities across trust boundaries — the basis for STRIDE.

Defense in depth

Layering multiple, overlapping controls so that if one fails, others still protect the asset.

DevSecOps

Integrating automated security into CI/CD so security testing and gates run continuously alongside development and operations.

Digital signature

A hash of a message encrypted with the sender's private key, providing integrity, authenticity, and non-repudiation.

Economy of mechanism

Keeping the design as simple and small as possible to reduce the attack surface and the number of flaws.

Fail-secure

Designing a system so that when it fails, it defaults to a secure, denied state rather than an open, permissive one.

Functional security requirement

A requirement stating a security feature the system must do (e.g., lock the account after failed logins).

Fuzzing

Feeding malformed or random input to a program to discover crashes and security flaws.

GRC

Governance, Risk, and Compliance — the framework for aligning software security with policy, risk tolerance, and regulations.

Hardening

Reducing a system's attack surface by removing unnecessary services, accounts, and software and applying secure settings.

Hashing

A one-way function producing a fixed-length digest used to verify integrity (e.g., SHA-256); not reversible.

IAST

Interactive Application Security Testing — instruments a running app to combine inside code knowledge with live execution.

Input validation

Checking all input against an allowlist of expected format, type, and range before use — the primary defense against injection.

Integrity

Ensuring data and code are accurate and unaltered except by authorized parties; protected by hashing, digital signatures, and input validation.

Key management

The full lifecycle of cryptographic keys: generation, distribution, storage, rotation, and destruction.

Least privilege

Granting each user, process, and component only the minimum access needed to do its job — and nothing more.

Misuse case

A scenario describing how an actor could intentionally abuse the system; used to derive security requirements.

NIST SSDF

The Secure Software Development Framework (NIST SP 800-218): fundamental secure-development practices grouped into Prepare, Protect, Produce, and Respond.

Non-functional security requirement

A quality the system must have, such as confidentiality or resilience, rather than a discrete feature.

Non-repudiation

Assurance that a party cannot deny performing an action, achieved through digital signatures and reliable logging.

Open design

Security should not depend on the secrecy of the design — the opposite of security through obscurity.

Output encoding

Encoding data for the context it is rendered in so it is treated as data, not executable code.

OWASP SAMM

Software Assurance Maturity Model — a prescriptive framework for assessing and improving a secure-software program.

OWASP Top 10

A community list of the most critical web application security risks (e.g., broken access control, injection).

Parameterized query

A query where user data is bound as parameters, never concatenated into the SQL string — the definitive fix for SQL injection.

PASTA

Process for Attack Simulation and Threat Analysis — a risk-centric, seven-stage threat-modeling methodology.

Patch management

Tracking, testing, and applying security updates to software and dependencies promptly and in a controlled way.

Pedigree and provenance

Pedigree is a component's history of changes; provenance is where it originated — both verify trustworthiness.

Penetration test

An authorized, simulated attack that actively exploits weaknesses to demonstrate real impact.

PII

Personally Identifiable Information — data that can identify an individual, subject to privacy requirements.

PKI

Public Key Infrastructure — the certificate authorities, certificates, and policies that manage public keys and trust.

Privacy by design

Embedding privacy protections such as data minimization and retention limits into requirements and design from the outset.

RASP

Runtime Application Self-Protection — security built into the running application that detects and blocks attacks in real time.

Requirements Traceability Matrix (RTM)

A grid mapping each security requirement to its design, code, and test, proving every requirement is implemented and verified.

Residual risk

The risk that remains after controls are applied; senior management formally accepts it.

Risk

The likelihood that a threat will exploit a vulnerability, and the resulting impact on an asset.

SAST

Static Application Security Testing — analyzing source code without running it to find vulnerabilities early.

SBOM

Software Bill of Materials — a complete inventory of the components and dependencies in a piece of software.

SDLC

Software Development Lifecycle — the phases software moves through, from requirements to decommissioning.

Secure baseline

A documented, approved secure configuration all deployments must match; drift away from it is detected.

Secure SDLC

Building security into every phase of the SDLC rather than testing for it only at the end.

Separation of duties

Splitting a sensitive task so no single person or component can complete it alone, reducing fraud and error.

Shift left

Moving security activities such as threat modeling and testing earlier in the lifecycle, where flaws are cheaper to fix.

Software composition analysis (SCA)

Tooling that inventories open-source and third-party components and flags known vulnerabilities and license issues.

Software supply chain

Everything that goes into building and delivering software: source, dependencies, build tools, and distribution.

SQL injection

An attack that inserts malicious SQL through unvalidated input to read or alter a database.

STRIDE

A threat taxonomy: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.

Supply chain risk management (SCRM)

Identifying and mitigating security risks from third-party and open-source components and suppliers.

Symmetric encryption

Encryption using one shared secret key for both encrypting and decrypting (e.g., AES); fast, but key distribution is hard.

Threat modeling

Systematically identifying, enumerating, and prioritizing threats to a system during design so controls can be chosen early.

Trust boundary

A point where data or control passes between components of differing trust levels — a prime place to validate and authorize.

Validation

Confirming the right software was built — that it meets the user's real need.

Verification

Confirming the software was built right — that it meets its specification.

Vulnerability management

The ongoing cycle of identifying, prioritizing, remediating, and verifying vulnerabilities in deployed software.

WAF

Web Application Firewall — a control that inspects and filters HTTP traffic to block common web attacks.

CSSLP Study Guide FAQ

References

1. 1.ISC2. “CSSLP Certification Exam Outline (effective September 15, 2023).” isc2.org. ↑
2. 2.ISC2. “CSSLP — Certified Secure Software Lifecycle Professional.” isc2.org. ↑
3. 3.National Institute of Standards and Technology. “SP 800-218: Secure Software Development Framework (SSDF).” csrc.nist.gov. ↑
4. 4.National Institute of Standards and Technology. “SP 800-53 Rev. 5: Security and Privacy Controls.” csrc.nist.gov. ↑
5. 5.National Institute of Standards and Technology. “SP 800-30 Rev. 1: Guide for Conducting Risk Assessments.” csrc.nist.gov. ↑
6. 6.National Institute of Standards and Technology. “SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management.” csrc.nist.gov. ↑
7. 7.OWASP Foundation. “OWASP Top 10 Web Application Security Risks.” owasp.org. ↑
8. 8.OWASP Foundation. “Threat Modeling.” owasp.org. ↑
9. 9.MITRE Corporation. “CWE/SANS Top 25 Most Dangerous Software Weaknesses.” cwe.mitre.org. ↑
10. 10.International Organization for Standardization. “ISO/IEC 27034 — Application Security.” iso.org. ↑
11. 101.National Institute of Standards and Technology (NIST). “Cryptographic Standards and Guidelines.” csrc.nist.gov, accessed 19 June 2026. ↑

Career Employer

Career Employer is the ultimate resource to help you get started working the job of your dreams. We cover topics from general career information, career searching, exam preparation with free study materials, career interviewing, and becoming successful in your career of choice.

Follow Us:

All Posts