Glossary

Definitions here are written for precision, not completeness — each entry says what the term means and, where useful, why it matters to the decisions covered elsewhere on this site. Terms are grouped by domain; use your browser's find function for a specific one.

#Application security testing

AppSec — Application security: the practice and tooling for finding and fixing vulnerabilities in software you build or ship, as distinct from network or endpoint security. The core battleground for AI code security companies.

SAST (Static Application Security Testing) — Analyzes source code without running it, looking for known-insecure patterns and dataflow. Semgrep, CodeQL, and Snyk's DeepCode AI are SAST engines; see AI code security companies.

DAST (Dynamic Application Security Testing) — Tests a running application from the outside, sending real requests to find exploitable behavior. The category XBOW, Pentera, and Horizon3.ai operate in; see Offensive AI security companies.

SCA (Software Composition Analysis) — Scans a project's third-party dependencies for known vulnerabilities. Socket and Endor Labs are SCA-first vendors pivoting toward AI-generated-code risk; see AI code security companies.

IAST (Interactive Application Security Testing) — Instruments a running application to observe real dataflow during actual use, combining SAST's code awareness with DAST's runtime accuracy; less prominent in the AI-native vendors covered on this site than SAST/DAST/SCA.

SBOM (Software Bill of Materials) — A machine-readable manifest of a product's components and dependencies. The EU Cyber Resilience Act makes maintaining a continuous SBOM a legal obligation (Article 13), which is the clearest EU forcing function for automated AppSec tooling demand.

SARIF (Static Analysis Results Interchange Format) — A standard JSON schema for static-analysis tool output, letting scanners, CI systems, and dashboards interoperate. Used across the AIxCC finalist systems' reporting pipelines; see AIxCC: the closest thing to a proof.

#Vulnerability identification and scoring

CWE (Common Weakness Enumeration) — MITRE's taxonomy of vulnerability classes (e.g., "CWE-79: Cross-Site Scripting"), as opposed to specific instances. Used throughout Cyber benchmarks and evals to scope what a given eval actually tests.

CVE (Common Vulnerabilities and Exposures) — The canonical identifier for a specific, disclosed vulnerability instance, run by MITRE under a CISA contract. The program nearly lost funding in April 2025 and was saved by an emergency 11-month extension; see What AI is actually doing to the threat landscape.

CVSS (Common Vulnerability Scoring System) — A 0–10 severity score for a vulnerability based on exploitability and impact metrics. Widely used but a poor proxy for real-world exploitation likelihood, which is why EPSS and KEV exist alongside it.

EPSS (Exploit Prediction Scoring System) — A probabilistic score estimating the likelihood a vulnerability will actually be exploited in the wild within the next 30 days, meant to complement CVSS's static severity rating with a dynamic, data-driven signal.

KEV (Known Exploited Vulnerabilities catalog) — CISA's list of vulnerabilities confirmed to be under active exploitation, used as a mandatory patch-priority list for US federal agencies. See What AI is actually doing to the threat landscape for how fast new KEV entries follow disclosure.

#CTF and low-level offense

CTF (Capture the Flag) — A competitive-hacking format where challenges are solved for a "flag" string proving success, split into standard categories. The dominant early format for AI-cyber benchmarks like Cybench and NYU CTF Bench; see Cyber benchmarks and evals.

pwn — The CTF category testing binary/memory-corruption exploitation (buffer overflows, use-after-free, etc.) to gain code execution on a target binary.

rev — Reverse engineering: the CTF category and general discipline of understanding a compiled binary's behavior without source code, often to find a flag or a vulnerability.

crypto — The CTF category testing cryptographic implementation flaws or classical cryptanalysis, distinct from applied cryptography engineering.

Fuzzing — Automatically generating large volumes of malformed or random input to a program to trigger crashes, which often reveal exploitable bugs. The backbone of OSS-Fuzz and every top AIxCC finalist's architecture; see AIxCC: the closest thing to a proof and The open-source stack.

Coverage-guided fuzzing — Fuzzing that uses code-coverage feedback to steer input generation toward unexplored paths (AFL, libFuzzer, LibAFL are implementations), dramatically more effective than blind random fuzzing and now commonly paired with LLM-generated seeds.

Sanitizers (ASAN/MSAN/UBSAN) — Compile-time instrumentation that turns otherwise-silent memory errors into hard crashes: AddressSanitizer (ASAN) for out-of-bounds/use-after-free, MemorySanitizer (MSAN) for uninitialized reads, UndefinedBehaviorSanitizer (UBSAN) for undefined-behavior triggers. A clean sanitizer-crash signature is one of the few genuinely hard-to-game reward signals available for post-training a security agent; see Post-training playbook.

