Domain 1: Secure Software Concepts
- Defense in depth requires layered independent controls, so no single control is treated as sufficient for a whole class of risk - transport encryption does not substitute for encryption at rest.
- Least privilege grants a subject only the permissions its specific function needs, for only as long as it needs them; reusing an existing privileged identity inherits everything that identity holds.
- Fail-safe defaults require that errors, timeouts and unspecified conditions resolve toward denial, so an unreachable dependency produces a refusal rather than an unverified grant.
- Complete mediation checks authority on every access rather than inferring it from an earlier decision, which is what makes a revoked entitlement take effect immediately.
- Economy of mechanism keeps security-critical components small enough to be completely analysed; complexity the requirement does not justify is a direct cost to assurance.
- Least common mechanism warns that any resource shared across a trust boundary can become a channel between the parties, including through timing and eviction behaviour.
- Open design (the design-principle form of Kerckhoffs's principle) holds that security must rest on the secrecy of keys, never on the secrecy of the design.
- Separation of duties splits an end-to-end process so completing it requires collusion; dual control (two-person control) requires two parties to authorise one single action.
- Bell-LaPadula is the confidentiality model (no read up, no write down); Biba is the integrity model (no write up); Clark-Wilson enforces integrity through certified transformation procedures; Brewer-Nash (Chinese Wall) changes access dynamically to prevent conflicts of interest.
- The trusted computing base is the totality of protection mechanisms whose correct operation the security policy depends on, and membership is determined by dependency rather than by intent.
- A reference monitor must always be invoked, be tamper-proof, and be small enough to be completely analysed and tested.
- Non-repudiation needs two things together: an identity binding only one party could have produced (a private signing key), and tamper-evident evidence - an HMAC under a shared key cannot support it.
- Quantitative risk uses SLE = asset value x exposure factor and ALE = SLE x ARO; residual risk is what remains after controls, and it is the figure a named owner formally accepts.
- Pseudonymised data remains personal data because a retained mapping permits re-identification; anonymisation requires the mapping to be destroyed and the residual data to resist re-identification.
Domain 2: Secure Software Lifecycle Management
- Security activities distributed across requirements, design, coding and testing cost far less than a single gate before release, which arrives when the cost of saying no is highest.
- In iterative delivery, assurance activities become smaller and continuous rather than large and phase-gated; coverage must not shrink because the iterations are short.
- Putting security criteria in the definition of done makes them part of finishing every story, rather than an event that happens to the team later.
- Software configuration management identifies and controls the items in a release, so the exact source, configuration and dependency versions behind a running binary can be reconstructed.
- Change control must include a defined emergency path with retrospective review, because a process that cannot accommodate genuine urgency gets bypassed the first time it matters.
- Build once and promote the same artefact through each environment; rebuilding per environment means the artefact tested is not the artefact deployed.
- A build definition is executable content, so whoever can edit it can run code with the build identity's authority - it needs the same review and protection as application source.
- Static analysis belongs on every pull request; dynamic scanning needs a deployed build; dependency scanning must be scheduled because dependency risk changes without any code change.
- Defect density normalises findings against codebase size, so 180 findings across 900,000 lines (0.20 per thousand) is better than 120 across 400,000 (0.30).
- A key performance indicator measures how well an activity was executed; a key risk indicator signals exposure building before a loss - report gate pass rate alongside the waiver rate or the figure misleads.
- A bug bar agreed in advance fixes the release threshold before schedule pressure applies, and needs a defined exception route or it gets quietly reinterpreted.
- Decommissioning is a security activity: it must sanitise the data to its classification and revoke the credentials, certificates and service accounts that keep working after the system stops.
- Certification is the technical evaluation against requirements; accreditation (authorisation to operate) is the accountable official's decision to accept the residual risk.
- Copying production data into test extends the full regulatory and breach exposure into an environment with wider access, weaker monitoring and longer-lived credentials.
Domain 3: Secure Software Requirements
- Functional security requirements state a behaviour the system must exhibit; non-functional ones constrain a quality of that behaviour, such as revocation propagating within 60 seconds.
- A requirement must state an observable condition a test can pass or fail; 'the system shall be secure' assumes the very definition the requirements set exists to supply.
- Abuse and misuse cases invert the use case: they state an attacker's goal and what the system must do to defeat it, which turns implicit assumptions into stated requirements.
- A security requirements traceability matrix links each requirement forward to design and test and backward to its source, so gaps and change impact are both visible.
- State the property, not the mechanism: reference the organisation's cryptographic standard rather than naming an algorithm and parameter that will age.
- Regulatory text must be decomposed into buildable requirements, each traced to its clause - a single requirement to comply with a regulation can be neither implemented nor tested.
- Deny by default means a missing rule refuses access; permit unless prohibited means every unanticipated case becomes an unintended grant.
- Prefer allowlist validation stating what is acceptable per field over denylists, which require every dangerous construct to have been anticipated.
- Output encoding must name the context - HTML body, attribute, URL and script each require a different transformation, so 'escape the value' is not implementable.
- Session requirements need both an inactivity timeout and an absolute lifetime, or a continuously exercised session (including a stolen one) never ends.
- Consent as a lawful basis requires a freely given affirmative act, a recorded scope, and withdrawal as easy as giving - bundling it into terms of service fails the freely given test.
- A retention schedule sets both a floor and a ceiling: designs routinely implement the retention and omit the disposal, and data held past its schedule is discoverable and often unlawful.
- Audit requirements need integrity protection and sufficient content (actor, action, object, outcome, time) as well as a retention period; unlogged events cannot be recreated later.
- Secure operational architecture requirements - topology, network zoning, administrative access paths - belong in the requirements set, not left to whoever builds the environment.
Domain 4: Secure Software Architecture and Design
- STRIDE pairs each threat with the property it violates: spoofing/authentication, tampering/integrity, repudiation/non-repudiation, information disclosure/confidentiality, denial of service/availability, elevation of privilege/authorisation.
- Threat modelling delivers most value during design, while structural findings are still cheap to act on; revisit it when a change adds or moves a trust boundary or an authority decision.
- Architectural risk analysis finds flaws in the structure that no amount of code reading reveals; code review finds bugs where a sound design was implemented incorrectly.
- A trust boundary marks where data crosses between parties of differing trust, and it is where validation must be re-applied and authority re-established.
- Network location is not identity: service-to-service calls need mutual authentication or signed workload tokens, since any compromised neighbour otherwise inherits full authority.
- Authorisation enforced in a client is not a control, because the client runs on hardware the user owns; hide controls for usability and decide on the server.
- Separate the policy decision point from distributed policy enforcement points: policy is authored once, and enforcement sits at every resource so no path bypasses it.
- Hybrid encryption is the practical construction - a random symmetric key protects the payload and only that key is encrypted to the recipient's public key.
- AES-GCM requires that a nonce never repeat under one key and that the authentication tag be verified before any plaintext is used.
- Certificate validation requires four checks together: chain to a trusted root, validity dates, hostname match, and revocation status; the hostname check is the one most often omitted.
- Envelope encryption wraps per-tenant data keys under a master key, so rotating the master key re-encrypts a small set of key blobs rather than every record, and destroying a tenant key is an effective erasure.
- OAuth 2.0 scope bounds what the client may attempt; it is not the authorisation decision, which must still establish which records the user is entitled to.
- A JWT must be validated for issuer and audience as well as signature, and the expected algorithm must be fixed in configuration rather than read from the token header.
- Containers share a host kernel, so hostile or customer-supplied code warrants a hypervisor boundary or a sandboxed runtime; a namespace is an organisational scope, not an isolation boundary.
Domain 5: Secure Software Implementation
- Parameterised statements remove injection as a class because the value is never parsed as part of the statement; escaping mitigates it and depends on being correct at every call site.
- Second-order injection stores a value safely and concatenates it into a query later, so data is untrusted by origin rather than by where it was read from.
- Identifiers such as table and sort column names cannot be bound as parameters, so they must be mapped through an allowlist and the matched constant used.
- Command injection is removed by invoking an executable with an argument array rather than through a shell; argument injection remains, because the invoked program parses its own options.
- XML external entity attacks are prevented by disabling document type definition processing and external entity resolution at every parser instance.
- Deserialising untrusted data with a general-purpose format reconstructs attacker-chosen types and runs their initialisation logic, which is arbitrary code execution.
- Reflected, stored and DOM-based cross-site scripting differ in where the payload lives; DOM-based flaws never reach the server, so the fix must be at the client sink.
- Canonicalise before validating, because the resolved path or value is what the platform will actually act on.
- Integer defects: a wrapped multiplication produces an undersized allocation, and a negative signed length passes an upper-bound check then converts to a huge unsigned size.
- Use-after-free is exploitable because the freed block can be reallocated with attacker-controlled content that the stale pointer then reads as the original object.
- Stack canaries, non-executable memory and address randomisation raise the cost of exploitation without removing the underlying memory error.
- Compare secrets with a constant-time function, because ordinary equality returns at the first differing byte and leaks how much of the value matched.
- Verify a signature before parsing or acting on a message, so no work is performed on behalf of an unauthenticated party.
- Never use an evaluation function, reflection by client-supplied type name, or a user-supplied template on untrusted input - each is arbitrary code execution by a different route.
Domain 6: Secure Software Testing
- Static analysis reads source and cannot see deployed configuration; dynamic scanning exercises a running system and reports only on the paths it actually reached.
- Interactive analysis instruments the running application, combining source-level precision with runtime evidence, and inherits the coverage of the tests that drive it.
- Composition analysis reports which vulnerable components are present; reachability and exposure must be established before the findings can be prioritised.
- Tuning a tool to reduce false positives raises false negatives, and the latter are invisible - nothing in the report indicates what is no longer being looked for.
- Coverage-guided fuzzing retains inputs that reach new code, which is what lets it get past early validation into the deeper parsing logic; corpus quality dominates results.
- Security requirements are usually negative, so a suite of positive cases passes in full while the control is entirely absent - the deny cases are the ones that matter.
- Boundary testing needs values immediately either side of each limit plus a wrong-type value; values in the middle of a range exercise the same accepting branch repeatedly.
- Code coverage measures which lines executed, not what was asserted, and the highest-impact security defects are missing code that no coverage measure can reach.
- A vulnerability assessment enumerates, a penetration test demonstrates exploitability and chains findings, and a red team exercise tests detection and response.
- Verification of a remediation must probe variants - encodings, other parameters, other endpoints sharing the routine - because a fix aimed at one payload leaves the class intact.
- Authorisation coverage needs a full matrix of roles against operations with the expected permit or deny per cell, generated from a table rather than written by hand.
- Multi-tenant isolation cannot be tested from a single tenant's suite: two tenants with distinguishable data are required, with cross-boundary requests asserted to be refused.
- A detection capability is only proven by generating the pattern deliberately and confirming the alert reaches the responding team, which tests the whole chain.
- Only a restore into a clean environment verifies recoverability; a successful backup job says nothing about key availability, scope completeness or format compatibility.
Domain 7: Secure Software Deployment, Operations and Maintenance
- Resolve the bootstrapping problem with a platform-attested workload identity, so there is no first secret to distribute or rotate.
- Immutable infrastructure replaces instances rather than mutating them, so the running estate matches a reviewed artefact and drift has a bounded lifetime.
- Blue-green deployment separates deploying from releasing, and keeps the previous version available so reversion is a routing change measured in seconds.
- A canary should be gated on security signals as well as latency - a sharp fall in authorisation failures can mean a check was removed.
- Sequence destructive migrations separately from code changes (expand and contract) so every individual deployment remains reversible.
- Enforce artefact signature verification at the platform through an admission policy, not in the deployment tool, because a workload can be started by other paths.
- Audit log integrity requires append-only storage in a separate trust domain with the source holding no delete permission, since clearing traces is a standard early action.
- Incident response order is contain, eradicate, recover: recovering before eradication returns the intruder to a restored system, and a restart destroys volatile evidence.
- Log retention must be set against plausible intruder dwell time rather than troubleshooting need, or the beginning of an intrusion is unknowable.
- Priority follows likelihood as well as severity, so a published exploit and observed use in the wild should raise a medium finding sharply.
- Where no patch exists, reduce reachability and add detection for the known vulnerable path; a perimeter rule is a temporary compensating control, not remediation.
- Ransomware-resistant backups must sit in a separate trust domain with immutability that the production administrative credential cannot override.
- Media sanitisation levels follow the media's destination: clear for internal reuse, purge for media leaving organisational control, destroy where purge cannot be verified.
- A retired system leaves data, credentials, certificates, hostnames and partner integrations behind - all still valid, and all unmonitored once attention moves on.
Domain 8: Secure Software Supply Chain
- Dependency confusion exploits a resolver that prefers the highest version across sources; prevent it by scoping internal names and resolving them only from the internal registry.
- Typosquatting works because installation executes lifecycle scripts, so a single mistyped name yields code execution on a developer machine or build agent.
- A lockfile with integrity hashes gives a reproducible dependency set and detects a package republished under the same version with altered content.
- Adopting a direct dependency accepts every maintainer in the resolved tree, so scanning, licence checks and provenance verification must cover the full graph.
- An abandoned component means no fix will arrive when a vulnerability is disclosed, which makes maintenance activity a security signal at selection time.
- A delay before new versions become available internally, plus review of the diff, is one of the few controls that catches a genuinely novel malicious release.
- A software bill of materials turns advisory triage from a multi-day investigation into a query; generate it at build time, since post-hoc inspection silently omits what it cannot recognise.
- Provenance attestation records the source revision, build definition and builder identity - a signature says who signed, not how the artefact was made.
- Reproducible builds let an independent party rebuild and compare, which is the only technique that detects a compromised build system inserting code.
- A hermetic build with no network access forces every input to be declared and pre-fetched, so the reviewed input set and the consumed set are the same.
- Pin third-party pipeline actions to an immutable commit digest and withhold production credentials from any job that runs third-party code.
- Tier supplier assessment depth by the data and access each holds, and reassess periodically, because a supplier's people, systems, subprocessors and ownership all change.
- Escrow works only if it is held independently, has specific release triggers, is updated as the component evolves, and is verified to actually build.
- Outsourcing transfers work and contractual liability, never accountability to customers and regulators - which is why requirements, acceptance criteria and verification rights matter more, not less.
(ISC)² CSSLP exam tips
- Read every question as a lifecycle question: the same topic has a different answer in requirements, design, implementation and operations. If a stem is set during design, the best answer changes the structure; if it is set during testing, the best answer is a test.
- Prefer the answer that removes a class of defect over one that mitigates an instance. Parameterisation beats escaping, an allowlist beats a denylist, deny-by-default beats an added rule, and structural enforcement beats a check every developer must remember.
- Watch for options that are true statements but answer a different question. A distractor that describes a real control accurately is still wrong if it addresses confidentiality when the stem asks about integrity, or detection when the stem asks about prevention.
- When an option relies on the network, the client or an obscure name for its safety, it is almost always the wrong answer. CSSLP consistently rejects location-based trust, client-side enforcement and security through obscurity.
- For requirements and testing questions, ask whether the option is verifiable. A requirement that cannot be tested and a test that asserts only the absence of an error are both treated as inadequate, however sensible they sound.
Study guide FAQ
How is the CSSLP exam structured and scored?
The CSSLP is 125 multiple-choice questions in a maximum of 180 minutes (3 hours). It is scored on a 1000-point scaled score with 700 required to pass, so the pass mark is not a raw percentage of questions answered correctly. Items are distributed across the eight domains per the (ISC)² outline effective 15 September 2023: Secure Software Concepts 12%, Secure Software Lifecycle Management 11%, Secure Software Requirements 13%, Secure Software Architecture and Design 15%, Secure Software Implementation 14%, Secure Software Testing 14%, Secure Software Deployment/Operations/Maintenance 11%, and Secure Software Supply Chain 10%.
What experience do I need before taking the CSSLP?
(ISC)² requires four years of cumulative paid full-time work experience in the software development lifecycle in one or more of the eight CSSLP domains, or three years with a relevant four-year degree or an approved credential. If you pass the exam without the experience, you become an Associate of (ISC)² and have five years to earn it. The experience requirement is why the exam rewards judgement about trade-offs rather than recall of definitions.
How does the CSSLP differ from the CISSP and from developer-focused certifications?
The CISSP covers information security management broadly across eight domains, of which software development security is one. The CSSLP goes deep on that one area, covering requirements, architecture, coding, testing, deployment, operations and the software supply chain in detail. It is also vendor-neutral and role-neutral: it does not test a specific language or framework, so questions concern principles, patterns and lifecycle decisions rather than syntax.
Do I need to be a working developer to pass the CSSLP?
No. The exam is written for everyone who influences software security decisions, including architects, testers, security engineers, project managers and procurement staff, and a substantial share of the content concerns requirements, testing strategy, operations and supplier risk rather than code. You do need to recognise the major implementation defect classes - injection, memory safety errors, deserialisation, cross-site scripting and race conditions - and understand why each fix works, without needing to write the code yourself.