Your FREE CSSLP Flashcards 2026 – 250+ Cards

Confidentiality, Integrity, and Availability — the three core goals of information security that every software security control supports.

Preventing unauthorized disclosure of data, typically enforced with encryption and access control.

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

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

Proving a claimed identity using a credential (something you know, have, or are) before access is granted.

Determining what an authenticated identity is allowed to do — which resources and actions are permitted.

Tying actions back to a specific identity through logging, auditing, and monitoring.

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

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

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

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

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

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

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

Keep the design as simple and small as possible — simpler systems have a smaller attack surface and fewer flaws.

Security controls must be easy to use, or users will bypass them; usability is a security design principle.

Minimize shared mechanisms (e.g., shared resources) between users to reduce unintended access paths.

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

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

Depth = layered controls along one path; breadth = covering all the different attack vectors. Secure software needs both.

A threat is a potential cause of harm; a vulnerability is a weakness it can exploit; risk is the likelihood and impact of that exploitation.

A component whose failure takes down the whole system; secure/resilient design eliminates it through redundancy.

Preventive, detective, corrective, deterrent, recovery, and compensating — categorized by function across administrative, technical, and physical classes.

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

Building security in from the start and shipping with the most secure settings enabled out of the box.

Relying on secrecy of design as the main protection — discouraged; it violates the open-design principle and fails once the secret leaks.

No single control should be trusted alone; layering ensures the failure of one control does not expose the asset.

Limiting access to the specific information required for a task, even among authorized users; pairs with least privilege.

A subject is an active entity (user, process) that acts; an object is a passive resource (file, record) acted upon.

Qualitative risk ranks risks subjectively (high/medium/low); quantitative risk assigns dollar values (e.g., ALE = SLE × ARO).

Mitigate (reduce with controls), transfer (e.g., insurance), avoid (stop the activity), or accept (formally tolerate the residual risk).

The risk that remains after controls are applied; management must formally accept it.

Confidentiality protects data from disclosure; privacy concerns an individual's right to control how their personal data is used.

WAF + input validation + parameterized queries + least-privilege DB account + encryption — layered so one failure is not fatal.

Software Development Lifecycle — the phases software moves through: requirements, design, implementation, testing, deployment, operations, and decommissioning.

Building security into every phase of the SDLC instead of testing for it at the end — the central idea of the CSSLP.

Moving security activities (threat modeling, testing) earlier in the lifecycle, where flaws are cheaper to fix.

A sequential development model with distinct phases; rigid but predictable — good for stable requirements.

Iterative development in short sprints with frequent delivery; security must be embedded in each iteration.

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

An iterative model that performs explicit risk analysis at the start of each cycle.

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

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

A checkpoint in the lifecycle where security criteria must be met before work proceeds to the next phase.

Quantitative measures (e.g., defect density, time-to-remediate, coverage) used to track and improve software security.

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

Tracking and managing changes to source code over time; underpins traceability, rollback, and code integrity.

Securely retiring software: removing access, sanitizing data, archiving as required, and disposing of credentials and keys.

Organization-wide awareness, training, and shared responsibility that makes secure development the default behavior.

The Secure Software Development Framework — a set of high-level secure-development practices grouped into Prepare, Protect, Produce, and Respond.

QA checks the software does what it should; security assurance checks it does NOT do what it shouldn't (abuse cases, misuse).

Feeding lessons learned, metrics, and incident findings back into the process so each release is more secure than the last.

A planned set of security objectives, controls, and maturity goals aligned to business risk over time.

Identifying, assessing, treating, and monitoring software risk continuously across every phase, not just once.

Justified confidence that software is free from vulnerabilities and functions as intended — the goal of the secure SDLC.

Threat modeling belongs early (requirements/design), so threats are addressed before code makes them expensive to fix.

A developer embedded in a team who advocates for security practices and bridges to the security team.

Including security criteria (tests passed, no high findings) in a story's acceptance, so security is part of 'done.'

Defects cost far more to fix the later they are found — cheapest in design, most expensive in production. The case for shifting left.