PoV / PoC (Proof of Vulnerability / Proof of Concept) — A minimal input or script that demonstrably triggers a vulnerability, used as the standard unit of "we actually found this, not just guessed it" across AIxCC: the closest thing to a proof and Cyber benchmarks and evals.

Taint analysis — Static or dynamic tracking of how untrusted input ("tainted" data) flows through a program to a dangerous operation ("sink"), the core technique behind tools like Vulnhuntr and IRIS; see The open-source stack.

Reachability — Whether a known-vulnerable code path can actually be triggered by real, attacker-controlled input in a given deployment, as opposed to existing in dead or unreachable code. The central question that separates "this dependency has a CVE" from "this CVE actually matters to you" — and the hardest part of triage to automate reliably.

Exploitability — Whether a vulnerability can actually be weaponized into a working exploit, as distinct from merely being a confirmed bug; AIxCC's own results show discovery and exploitability-proof are often decoupled — see AIxCC: the closest thing to a proof.

CRS (Cyber Reasoning System) — DARPA's term of art for a fully autonomous system that finds and patches vulnerabilities without a human in the loop, the object every AIxCC team built; see AIxCC: the closest thing to a proof.

#Security operations and threat intelligence

Red team — The offensive side of a security exercise, simulating a real attacker against an organization's defenses under authorization.

Blue team — The defensive side, detecting and responding to the red team's simulated attack (or a real one).

Purple team — A collaborative exercise where red and blue teams work together in real time to improve detection, rather than a blind adversarial test.

SOC (Security Operations Center) — The team and function responsible for continuous monitoring, triage, and response to security alerts; the buyer at the center of AI SOC and detection companies.

SIEM (Security Information and Event Management) — A platform that aggregates and correlates log/event data across an organization for detection and investigation (Splunk, Microsoft Sentinel are examples); the data layer most AI-SOC startups sit on top of.

SOAR (Security Orchestration, Automation and Response) — Tooling that automates the response workflow once an alert fires (ticket creation, containment actions, playbook execution); Tines and Torq are repositioning SOAR products around agentic AI, see AI SOC and detection companies.

EDR (Endpoint Detection and Response) — Agent-based monitoring and response on individual devices (laptops, servers), the CrowdStrike/SentinelOne core product category.

XDR (Extended Detection and Response) — EDR's data scope extended across endpoint, network, cloud, and identity telemetry into one correlated detection surface.

MDR (Managed Detection and Response) — A fully outsourced SOC-as-a-service, where a third party monitors and responds on the customer's behalf rather than the customer running its own SOC.

MSSP (Managed Security Service Provider) — A broader outsourced-security category than MDR, covering ongoing management of security infrastructure (firewalls, SIEM tuning) as well as monitoring.

TTPs (Tactics, Techniques, and Procedures) — The standard vocabulary for describing attacker behavior at increasing specificity, from broad tactic (e.g., "initial access") to specific procedure. Structured most commonly via MITRE ATT&CK.

MITRE ATT&CK — The industry-standard, publicly maintained knowledge base of adversary tactics and techniques observed in real intrusions, used as the common taxonomy across nearly every threat-intel and SOC-benchmark tool in Cyber benchmarks and evals and AI SOC and detection companies.

Threat intel / CTI (Cyber Threat Intelligence) — The discipline of collecting and analyzing information about active or emerging threats (actors, malware, campaigns) to inform defense; CyberSOCEval and CTIBench are the leading LLM benchmarks for this specifically, see Cyber benchmarks and evals.

Responsible disclosure — The practice of privately notifying a vendor of a vulnerability and giving them a defined window to patch before public disclosure, the norm underlying every AIxCC real-world find and most academic vulnerability-discovery research; see AIxCC: the closest thing to a proof.

Bug bounty — A program paying independent researchers for validated vulnerability reports, run by platforms like HackerOne and Bugcrowd; the category now visibly strained by AI-generated "slop" submissions, see What AI is actually doing to the threat landscape and Offensive AI security companies.

#AI safety and governance frameworks

RSP (Responsible Scaling Policy) — Anthropic's internal framework tying model capability thresholds to required safeguards before deployment; see What the frontier labs do themselves and Is frontier-lab gating a real wedge?.

ASL (AI Safety Level) — The specific tiered scale (ASL-2, ASL-3, etc.) inside Anthropic's RSP, each level requiring stronger deployment and security safeguards as capability rises.

Preparedness Framework — OpenAI's equivalent capability-gating framework, currently on version "PFv2," defining High and Critical risk categories across domains including cybersecurity; see What the frontier labs do themselves.

Frontier Safety Framework (FSF) — Google DeepMind's equivalent framework, defining Critical Capability Levels (CCLs) including a consolidated cyber-uplift CCL that Gemini 3 Pro is reported to have reached the "alert threshold" for without crossing; see What the frontier labs do themselves.

