Vulnerability Registry
On this page
Framework version: 2.0.0-draft.1. Status: proposed registry design and governance process. This document does not establish an operating institution or announce accepted findings.
Purpose and entry kinds
The registry records claims, evidence, decisions, and their revision history. Inclusion does not establish validity or framework recognition. Classification belongs to the taxonomy; the registry preserves the record through which a particular finding or proposal was evaluated.
Distinguish concrete findings from class proposals. A concrete finding concerns a bounded system and configuration. A class proposal requests a new or revised mechanism, family, or security property. An incident report may supply evidence to either but should not be silently converted into a general class. Record the entry kind explicitly and link related entries.
The registry should retain refutations, duplicates, withdrawals, and inconclusive cases. These prevent repeated unsupported claims and preserve useful negative evidence. Retention is subject to privacy and disclosure obligations; public retention of personal data or operational exploit detail is not required.
Versioned record structure
Every entry has a stable identifier under the scheme in Versioning and Identifiers, an entry revision, a schema version, and the framework version used for classification. Identifier assignment denotes record creation, not acceptance. Earlier revisions remain referenceable except where lawful removal or necessary protection requires restricted handling; such changes should leave a non-sensitive audit explanation.
| Field group | Required content |
|---|---|
| Identity | entry_id, entry_revision, schema_version, framework_version, entry_kind, title, created_at, updated_at |
| Claim | bounded statement, claim identifiers, expected contract, assumptions, falsifying observations |
| Scope | target versions, configuration references, deployment boundary, lifecycle, profile identifiers and versions |
| Threat | actor or disturbance, access, knowledge, control, feedback, budget, timing, exclusions |
| Classification | property_ids, mechanism_ids, dimension_ids, entry_points, failed_contracts, participating_domains, interaction_locus, propagation, impact_scope |
| Evidence | assessment outcomes, E0–E6 facets, protocol, oracle, controls, units, execution accounting, analysis, artifact references |
| Consequence | demonstrated and potential impact, severity rationale, likelihood assumptions, reversibility, recovery limits |
| Review | review_status, reviewers, independence disclosures, conflicts, rationale, unresolved criteria, decision history |
| Disclosure | confidentiality_status, owner contact record where appropriate, embargo or release conditions, redactions, access and retention rules |
| Relationships | related entries, duplicate or superseding links, prior-category comparison, migration history |
Missing required information must have an explicit reason and an unresolved state. Unknown is not equivalent to empty, false, or zero. For a class proposal, target-specific fields can reference the supporting assessments rather than pretending that a class has one target version.
Classification references the exact canonical domains: L1 Models & Computation; L2 Software & Infrastructure; L3 Data & Knowledge; L4 Perception & World Representation; L5 Interpretation & Objectives; L6 Memory & State Continuity; L7 Planning & Action; L8 Human–System Interaction; and L9 Collective & Systemic Interaction. The schema permits multiple failed contracts and node, edge, shared-resource, group, or subgraph loci. Primary domain is optional. Mere traversal does not imply a domain failure.
Evidence and outcome fields
Assessment outcomes are supported, refuted, inconclusive, quality_issue, hazard_only, or out_of_scope, each attached to a claim and rationale. These are separate from administrative review status. One entry can contain a supported narrow claim and an inconclusive generalization.
E0 Hypothesis, E1 Single Observation, E2 Reproduced Observation, E3 Controlled Experiment, E4 Cross-Condition Evidence, E5 Cross-Model Evidence, and E6 Independent Replication are evidence facets as defined in Assessment Methodology. Each records supported, unsupported, not_tested, inconclusive, or not_applicable, with artifacts and scope. They are not cumulative scores or substitutes for reviewer judgment. Independent replication of a narrow claim does not establish broad applicability.
The unresolved-criteria field may legitimately state that no outstanding criteria remain for the bounded decision, provided residual limitations are separately recorded. It must not require inventing an unmet criterion merely to complete a form. Evidence withheld from public access is not automatically weak, but reviewers must state whether they inspected it. Unavailable evidence cannot receive the same verification claim as inspected evidence.
Proposed review states
Use submitted, under_review, accepted, rejected, withdrawn, and superseded as review_status values. Acceptance of a concrete finding means the specified claim met the documented review criteria. Acceptance of a class proposal additionally requires the taxonomy's novelty and inclusion criteria. Neither is a certification of the target system or a statement about every related deployment.
Submission enters submitted. Triage can move it to under_review or request missing information while retaining its state. A reasoned review can produce accepted or rejected; the submitter may request withdrawal. Superseded records link to the replacement. New evidence can reopen any substantive decision through under_review. Preserve the earlier decision and explain why it changed.
Duplicates should link to the relevant entry and retain any distinct evidence rather than acquiring an independent acceptance claim. A rejected proposal can still contain a valid concrete finding whose novelty claim failed. Separate those decisions. Withdrawal does not erase an independently supported event, and acceptance can be revised when new evidence undermines the explanation.
Proposed governance responsibilities
The following roles are a governance proposal, not a claim that reviewers or a board currently exist. An intake custodian checks completeness and protects sensitive material. A technical reviewer examines contracts, reachability, controls, and causal evidence. A domain reviewer examines consequences and profile assumptions where specialized expertise is required. A decision custodian records the outcome and ensures the stated criteria were applied.
One person may perform administrative roles in a small project, but must disclose overlap. A submitter should not be the sole substantive reviewer of their own acceptance. Where independent review cannot be obtained, retain the submission as pending review rather than simulate independence. Financial, employment, authorship, personal, and competitive conflicts should be disclosed and assessed; recusal or an additional reviewer may be necessary.
A decision record names the claim, evidence examined, applicable criteria, unresolved limits, reviewer roles, conflicts, dissent, and date. Review should not depend on affiliation or publication prestige. Reproducibility and relevant expertise matter, while constrained access to proprietary systems should be explained rather than treated as automatic disqualification.
An appeal identifies a procedural error, overlooked evidence, or disputed technical inference. A reviewer not responsible for the disputed decision should examine it where feasible. The outcome and reasoning remain linked to the original record. If no independent appeal reviewer is available, record that limitation and keep the dispute visible. The proposal does not create authority it cannot currently exercise.
Acceptance and citation
A concrete finding requires a specified security contract, credible conditions, evidence of the claimed violation, a bounded impact explanation, consideration of alternatives, and a review record. The required evidence depends on the claim and profile. A deterministic implementation flaw does not need cross-model testing merely to be actionable.
A class proposal additionally compares the closest existing categories, explains the distinction, supplies supporting cases, and tests plausible falsifiers. Cross-condition and independent evidence should be sought in proportion to the generality claimed. Absence of a reviewed profile is an unresolved acceptance issue to be addressed explicitly, not a reason to apply an arbitrary numerical evidence threshold.
Citations include entry identifier, revision, framework version, review status, and claim scope. Submitted and under-review entries are proposals under evaluation. Accepted entries may be described as accepted under the documented process, with limitations. Rejected or superseded entries remain citable as historical decisions. A public abstract should preserve these qualifiers so that detached summaries do not convert hypotheses into recognized vulnerabilities.
Disclosure and evidence access
Specific deployed-system weaknesses require coordinated handling with the responsible owner before public operational detail is released. Record contact attempts, relevant responses, agreed timing where available, and the basis for a release decision. This document does not prescribe a universal deadline or authorize publication contrary to applicable obligations.
Use public, restricted, and embargoed as confidentiality_status values. Public records can describe contracts, affected versions where appropriate, evidence summaries, and remediation while restricting details that materially enable abuse. Store sensitive artifacts with least necessary access, retention limits, and audit records. Redact credentials, personal data, and unrelated organizational information.
Researchers should provide sufficient evidence to authorized reviewers without making harmful reproduction instructions universally available. If disclosure limits prevent independent verification, record that specific limitation. Privacy protection and evidence quality are related but distinct decisions. A privacy-preserving digest can establish artifact identity without proving the contents of a claim.
Illustrative entry
The following is an illustrative, unexecuted example, not a submitted or accepted registry finding. Its local example identifier is EXAMPLE-RETRIEVAL-01 and must not be allocated as a production registry entry.
The claim is that attacker-controlled retrieved content could cause an unauthorized retained preference update in a synthetic assistant. The actor controls one document and cannot alter system instructions or tool permissions. Proposed properties are P04 Instruction Integrity and P07 Memory Integrity. The entry point is an L3 information source; hypothesized failed contracts concern L5 interpretation and L6 persistence. Proposed mechanism references are M05 Semantic Manipulation and M08 Memory Manipulation, pending evidence. No L7 Action Integrity violation is claimed without an action-contract observation.
The planned oracle is a retained-state readback, with matched benign retrieval as a negative control and isolated session reset. Trial counts, observed events, and impact are not available because the example has not been executed. Assessment outcome is inconclusive; E0 can describe the explicit hypothesis, while E1–E6 are not_tested. Review status would remain submitted only if a real submission were created; this illustrative record has no review decision.
A falsifier would be evidence that the state change requires an authorized user update, or that the alleged persistence never occurs. A second alternative is that the harness writes the preference itself. The example demonstrates how to state missing evidence without manufacturing a finding.
Maintenance and migration
Validate schema structure separately from scientific acceptance. A well-formed record can contain an unsupported claim. Validate identifier references against the specified framework version and reject silent reuse of P, M, or D meanings. Migrations record the old classification, proposed mapping, reviewer, and reason; material domain changes require human reclassification rather than automatic relabeling.
Audit decision latency, unresolved disputes, disclosure handling, and recurring missing fields as process evidence. Do not present entry counts as proof of scientific quality. The registry succeeds when a reader can distinguish what was proposed, observed, established, limited, and later revised.