ISC2 CSSLP key terms

The three core security goals: confidentiality keeps data secret from unauthorized parties, integrity keeps it accurate and unaltered, and availability keeps it accessible to authorized users when needed.

Giving each user, process, or service only the permissions it truly needs to do its job, and no more, so mistakes or compromise cause limited damage.

Layering multiple independent security controls so that if one fails, others still protect the system; no single control is ever relied upon alone.

A design choice where a system that fails or errors defaults to its safest state, denying access rather than granting it.

Splitting sensitive tasks among different people or components so no single party can complete a harmful action alone, such as both developing and approving a change.

Assurance that a party cannot credibly deny having performed an action, usually achieved with digital signatures and tamper-evident logs.

A weakness in software, configuration, or process that an attacker could exploit to harm the system or its data.

A structured exercise that identifies assets, entry points, threats, and mitigations early in design, often using data-flow diagrams and a scheme such as STRIDE.

The total set of entry points, interfaces, code, and data an attacker can reach and try to exploit; smaller surfaces are generally easier to defend.

A line in a design where data or control passes between components with different privilege or trust levels, and where validation and authentication must occur.

A software development lifecycle that builds security activities such as requirements analysis, design review, code review, testing, and deployment checks into every phase rather than bolting them on at the end.

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

A developer or team member who receives extra security training and acts as the local go-to for secure coding questions, reviews, and raising security concerns.

The process of identifying assets and threats, estimating likelihood and impact, and deciding how to treat each risk: mitigate, transfer, accept, or avoid.

A description of how an actor with hostile intent could misuse a system, used alongside normal use cases to derive security requirements and tests.

A stated, testable need that the software must satisfy to protect confidentiality, integrity, or availability, such as authentication rules, logging obligations, or data retention limits.

Labeling data by sensitivity and value, for example public, internal, confidential, or restricted, so handling, storage, and protection rules can be applied consistently.

A structured review of how a system collects, uses, shares, and retains personal data, identifying privacy risks and required safeguards before build or launch.

Checking that incoming data conforms to the expected type, format, length, and range and rejecting anything else, so malicious or malformed input cannot reach risky code.

Converting data into a safe representation for its destination context, such as HTML, SQL, URL, or script, so characters are treated as data rather than executable instructions.

A database query where the SQL structure is fixed and user values are passed separately as bound parameters, preventing injected input from changing the query's logic.

A memory-safety flaw where a program writes more data than a buffer can hold, overwriting adjacent memory and potentially letting an attacker alter control flow.

Random data added to a value before hashing so identical inputs produce different hashes, defeating precomputed lookup tables and slowing password guessing.

Analyzing source code, bytecode, or binaries without running the program to find coding flaws such as injection patterns or unsafe functions; fast but prone to false positives.

Testing a running application from the outside, often through its interfaces, to find exploitable behavior; it reveals runtime and configuration issues but not the underlying source code.

Feeding large volumes of malformed or random input to a program to trigger crashes, hangs, or memory errors that reveal robustness and security defects.

Authorized simulated attacks against a system, chained like a real adversary, to demonstrate exploitability and measure how effective the deployed controls really are.

A test added after a security bug is fixed so the same flaw cannot silently return in a later build; it becomes part of the repeatable automated test suite.

A systematic examination of source code by other people or by tooling to find defects, unsafe patterns, and policy violations before the code is merged or released.

Reducing a deployed system's exposure by removing unused services, closing unnecessary ports, tightening permissions, and applying secure configuration before it goes live.

A repeatable process for tracking, testing, and applying vendor updates that fix known vulnerabilities, prioritized by severity and completed within risk-based timeframes.

The organized process of preparing for, detecting, containing, eradicating, and recovering from security incidents, plus reviewing what happened to improve for next time.

An approved, documented set of settings for a system that serves as the reference point for deployment, drift detection, and audit.

A machine-readable inventory of the components, libraries, and versions that make up a software product, used to find exposure when a dependency vulnerability is announced.

Evidence about where a component or build came from and how it was produced, supporting verification that artifacts are authentic and have not been tampered with.

Evaluating vendors, libraries, and open-source components for security posture, licensing, maintenance activity, and data-handling practices before adopting them or continuing to rely on them.

An automated build and delivery process with controlled access, isolated runners, signed artifacts, and recorded inputs so releases are reproducible and resistant to tampering.