BSIMM/SAMM let an organization measure where its software-security program stands and plan concrete improvements.

Predefined security checkpoints (design review, code review, pen test) that must pass before moving to the next phase.

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

A quality the system must HAVE (e.g., confidentiality, performance, resilience) rather than a discrete feature.

A scenario describing how an actor could intentionally abuse the system; the inverse of a use case, used to derive security requirements.

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

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

Labeling data by sensitivity (e.g., public, internal, confidential, restricted) so the right protection is applied throughout its lifecycle.

The stages data moves through: create, store, use, share, archive, and destroy — each needing appropriate controls.

Personally Identifiable Information — data that can identify an individual; subject to privacy requirements and special handling.

Embedding privacy protections (data minimization, consent, retention limits) into requirements and design from the outset.

Collecting and retaining only the data actually needed for the purpose — a core privacy requirement.

Legal constraints on transferring personal data between jurisdictions (e.g., GDPR), which become software requirements.

Obligations from laws, regulations, and standards (GDPR, HIPAA, PCI DSS) that translate into specific security requirements.

Payment Card Industry Data Security Standard — security requirements for systems that store, process, or transmit cardholder data.

A requirements technique listing who (subjects) can do what (activities) to which data (objects) — drives access requirements.

Derived from policy, regulations, risk assessment, abuse/misuse cases, data classification, and stakeholder needs.

Security specifications imposed on vendors and components the software depends on, set during requirements.

How long data must be kept and when it must be destroyed, driven by legal, regulatory, and privacy obligations.

Functional requirements say what security to build; assurance requirements say how much confidence (evidence/testing) is required.

A use case shows legitimate behavior; a misuse case shows hostile behavior — together they define needed security controls.

Identifying where regulated/sensitive data lives in the system so requirements can mandate its protection.

A requirement states the security need; a control is the specific mechanism implemented to satisfy it.

Regulatory requirements come from law (GDPR, HIPAA); contractual ones come from agreements (PCI DSS, customer contracts).

The EU General Data Protection Regulation — governs processing of personal data, consent, breach notice, and cross-border transfer.

U.S. law setting privacy and security requirements for protected health information (PHI).