CCL (Critical Capability Level) — The specific threshold inside Google's FSF at which a model's capability in a domain is judged to require materially stronger security and deployment controls.

Systemic-risk GPAI — The EU AI Act's classification for general-purpose AI models presumed to carry systemic risk, triggered by a rebuttable presumption at 10^25 FLOPs of training compute or by discretionary Commission designation; systemic-risk status is not waived by open-weighting the model. See EU regulation as a demand engine.

#Model training and agents

SFT (Supervised Fine-Tuning) — Training a model on labeled input-output examples to shape its behavior, the standard first post-training step before any reinforcement-learning stage; see Post-training playbook.

RLHF (Reinforcement Learning from Human Feedback) — Post-training a model using a reward signal derived from human preference judgments, the technique that produced the first generation of aligned chat models.

RLVR (Reinforcement Learning from Verifiable Rewards) — Post-training using an automated, checkable reward (does the code compile, does the patch pass tests, does the exploit crash the target) rather than a human judgment — the dominant paradigm for training agentic coding and security models today, and the technique whose defensive-security verifier design remains largely unsolved; see Post-training playbook.

GRPO (Group Relative Policy Optimization) — A reinforcement-learning algorithm that scores a batch of sampled responses against each other rather than against a separately trained value model, widely used across the RLVR post-training stack referenced in Post-training playbook.

Rollout — One full episode of an agent interacting with its environment during reinforcement learning (a complete multi-step task attempt), the basic unit of both training cost and evaluation in agentic RL.

Verifier — The automated component that checks whether a rollout succeeded and assigns reward accordingly; verifier design quality is the single biggest lever on whether RLVR training produces a genuinely capable model or a reward-hacked one, see Post-training playbook.

Reward hacking — When a model learns to maximize its reward signal in a way that technically satisfies the verifier without accomplishing the intended task (e.g., triggering an irrelevant crash instead of the target vulnerability class); the central risk any RLVR verifier design must defend against, see Post-training playbook.

Distillation — Training a smaller model to imitate a larger one's outputs, historically the cheapest way to bootstrap capability; now legally constrained for security-model builders whose target model competes with the frontier lab whose outputs they'd want to distill from, per the labs' own usage terms — see Post-training playbook.

Scaffold / agent harness — The surrounding code (tool definitions, prompting strategy, retry logic, sandboxing) that turns a base model into a working agent; benchmark results vary more by scaffold than by underlying model in controlled comparisons (CAIBench found up to 2.6x variance from scaffold alone), making harness quality often the higher-leverage investment than model choice. See Post-training playbook and The open-source stack.

MCP (Model Context Protocol) — An open protocol for connecting an AI model to external tools and data sources in a standardized way; widely adopted as the connective layer for security-tool wrappers (HexStrike-AI exposes 150+ tools via MCP) and, correspondingly, a new attack surface of its own (see prompt injection, below). See The open-source stack and How these systems are actually built.

Prompt injection — An attack that smuggles instructions to an AI agent inside content the agent processes (a file, a web page, a log line) rather than through its intended input channel, tricking it into unauthorized action. Behind real 2026 production incidents including an agent that autonomously rewrote DNS records after reading a poisoned log entry; see What AI is actually doing to the threat landscape.

Air-gapped — A deployment with no network connection to the outside internet, the strongest available isolation guarantee and a common requirement for critical-infrastructure and government buyers of AI security tooling; see Who buys, and what they pay.

BYOK (Bring Your Own [LLM API] Key) — An enterprise deployment option letting a customer route a vendor's AI features through the customer's own LLM provider account, keeping code and data off the vendor's infrastructure — a direct response to enterprise concern about source code reaching a third-party model provider; see Who buys, and what they pay.

#Go-to-market

ACV (Annual Contract Value) — The yearly value of a customer contract, the standard unit for comparing deal sizes across the vendors profiled in Who buys, and what they pay.

PLG (Product-Led Growth) — A go-to-market motion where the product itself (often via a free tier) drives adoption and expansion with minimal sales-team involvement before converting to paid; Snyk's and Semgrep's open-source-to-paid funnels are the canonical examples in this market, see Go to market.

Design partner — An early customer who works closely with a vendor to shape a still-forming product, typically in exchange for early or discounted access rather than as a fully repeatable sales motion; the standard seed-stage traction metric in this category is 2–4 named design partners, see Who funds this and at what price.

#EU regulation

CRA (Cyber Resilience Act, Regulation (EU) 2024/2847) — The EU's horizontal cybersecurity regulation for any "product with digital elements," mandating SBOM maintenance, vulnerability handling, and incident reporting on an hours-to-days clock from 11 September 2026, with full application from 11 December 2027. See EU regulation as a demand engine.

