Glossary: Pentesting, Security, Privacy and CTF/Bug Bounty¶

Security has a dense vocabulary. This glossary covers the 15 most important terms in this topic. For more terms, see [[shared/glossary]].

Terms¶

Attack Surface¶

The total sum of the different points (the "attack surface") where an unauthorized user can try to enter data to or extract data from an environment. The larger the attack surface, the higher the risk. Attack surface reduction — disabling unused services, closing unused ports, removing unnecessary features — is one of the most effective defensive strategies. A web application's attack surface includes every URL, parameter, file upload, API endpoint, and authentication mechanism.

Bug Bounty¶

A reward program offered by organizations to security researchers who discover and responsibly disclose vulnerabilities in their systems. Payouts range from a few hundred dollars (for low- severity findings) to over $1,000,000 (for critical vulnerabilities like remote code execution on major platforms). Major platforms hosting bug bounty programs include HackerOne, Bugcrowd, and Intigriti. The defining characteristic is scope: the program defines exactly which assets are in-scope for testing. Testing out-of-scope assets is unauthorized.

CTF (Capture The Flag)¶

A type of cybersecurity competition in which participants solve security puzzles to find hidden strings called "flags" (usually in the format flag{...} or CTF{...}). Categories include web exploitation, binary exploitation (pwn), cryptography, forensics, reverse engineering, and steganography. CTFs are legal, structured environments for practicing offensive security skills. Major competitions include DEF CON CTF, Google CTF, and picoCTF.

CVSS (Common Vulnerability Scoring System)¶

A standardized framework for rating the severity of security vulnerabilities on a scale of 0.0 to 10.0. The score is computed from a vector string that captures characteristics including: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction required, scope, and the impact on confidentiality, integrity, and availability. A CVSS score of 9.0+ is "Critical"; 7.0–8.9 is "High"; 4.0–6.9 is "Medium"; 0.1–3.9 is "Low". See https://www.first.org/cvss/ for the calculator.

CVE (Common Vulnerabilities and Exposures)¶

A list of publicly disclosed cybersecurity vulnerabilities, each assigned a unique identifier in the format CVE-YYYY-NNNNN (e.g., CVE-2021-44228 for Log4Shell). Maintained by MITRE and funded by the US government. When a researcher discovers a vulnerability, they typically request a CVE ID through a CVE Numbering Authority (CNA) before disclosure. The CVE system provides a common language for discussing specific vulnerabilities across tools, databases, and organizations.

OWASP (Open Web Application Security Project)¶

A non-profit foundation that produces freely available materials on web application security. Most famous for the OWASP Top 10 — a list of the 10 most critical web application security risks, updated approximately every 3–4 years based on real-world data. The OWASP Testing Guide is the industry standard methodology for web application penetration testing.

Penetration Testing¶

A simulated cyberattack against a computer system, network, or web application, performed with explicit written authorization from the system owner, for the purpose of identifying exploitable vulnerabilities before malicious actors do. A penetration test follows a defined scope (which systems can be tested), rules of engagement (what techniques are allowed), and concludes with a detailed report of findings, evidence, and remediation recommendations.

Proof of Concept (PoC)¶

A demonstration that a vulnerability is exploitable, typically in the form of code, a URL, or a step-by-step reproduction procedure. In bug bounty and responsible disclosure contexts, a PoC proves to the vendor that the vulnerability is real and reproducible. A good PoC is minimal, controlled, and causes no actual damage — it demonstrates impact without exploiting it beyond what is necessary to prove the vulnerability exists.

Purple Team¶

A security team model that combines red team (offensive) and blue team (defensive) capabilities in a collaborative framework. Rather than the traditional adversarial red-vs-blue model, a purple team has red and blue working together: the red team attacks, and the blue team immediately analyzes the attack, improves detections, and validates that defenses work. This dramatically accelerates the security improvement cycle.

Red Team¶

The offensive security team in an organization's security program. A red team simulates real-world adversaries — using the same tactics, techniques, and procedures (TTPs) as actual threat actors — to test whether an organization's defenses, detection capabilities, and incident response processes work. Unlike a penetration test (which has a defined scope), a red team engagement often has a broad objective ("gain access to the Crown Jewels") and tests the entire security program.

Blue Team¶

The defensive security team that monitors, detects, and responds to security threats. Blue team activities include security operations center (SOC) work, incident response, log analysis, threat hunting, and implementing defensive controls. The blue team's goal is to detect and contain attacks as quickly as possible. Tools include SIEM systems (Splunk, Elastic SIEM), EDR platforms, and network monitoring tools.

Responsible Disclosure¶

The practice of reporting a discovered vulnerability to the affected vendor privately and giving them a reasonable time to develop and release a fix before publicly disclosing the vulnerability details. The standard coordination window is 90 days (established by Google Project Zero). After 90 days, the researcher may publish regardless of whether the vendor has patched — this creates incentive for vendors to act promptly. Responsible disclosure balances the researcher's right to publish with the public's interest in having systems protected before attackers learn of the flaw.

Scope¶

In security testing, the scope defines exactly which assets, systems, IP ranges, domains, and features are authorized for testing. Testing anything outside the defined scope — even accidentally — is unauthorized and potentially illegal. In a bug bounty program, the scope is published in the program's policy page. In a penetration test engagement, the scope is defined in the Statement of Work and Rules of Engagement document. Always verify scope before testing anything.

Threat Modeling¶

A structured process for identifying, quantifying, and addressing security risks in a system. The most common framework is STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Threat modeling is typically done during design — it asks: "What could go wrong? What are the assets? Who are the adversaries? What are the entry points?" The output is a prioritized list of threats and corresponding mitigations.

Zero-Day¶

A vulnerability that is unknown to the vendor and for which no patch exists. The term "zero-day" refers to the fact that the vendor has had zero days to fix it. Zero-days are extremely valuable to both attackers and defenders: nation-states stockpile them for offensive operations, and security researchers race to find and report them before malicious actors exploit them. Once a zero-day is reported to the vendor and a patch is released, it becomes a known vulnerability (typically receiving a CVE ID).