Vulnerability

slug: vulnerability element_type: TERM mutability: MUTABLE inline: true current_version: 0 status: seed-draft contentURI: null

A vulnerability is a property of an asset, configuration, or process that, if encountered by a threat, may enable harm. Vulnerabilities are properties — not events — and exist whether or not anyone has yet exploited them. Each vulnerability is characterized by: a target asset class, an exploitation pre-condition (what a threat needs to use it), an impact class (what harm follows exploitation), and a remediation pathway (how it can be reduced or eliminated).

Status

Seed-draft, no personal attribution. Authored as part of the Cyber Security Sub-Leviathan opening set (2026-05-16). The framing aligns with common industry definitions (CVE, CVSS) but deliberately avoids endorsing any single scoring system at this level — domain authors choose.

Why this matters

A vulnerability is the bridge between a threat and an asset. Without a precise definition, instances under Cyber Security could not maintain shared vulnerability registries, could not exchange findings, and could not jointly score remediation priorities. This term establishes the bridge.

Reasoning trail

• Property, not event. A vulnerability exists in a system before, during, and after any exploitation attempt. Treating it as an event (only counted when exploited) is the failure mode that creates incident confusion downstream.
• Pre-condition + impact + remediation are mandatory. A "vulnerability" reported without these three is not actionable — it is rumor. The required fields prevent the vulnerability registry from filling with noise.
• No scoring system mandated. CVSS is the industry default but has known critiques. Domain authors may select CVSS, OWASP Risk Rating, or a custom system in rules/vulnerability-scoring.md.

Open questions for domain authors

• Should the federation maintain a canonical vulnerability registry, or should each instance maintain its own with cross-instance reference by hash?
• How are vulnerabilities versioned when remediation changes their state (open → patched → re-opened due to regression)?
• Is "known-unknown" vulnerability (pre-disclosure, embargoed by responsible disclosure) a distinct status from "unknown"? How is it tracked without leaking?
• What is the relationship between a vulnerability and a term:control that mitigates it? One-to-many? Many-to-many?

Related elements

• term:threat — threats exploit vulnerabilities
• term:asset — vulnerabilities are properties of assets
• term:incident — exploitation of a vulnerability produces an incident
• rule:disclose-vulnerabilities-responsibly — embargo + coordination expectations

Awaiting domain author

Vulnerability taxonomy, scoring system selection, and registry architecture are domain-author decisions. See /forum/cyber-security thread for proposal-stage discussion.