Owner (accountable, sets classification), custodian (implements controls), and processor (handles data on the controller's behalf).

Translating high-level policy into specific, testable security requirements the software must meet.

Explicit statements of what the system must NOT do or allow, derived from abuse/misuse cases.

A structured review of how a system collects and uses personal data, identifying privacy risks and required controls.

Following each security requirement through design, code, and test (via the RTM) to prove it is implemented and verified.

Systematically identifying, enumerating, and prioritizing threats to a design so controls can be chosen before code is written.

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

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

A (legacy) risk-rating model: Damage, Reproducibility, Exploitability, Affected users, Discoverability.

A diagram that breaks an attacker goal (root) into the steps and sub-steps needed to achieve it; used to analyze threats.

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

A reusable, proven solution to a recurring security problem (e.g., secure proxy, single access point, defense in depth).

Encryption using one shared secret key for both encryption and decryption (e.g., AES) — fast, but key distribution is hard.

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

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

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

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

The full lifecycle of cryptographic keys: generation, distribution, storage, rotation, and destruction — often the weakest link.

Evaluating a design for security weaknesses and prioritizing them by risk before implementation begins.

Designing interfaces with authentication, authorization, input validation, rate limiting, and minimal exposed surface.

Designing for the shared-responsibility model, multitenancy isolation, identity federation, and data protection in cloud environments.

Architectures must address constrained resources, untrusted networks, physical access, and secure update of distributed devices.

Securing distributed services with mutual TLS, per-service identity, API gateways, and zero-trust between components.

An architecture that never implicitly trusts based on network location — every request is authenticated and authorized.

Isolating untrusted code or processes in a confined environment so it cannot affect the rest of the system.

Tokenization replaces sensitive data with a non-sensitive token (no math link); encryption transforms data reversibly with a key.

Choosing which controls to apply first based on the risk they reduce versus their cost — output of architectural risk analysis.

Partitioning the architecture into zones of differing trust (e.g., DMZ, internal) with controls at each boundary.

Inference = deducing protected data from accessible data; aggregation = combining harmless data into sensitive data. Design must mitigate both.

Designing so algorithms and key lengths can be swapped out as standards change, without re-architecting the system.

Enumerating every entry point, interface, and data path to understand and reduce where attacks can occur.

A structured evaluation of the architecture against security principles and threat models before implementation.

A confidentiality model: 'no read up, no write down' — prevents information flow to lower security levels.

An integrity model: 'no read down, no write up' — prevents contamination of high-integrity data by lower-integrity sources.

The abstract concept that mediates all access between subjects and objects; implemented by the security kernel.

Adding a unique random value to each password before hashing, so identical passwords produce different hashes and rainbow tables fail.

Choosing strong, current algorithms (AES, SHA-256, RSA-2048+) and adequate key lengths is a design-time decision.

Designing session IDs to be random, transmitted over TLS, expired/idle-timed, and invalidated on logout to prevent hijacking.

Letting users authenticate once with a trusted identity provider (e.g., SAML, OIDC) and access multiple services.

Placing controls at every tier (client, network, app, data) so a breach of one layer is contained by the next.

The output: a list of threats (by STRIDE category), their risk, and the mitigations/controls assigned to each.

Pretending to be someone/something else; mitigated by strong authentication.

Unauthorized modification of data or code; mitigated by integrity controls (hashing, signatures, access control).

Denying an action was performed; mitigated by non-repudiation controls (logging, digital signatures).

Exposing data to unauthorized parties; mitigated by encryption and access control (confidentiality).

Making a system unavailable; mitigated by rate limiting, resilience, and redundancy (availability).

Gaining higher rights than authorized; mitigated by least privilege and rigorous authorization checks.

Writing code that resists abuse: validating input, encoding output, handling errors safely, and using vetted security APIs.

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

Encoding data for the context it is rendered in (HTML, JS, SQL, URL) so it is treated as data, not executable code.

Inserting malicious SQL through unvalidated input to read or alter a database; prevented by parameterized queries and input validation.

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

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

Tricking a logged-in user's browser into sending an unwanted request; prevented with anti-CSRF tokens and SameSite cookies.

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

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

The MITRE Common Weakness Enumeration and the list of the 25 most dangerous software weaknesses — a coding-error reference.

Failing securely: catch errors, log them safely, and never leak stack traces or sensitive details to the user.

Avoiding overflows, use-after-free, and leaks; preferring memory-safe languages or safe library functions.

Static Application Security Testing — analyzing source code (without running it) to find vulnerabilities early. Also called static analysis.

Humans reading code to find logic and security flaws that automated tools miss; especially valuable for auth and crypto code.

Techniques (code signing, obfuscation, integrity checks) that detect or prevent unauthorized modification of software.

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

A reproducible, protected pipeline that compiles trusted source into trusted artifacts, free of injected or unauthorized code.

Code intentionally inserted to cause harm (backdoor, logic bomb, trojan); detected through review and integrity verification.

Enforcing that operations only act on compatible data types, preventing a class of memory and logic vulnerabilities.

Reducing input to its simplest, standard form before validation, so attackers cannot bypass checks with alternate encodings.

Allowlisting permits only known-good input (preferred, secure by default); denylisting blocks known-bad and misses novel attacks.

A flaw where the state changes between a check and its use (Time-Of-Check to Time-Of-Use); fixed with atomic operations/locking.

Embedding credentials or keys in source code — a serious flaw; secrets belong in a vault or secure configuration, never in code.

Initializing variables, permissions, and configurations to their safest values so omissions fail closed, not open.

An arithmetic result exceeding the variable's range, wrapping to a wrong (often small) value and enabling overflow attacks.

Failing to enforce what users are allowed to do; the #1 web risk — enforce authorization on the server for every request.

Weak or missing encryption, bad key handling, or outdated algorithms exposing sensitive data; an OWASP Top 10 category.

Trusting serialized data from users so it can execute code or tamper with objects; validate and avoid native deserialization of untrusted data.

Passing unvalidated input into an OS command; prevented by avoiding shell calls and using safe APIs with strict input validation.

Using '../' sequences in input to access files outside the intended directory; prevented by canonicalization and allowlists.

Tricking a server into making requests to unintended internal targets; mitigated by allowlisting destinations and blocking internal ranges.

Logging security events without recording secrets/PII, and protecting logs from tampering.

Accessing memory after it has been freed, leading to crashes or code execution; avoided by memory-safe practices and languages.

Using a cryptographically secure RNG (not a predictable PRNG) for tokens, keys, and session IDs.

A browser-enforced allowlist of content sources that helps mitigate XSS by restricting where scripts can load from.

Storing credentials and keys in a vault/secret manager with rotation and access control — never hardcoded or in config files.

Business-logic vulnerabilities are missed by scanners; they require threat modeling, manual review, and abuse-case testing.

A plan defining what security to test, how, when, and with which tools across the lifecycle — driven by requirements and risk.

Dynamic Application Security Testing — testing a running application from the outside (black-box) to find runtime vulnerabilities.

SAST inspects source code at rest (early, white-box); DAST exercises a running app (later, black-box). Use both for coverage.

Interactive Application Security Testing — instruments a running app to combine inside knowledge (like SAST) with live execution (like DAST).

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

An authorized, simulated attack that actively exploits weaknesses to demonstrate real impact, performed under rules of engagement.

Automated checking for known weaknesses without exploiting them; broad and frequent, unlike a pen test.

Functional security tests verify a control works (e.g., lockout); non-functional tests check qualities like resilience and performance under load.

Testing what the software should reject or prevent (invalid input, misuse) rather than only the happy path.

Deriving concrete security test cases directly from the misuse/abuse cases identified in requirements.

Verification asks 'did we build it right?' (meets spec); validation asks 'did we build the right thing?' (meets the real need).

Re-running tests after changes to confirm previously fixed vulnerabilities and working controls were not broken.

Using anonymized, masked, or synthetic data in test environments so real sensitive data is never exposed.

Anonymization irreversibly removes identifying detail; masking obscures data while keeping format — both protect test data.

Common Vulnerability Scoring System — a 0–10 standard for rating the severity of a vulnerability, used to prioritize fixes.

A false positive flags a non-issue (wastes effort); a false negative misses a real flaw (dangerous). Tuning balances them.

A metric of how much code the tests exercise; high coverage increases (but does not guarantee) confidence in security testing.

An isolated environment mirroring production where security testing runs without risking real systems or data.

Logging, prioritizing (e.g., by CVSS), assigning, and verifying the fix of each security defect found in testing.

Test perspectives by knowledge: black-box (none), white-box (full source/design), gray-box (partial).

An automated set of security tests run on each build to ensure fixed vulnerabilities do not reappear.

The agreed scope, timing, methods, and limits for a penetration test; testing without authorization is a crime.

Risk-based testing focuses effort on the highest-risk areas rather than treating all code equally.

Reviewing tool output to remove false positives and prioritize true vulnerabilities by severity (e.g., CVSS) before remediation.

Testing how the system behaves under extreme load to confirm availability controls and graceful failure.

Confirming all security test criteria are met before a release is approved to ship.

Artificially generated data that mimics production format without using real sensitive records.

Static (SAST) examines code without running it; dynamic (DAST) tests the running application from the outside.

A focused automated test that verifies a single security control (e.g., that an input validator rejects bad input).

An authenticated scan logs in for deeper coverage; an unauthenticated scan sees only what an outside attacker would.

Releasing software with hardened configuration, least-privilege accounts, and verified integrity into a controlled environment.

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

A documented, approved secure starting configuration that all deployments must match and drift away from is detected.

Protecting the automated build/test/deploy pipeline with access control, signed artifacts, and integrated security gates.

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

The structured process to detect, contain, eradicate, recover from, and learn from a security incident.

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

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

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

Web Application Firewall — a control that inspects and filters HTTP traffic to block common web attacks before they reach the app.

Assessing the risks introduced once software is live (configuration, dependencies, environment) and the controls to manage them.

A controlled process for evaluating, approving, documenting, and rolling back changes to deployed software.

A plan to keep critical business functions running during and after a disruption.

The processes to restore IT systems and software operations after a disruptive event.

Recovery Time Objective — the target time to restore a system after a disruption; must be shorter than the maximum tolerable downtime.

Recovery Point Objective — the maximum acceptable data loss measured backward in time; it drives backup frequency.

Retiring software safely: revoking access and keys, sanitizing data, and removing the system from monitoring and inventory.

A formal sign-off (authorization) that residual risk is acceptable before software goes or stays in production.

Release strategies that limit blast radius by running a new version alongside the old and shifting traffic gradually.

Scanning and controlling declarative infrastructure definitions so misconfigurations are caught before deployment.

Recording security-relevant events tamper-resistantly so incidents can be detected, investigated, and attributed.

When a live system diverges from its approved secure baseline; continuous monitoring detects and corrects it.

Running services and accounts with the minimum permissions needed, so a compromise has limited reach.

Replacing servers/containers with fresh, known-good images on each deploy instead of patching in place, reducing drift and tampering.

Scanning images for vulnerabilities, using minimal trusted base images, and signing them before deployment.

Preparation; detection & analysis; containment, eradication & recovery; and post-incident (lessons learned).

Mean Time To Detect and Mean Time To Respond/Recover — key operational security metrics to minimize.

Validating patches in a staging environment so a security fix does not break functionality in production.

Full (everything), incremental (changes since any backup — slow restore), differential (changes since last full — faster restore).

Documentation of who handled evidence and when, preserving its integrity for an investigation or legal use.

Using external feeds of attacker tactics and indicators to tune monitoring and prioritize defenses.

Delivering signed, verified updates over a protected channel so attackers cannot push malicious updates.

At end-of-life, securely erasing or destroying data and revoking keys/credentials so nothing is recoverable.

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

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

Software Bill of Materials — a complete inventory of components and dependencies in a piece of software, used to track and respond to risk.

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

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

Risk inherited from libraries your code uses — and from the libraries THOSE use (transitive dependencies).

Security risk from commercial off-the-shelf and externally acquired software that you cannot fully inspect or control.

Security obligations placed on vendors via contracts, SLAs, and audits to ensure their components meet your standards.

Protecting source repositories with access control, branch protection, signed commits, and secret scanning.

An attack where a malicious public package with a private package's name is pulled into a build; mitigated by namespace/scope controls.

Publishing a malicious package with a name close to a popular one, hoping developers install it by mistake.

Ensuring artifacts are built from trusted source by a trusted, tamper-resistant pipeline (e.g., the SLSA framework).

Assessing a supplier's security practices (questionnaires, certifications, SOC 2) before and during reliance on them.

Legal risk from using components under restrictive licenses; tracked alongside vulnerabilities in SCA and the SBOM.

Monitoring advisories, mapping them to your SBOM, and patching or replacing affected components quickly.

Signing and verifying components and releases so each link in the chain can confirm integrity and origin.

NIST guidance on cybersecurity supply chain risk management practices for systems and organizations.

Open source is inspectable but unsupported by a vendor; proprietary is supported but opaque — both need supply-chain controls.

Standardized machine-readable formats (e.g., SPDX, CycloneDX) used to express a software bill of materials.

Classifying suppliers by the risk they pose so the highest-risk vendors get the most scrutiny and controls.

Confirming a component truly originated from its claimed, trusted source before it enters the build.

Automatically re-checking dependencies against new advisories so newly disclosed flaws are caught after release.

Depositing source code with a trusted third party so a customer can recover it if the supplier fails — a supply-chain safeguard.

Pulling components only from vetted, controlled internal/mirror registries to reduce dependency-confusion and typosquatting risk.

Security-reviewing third-party or COTS software before integrating it — penetration test, SCA, and contract terms.

Securing the CI/CD build servers and toolchain so they cannot be used to inject malicious code into artifacts.