Vulnerability

Origin & evolution

For most of computing's history, vulnerabilities had no shared names. The same flaw might be called three different things by three vendors, so defenders could not tell whether two advisories described one problem or two. MITRE's David Mann and Steven Christey proposed a fix in a 1999 white paper at Purdue University, and the Common Vulnerabilities and Exposures list launched publicly that September with 321 entries. A CVE identifier gives each publicly known flaw one canonical name, which is the quiet infrastructure behind every patch advisory you have ever read.

Naming was the first layer; scoring and classification followed. The Common Vulnerability Scoring System (CVSS), with v2 arriving in 2007 under FIRST's stewardship, rates severity on a 0 to 10 scale from attack vector, complexity, and impact. The Common Weakness Enumeration (CWE) sits one level up, cataloguing the types of flaw (SQL injection, buffer overflow, improper authentication) so that a specific CVE can be tagged with the class of mistake that produced it.

Disclosure was the harder, more political evolution. In 2000 the researcher known as Rain Forest Puppy published the RFPolicy, which gave vendors a private window to fix a flaw before the researcher reserved the right to publish anyway. Vendors preferred coordinated disclosure, which asks researchers to wait until a fix ships. The tension between those two stances, full versus coordinated, still defines disclosure ethics today.

How it works in practice

A penetration test🗡️Penetration TestSecurityA penetration testView reference → of a billing service finds that a user ID in a URL can be changed to read another customer's invoices💳InvoiceSales & RevenueAn invoice for billingView reference →: an insecure direct object reference, classed as CWE-639. The finding scores CVSS 8.1, high, because it needs🫀NeedUserA user need, pain, desire, or constraintView reference → only a logged-in account and exposes other customers' data. The team opens an internal ticket the moment the report lands and starts the patch window clock.

The fix is a one-line authorisation check, but the rollout takes nine days because the affected endpoint is shared by a mobile client that needs a coordinated release🚢ReleaseProduct SpecificationA shipped version of the productView reference →. During those nine days the vulnerability is real, scored, and known, and the team adds rate-limiting as a stopgap so any exploitation attempt is throttled and logged. Once the patch ships, the weakness closes; the CWE class stays in the team's regression tests♻️Regression TestQuality AssuranceA regression testView reference → so the same shape of mistake gets caught next time.

Vulnerability vs. its neighbours

• Threat is the event or actor that could exploit the weakness. A vulnerability is the weakness itself. The same vulnerability faces many threats, and a strong vulnerability programme prioritises by which threats are actually plausible against this system.
• Incident🚨IncidentDevOps & PlatformA production incidentView reference → is what happens when a threat successfully exploits a vulnerability. The flaw existed before the breach; the incident is the moment it was used. Most disclosed vulnerabilities are patched before any incident occurs.
• Penetration test is one of the ways a vulnerability gets discovered, alongside automated scanning, code review, and external researchers. The test finds the weakness; the vulnerability is what it found.

In the graph

In the Unified Product Graph, a vulnerability anchors the security region's weakness layer through four edges that map its whole lifecycle. A vulnerability_affects_serviceVulnerabilityaffectsServicecross-domain edge locates the flaw in the product, so its blast radius is queryable. A vulnerability_discovered_by_penetration_testVulnerabilitydiscovered byPenetration Testcross-domain edge records how it surfaced, and threat_model_surfaces_vulnerabilityThreat ModelsurfacesVulnerabilityhierarchy captures the design-time path where modelling exposed it before any attacker did. An incident_exploits_vulnerabilityIncidentexploitsVulnerabilitycross-domain edge connects the weakness to any breach that used it, which means a single query can answer the question every post-mortem asks: was this flaw known, and for how long, before it was used against us.