ISTQB CT-SEC flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Risk-based security test planning

Planning that allocates security test effort in proportion to each asset's risk, computed from potential impact and likelihood of attack, rather than to code size or convenience.

Threat modelling as test basis

Systematic identification of threats against assets and interfaces, whose output becomes the set of negative test conditions the security test plan must cover or explicitly exclude.

Security entry criteria

Preconditions before security test execution: stable build, documented configuration baseline, accounts with defined privileges, and monitoring enabled so attacks can be observed and evidenced.

Measurable security exit criteria

Quantified conditions for ending security testing, such as zero open critical findings, agreed remediation dates for high findings, and demonstrated coverage of the threat list.

Test environment isolation

Running attack simulations in a production-like but separate environment with synthetic or masked data, avoiding legal exposure and damage to live services and real personal data.

Whole-lifecycle security testing

Treating security testing as continuous across requirements, design, implementation, deployment and operations, each phase having distinct objectives rather than a single pre-release penetration test.

Retest and fix verification

A finding is closed only after the remediation is re-executed against the original reproduction steps and a regression check confirms the fix introduced no new exposure.

Test level security focus

Component tests target input validation and memory safety; integration tests target authentication and interface hardening; system tests target attack resistance; acceptance tests target compliance and operations.

Vulnerability scanning characteristics

Automated signature-based detection with broad coverage and low cost per run, but high false-positive rates and no understanding of business logic or chained exploitation.

Penetration testing characteristics

Manual, goal-directed exploitation that chains weaknesses and finds logic flaws scanners miss, but is sample-limited, non-repeatable and dependent on tester skill.

SAST versus DAST

Static analysis inspects source or bytecode without executing the system; dynamic analysis attacks the running system without source access. They detect different defect classes and complement each other.

Fuzz testing effectiveness metric

Fuzzing is judged by interface or code coverage achieved and time to first crash, not by the raw number of malformed inputs submitted to the target.

Security regression suite origin

The regression suite for security is built from previously confirmed findings, each retained as an executable exploit case and re-run after every relevant change.

Reconnaissance before exploitation

Enumeration and fingerprinting of hosts, services and versions precede targeted attacks; their output selects which exploits are attempted and in what order.

Resilience under hostile load

Testing that combines normal load with attack traffic to observe degradation, failover and whether rate limiting engages before resources are exhausted.

Finding evidence package

The recorded reproduction steps, request and response or log excerpt, affected component, severity justification and environment, sufficient for another tester to retest the issue.

IAST correlation advantage

Instrumenting the running application links runtime observations to code locations, cutting false positives compared with standalone static or dynamic analysis.

High-risk coverage test

An evaluation question asking whether the highest-ranked risks each have executed tests with evidence; strong results on low-risk areas cannot compensate for an untested critical asset.

Security requirements traceability

Each security requirement maps to at least one designed test case and a recorded result, so evaluation can show coverage rather than assume it from test volume.

Vulnerability clustering signal

Concentration of findings in one component indicates a design or architectural weakness in that area, which warrants deeper testing rather than treating findings as isolated incidents.

Severity from exploitability and impact

A finding's severity combines how easily it can be exploited with the damage if exploited; remote, unauthenticated, high-impact flaws outrank local flaws needing physical access.

Category-based coverage check

Evaluating security tests by whether each weakness category, such as injection or broken access control, was exercised, instead of counting how many tests were run.

Social engineering simulation

Controlled, consented phishing or pretext exercises that measure human susceptibility; results inform training and process change and must not be used to punish individuals.

Security control usability

A control that users routinely bypass because it is burdensome has failed its objective, so usability of the control is itself a legitimate test target.

Confirmed versus unverified findings

Tool output is a lead until reproduced; evaluation must separate verified defects from scanner noise, because inflating counts distorts the risk picture and erodes trust.

Residual risk reporting

Explicitly stating the risk remaining after testing to the risk owner, since testing reduces uncertainty but never removes risk; sign-off is acceptance of that remainder.

Tool category selection

Matching scanner, fuzzer, proxy, network scanner, vulnerability manager or log-analysis tool to the technology stack and the specific test objective being pursued.

Interception proxy test purpose

A proxy between client and server lets the tester alter requests, proving whether the server validates input independently of client-side checks that can be bypassed.

ISO/IEC 25010 security view

The quality model treats security as comprising confidentiality, integrity, non-repudiation, accountability and authenticity, giving structured sub-characteristics to derive test objectives from.

Authorization and scope constraint

Security testing is performed only within written permission and defined scope, respecting data-protection law, with findings reported confidentially through the agreed channel.

Tool signature currency

Rule sets and vulnerability signatures must be maintained; stale signatures silently reduce detection and create false confidence in a clean scan report.

Automation limits in security testing

Tools cannot judge business-logic abuse or authorization intent, so their output is an input to human test design rather than a replacement for it.