NIS2 (Directive (EU) 2022/2555) — The EU directive requiring risk-management measures and incident reporting across 18 sectors, with personal management liability for non-compliance; Germany transposed it into national law via the NIS2UmsuCG. See EU regulation as a demand engine and Germany: §202c and the Berlin question.

DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554) — In application since 17 January 2025, mandates recurring threat-led penetration testing (TLPT) for major EU financial entities and directly regulates their ICT third-party providers. See EU regulation as a demand engine.

AI Act (Regulation (EU) 2024/1689) — The EU's general AI regulation; GPAI and systemic-risk obligations have been binding since 2 August 2025, while high-risk-system deadlines were pushed to December 2027/August 2028 by the 2026 "Digital Omnibus" simplification. See EU regulation as a demand engine.

EUCC (European Common Criteria-based cybersecurity certification scheme) — The first voluntary EU-wide product security certification scheme adopted under the Cybersecurity Act, relevant to any vendor shipping a certifiable hardware or embedded software component.

ENISA (European Union Agency for Cybersecurity) — The EU's cybersecurity agency, operating the CRA's central incident-reporting platform, coordinating CSIRTs, and running the EU's own vulnerability database (EUVD) as a hedge against dependence on the US-run CVE program. See EU regulation as a demand engine.

BSI (Bundesamt für Sicherheit in der Informationstechnik) — Germany's federal cybersecurity authority, both regulator and a plausible procurement partner, and — as of this research — the operative German government interlocutor on AI-cyber capability in the absence of a dedicated national AI safety institute. See Germany: §202c and the Berlin question.

§202c StGB — The German "Hackerparagraf," criminalizing the production or distribution of software or credentials whose purpose is unauthorized data access, unreformed as of August 2026 despite a coalition-agreement commitment to add a good-faith security-research safe harbor. The central legal landmine for any Berlin-based offense-adjacent product. See Germany: §202c and the Berlin question.

#US regulation and institutions

CISA (Cybersecurity and Infrastructure Security Agency) — The US agency running the CVE Program contract, the KEV catalog, and the Secure by Design pledge; under the Department of War (the 2025 rename of the Department of Defense) suspended CMMC Phase II enforcement in July 2026. See The US picture.

CMMC (Cybersecurity Maturity Model Certification) — The US defense-industrial-base contractor security-certification program; its Phase II third-party-assessment requirement was suspended in July 2026, materially softening the near-term US compliance-driven demand picture relative to the EU. See The US picture.

FedRAMP — The US government's cloud-service security authorization program, historically a 12–18-month process now being modernized under "FedRAMP 20x" toward continuous, automated evidence rather than static point-in-time review.

CFAA (Computer Fraud and Abuse Act, 18 U.S.C. § 1030) — The primary US federal statute criminalizing unauthorized computer access, narrowed by Van Buren v. United States (2021) to a "gates-up-or-down" test — but leaving unresolved whether an autonomous agent that drifts outside an authorized scope creates the same liability a human operator would face. See The US picture.

DMCA 1201 — The US copyright law provision that, unlike Germany's §202c, provides a codified (if narrow) safe harbor for good-faith security research under 17 U.S.C. §1201(j) and the periodically renewed triennial rulemaking exemption. See The US picture.

AIxCC (DARPA AI Cyber Challenge) — A two-year, $29.5M-prize-pool DARPA competition (finals at DEF CON 33, August 2025) that produced seven open-sourced autonomous cyber reasoning systems; the field's clearest public proof that AI-driven vulnerability discovery-and-patching works on real, large codebases. See AIxCC: the closest thing to a proof.

AISI / CAISI — National AI-safety-testing institutes: the UK's AI Security Institute (AISI), the most active and best-documented third-party cyber-capability evaluator cited in frontier-lab system cards, and the US Center for AI Standards and Innovation (CAISI, housed at NIST), which runs comparative capability assessments under a narrower and more politically contingent public mandate. See What the frontier labs do themselves and Is frontier-lab gating a real wedge?.

#What this means for us

• Use this glossary as the shared vocabulary for any pitch, memo, or diligence document coming out of this research — precision here is what lets a technical reader trust the rest of the site.
• The RLVR/verifier/reward-hacking cluster is the terminology to master before evaluating any "we post-train our own model" claim from a competitor — most such claims in Offensive AI security companies don't specify verifier design at all, which is itself a red flag.
• The EU-regulation cluster (CRA, NIS2, DORA, AI Act) is the terminology a German go-to-market motion needs fluent by default; the US cluster (CFAA, CMMC, DMCA 1201) matters more for corporate-structure and IP-location decisions than for near-term sales.
• §202c StGB is the one term on this page with a live, unresolved legal question attached to it — treat it as a standing action item, not settled background, per Open questions and the research backlog.