Resource · Glossary

Security Testing Glossary

Name: Optimum Web
Address: Calea Iesilor 8, office 3, Chisinau, MD-2069, MD
Telephone: +373 22 843569
Price range: €€
Rating: 4.8

Reviewed: 2 August 2026 — reviewed quarterly

Quick Answer

This glossary defines the terminology used across penetration testing and vulnerability assessment reports — including CVE, CVSS, CWE, IDOR, BOLA, black/grey/white box testing, Rules of Engagement, and OWASP's ASVS, WSTG and Top 10 — in plain, self-contained definitions with links to fuller explainers where one exists.

Asset Inventory: The list of systems, applications, IP ranges and domains an organisation maintains and is responsible for securing. A test's scope is usually drawn from a subset of the asset inventory relevant to the engagement's objective.
Attestation Letter: A short, signed document confirming that testing was performed, by whom, over what scope and dates, without disclosing technical findings — used to satisfy auditors and vendor questionnaires without sharing a full technical report. Full explainer →
Authenticated Testing: Testing performed with valid credentials for the application or system, allowing the tester to assess what a logged-in user (at one or more privilege levels) can access, rather than only what's visible to an anonymous visitor.
Black Box Testing: Testing performed with no internal knowledge of the target system — no source code, architecture diagrams or credentials — simulating what an external attacker with no inside information could discover and exploit.
BOLA (Broken Object Level Authorization): A vulnerability class, common in APIs, where a user can access or modify another user's data by changing an identifier in a request (e.g. an order ID) without the system checking that the requester actually owns that object.
Business Logic Flaw: A vulnerability arising from how an application's specific workflow is designed, rather than a generic technical bug — for example, being able to apply a discount code multiple times. These require manual testing tailored to the application; automated scanners generally can't find them.
CVE (Common Vulnerabilities and Exposures): A public, unique identifier assigned to a specific known vulnerability in a product or library, maintained by MITRE. CVE IDs let vendors, researchers and tools refer to the same vulnerability consistently across reports and advisories.
CVSS v3.1 (Common Vulnerability Scoring System): A standardised scoring framework producing a 0–10 severity score for a vulnerability, based on factors like attack complexity, required privileges and impact. Version 3.1 is the most widely used revision in current vendor and scanner tooling.
CWE (Common Weakness Enumeration): A classification system for types of software weaknesses (e.g. "improper input validation"), maintained by MITRE. CVEs are typically mapped to one or more CWEs, allowing vulnerabilities to be grouped by underlying root cause rather than by individual instance.
DAST (Dynamic Application Security Testing): Automated testing performed against a running application, sending requests and observing responses to find vulnerabilities — without access to the underlying source code. Commonly used for web applications and APIs as part of continuous scanning.
Exploit: A piece of code, technique or sequence of actions that takes advantage of a vulnerability to achieve an unauthorised outcome, such as accessing data or executing commands. Confirming a vulnerability is exploitable — not just theoretically present — is a key part of manual validation.
False Positive: A finding reported by an automated tool that isn't actually exploitable or valid in the specific environment tested — for example, a scanner flagging an outdated library version that has been patched via a backport. Manual validation exists largely to filter these out.
Findings Register: A tracked list of vulnerabilities identified during testing, showing when each was found, its severity, and its remediation status over time — used as evidence that a testing programme addresses issues, not just discovers them, across multiple cycles.
Grey Box Testing: Testing performed with partial knowledge of the target — typically standard user credentials and some documentation, but not full source-code access. It balances realism (testing as an outsider with a foothold) against the efficiency of internal knowledge.
IDOR (Insecure Direct Object Reference): A vulnerability where an application exposes a direct reference to an internal object (like a database record ID) and fails to verify the requester is authorised to access it — a common cause of one user viewing or modifying another's data.
OWASP ASVS (Application Security Verification Standard): A detailed, verifiable checklist of application security requirements published by OWASP, organised into three increasing levels of rigour. Used by testers as a methodology reference and by organisations to define what "secure" means for their own applications.
OWASP Top 10: OWASP's periodically updated list of the most critical web application security risk categories, based on contributed testing data and a community survey. It's an awareness and prioritisation list, not a full testing methodology. What changed in the 2025 edition →
OWASP WSTG (Web Security Testing Guide): A detailed, step-by-step methodology for testing web applications, published by OWASP. Testers commonly reference WSTG test cases to structure engagements and ensure consistent coverage of a target's attack surface.
Patch Management: The organisational process of tracking, prioritising and applying security updates to software and systems. Weak patch management is one of the most common root causes behind findings in both vulnerability scanning and penetration testing.
Penetration Test: A manual, authorised attempt to exploit vulnerabilities in a system, going beyond identification to demonstrate real-world impact — for example, chaining findings together to access data or systems that shouldn't be reachable. More thorough and more expensive than a vulnerability assessment.
Proof of Concept (PoC): Evidence — a request, script, screenshot or short recording — demonstrating that a reported vulnerability is genuinely exploitable, rather than theoretical. A well-formed PoC lets a development team reproduce and confirm a fix without needing to re-run the full test.
Red Team: An engagement simulating a realistic, often stealthy adversary across multiple attack vectors (technical, physical, social) with a broad objective, rather than testing every vulnerability in a defined scope. Contrasted with a penetration test, which is narrower and typically not attempting to stay undetected.
Remediation Retest: A follow-up test, usually scoped only to previously reported findings, confirming that fixes actually resolve the underlying vulnerability rather than only masking its symptoms. Often included as a standard part of a penetration testing or vulnerability assessment engagement.
Risk Acceptance: A documented decision by someone with appropriate authority to knowingly leave a finding unremediated, typically because the cost or effort of fixing it outweighs the assessed risk. Auditors generally expect risk acceptances to be explicit and time-bound, not silent inaction.
Rules of Engagement (RoE): The signed document authorising a penetration test before it starts, defining scope, testing window, permitted techniques and emergency contacts. It's what distinguishes authorised testing from unauthorised access. Full explainer →
SAST (Static Application Security Testing): Automated testing performed against an application's source code, bytecode or binaries without executing it, looking for known-insecure coding patterns. Complements DAST, which tests a running application from the outside.
Scope: The precise set of systems, applications, IP ranges and techniques a testing engagement is authorised to cover, defined in the Rules of Engagement before testing starts. Anything outside the stated scope is, by definition, not covered by the test's findings or its authorisation.
Severity Rating: A classification (commonly Critical, High, Medium, Low, Informational) assigned to each finding based on its potential impact and exploitability, often derived from a CVSS score. Used to prioritise which findings need urgent remediation versus longer-term tracking.
Social Engineering: Testing techniques that target people rather than systems directly — phishing emails, phone-based pretexting, or physical tailgating — assessing whether staff can be manipulated into bypassing technical controls. Typically an explicitly opt-in scope item, not included by default.
Threat Model: A structured analysis of who might attack a system, what they'd want, and how they could realistically get it, used to prioritise which risks matter most for a specific application before or alongside testing. Improved threat modelling practice is cited as a factor in some OWASP Top 10 category shifts.
Vulnerability Assessment: Automated vulnerability discovery combined with manual validation of high-severity findings, producing a dated report without attempting to exploit findings as deeply as a full penetration test. A cost-effective, common form of recurring compliance evidence. Service details →
Vulnerability Scanning: Fully automated checking of assets against known vulnerability signatures (CVEs, misconfigurations), often run on a recurring schedule with no manual review of results. Faster and cheaper than manual assessment, at the cost of a higher false-positive rate. vs one-off assessment →
White Box Testing: Testing performed with full access to source code, architecture documentation and credentials, allowing the most thorough possible review — at the cost of being less representative of what an external attacker without that access could actually discover.
Zero-Day: A vulnerability that is exploited or disclosed before the vendor has had any opportunity to release a fix — the "zero days" referring to the time the vendor has had to respond. Distinct from an unpatched but already-known and disclosed vulnerability.