CFSE Consequence Paths v1.0-candidate

Methodology

CFSE Consequence Paths evaluates a vulnerability mechanism under explicit deployment and operational assumptions, as one or more cyber-physical consequence paths. Each path represents a distinct terminal consequence: authority, perception, data, physical/safety harm, systemic reach, or recovery burden. The model is intended as a consequence layer for triage, not a replacement for SSVC, EPSS, vendor advisories, published vulnerability scores, or asset-specific risk assessment.

Status: v1.0-candidate — the first public version. Calibrated against the current public review set and design-reviewed independently. A blind inter-rater reproducibility study and a construct-validity study (Path bands vs CVSS against recall class, CISA KEV, recovery burden, expert triage) are pre-registered and open — the blind scorer packet is public and practitioners are invited to participate.

The Paths model keeps physical/safety harm severity (`PH`), deployment realizability (`REAL`), and systemic reach (`SYS`) separate so a score can say why a case is severe without silently mixing harm, probability, guards, fleet scale, and recovery difficulty. This is not an accuracy claim. Independent validation is open.

What A Path Means

A single vulnerability can reach more than one kind of consequence. For example, a robot flaw may create an authority path, a perception path, and a physical/safety path. The Paths model keeps those paths separate so the analysis does not collapse fleet authority, sensor leakage, physical actuation, and recoverability into one unexplained number.

Identifier Scheme

Public records use stable CPATH identifiers in the form CPATH-YYYY-NNNN. The year is the assignment year, not necessarily the disclosure or publication year, and the sequence is minimum-four-digit, left-padded, and allowed to grow beyond four digits. The identifier names the consequence-path record only; severity, score, and vector values remain mutable record attributes.

Vector Fields

`TT`	Terminal consequence type: the kind of harm this path reaches, such as firmware trust root, device-control safety, fleet control plane, perception-to-action, or data privacy.
`RE`	Reachability: how much attacker position is needed, from no practical path to internet/default-exposed reachability.
`EC`	Execution complexity: how reproducible the exploit workflow is, from speculative/lab-only to commodity or single-request.
`EX`	Exposure: the effective exposure used by the aggregation engine; currently the lower of reachability and execution complexity.
`PH`	Physical / safety consequence: the safety or bodily consequence available to the vulnerability, scored separately from deployment realizability.
`DP`	Data / perception consequence: the sensitivity and operational importance of exposed or manipulated data.
`AT`	Authority transfer: what control, account, root, fleet-plane, signing, or trust authority is reached.
`CH`	Chainability / boundary crossing: whether the path bridges domains or composes into a broader attack.
`SR`	Scale of reuse: how portable the artifact, credential, primitive, or design flaw is across units or products.
`SX`	Scale of execution: whether exploitation remains per-device or can operate at deployment or fleet scale.
`OR`	Operational recoverability: whether recovery is easy, per-device, reflash-class, recall-class, or trust-root/fleet-reprovision-class.
`EV`	Evidence level: from speculative/inferred to report-backed, reproduced, or field-confirmed.
`LS`	Liveness state: whether the issue is active, partially mitigated, patch-available, mitigated, historical, or unknown.

Aggregation

The current public candidate separates pure physical/safety harm severity from deployment realizability and systemic reach. Registry entries preserve compact path vectors for review: exposure is derived from reachability and execution complexity; physical/safety, data/perception, and authority bands are computed; bounded modifiers account for active exploitation, fleet-scale authority, and recall-class recovery; caps prevent some path classes, such as privacy-only paths, from over-promoting. The overall registry verdict is the highest band among paths.

Published vulnerability scores can be recorded as baselines for review, but they are not the registry's primary organizing axis. The primary ordering is the Paths verdict and the path family that drives it.

Evidence And Validation

Evidence is part of the vector. Paths with low evidence should be treated as hypotheses or structured risk arguments until the underlying source and exploit chain are reviewed. Human review should check both the source facts and the Paths interpretation: whether the path exists, whether the terminal consequence is correctly named, whether PH/DP/AT/SR/SX/OR values are justified, and whether the final band follows the candidate rules.

Use Boundaries

Paths is designed to feed an SSVC-style decision and compose with EPSS. It does not decide remediation priority by itself, and it does not replace deployment context, compensating controls, asset criticality, exploit likelihood, patient/user exposure, or vendor-specific mitigation guidance.

Review or challenge a score