Problem
A network attack vector (CVSS AV:N or AV:A) tells a consumer that a vulnerability is deliverable over a network — but not over what. Many network-vector vulnerabilities are only triggerable via a specific protocol, or even a specific negotiated ALPN:
- An SSH-only vulnerability on a host whose SSH port is not internet-exposed.
- An HTTP/2-only flaw on a backend that only ever receives HTTP/1.1, because the load balancer in front of it terminates HTTP/2 and forwards downgraded requests.
- A TLS-stack vulnerability that is only reachable when a particular ALPN (e.g.,
h2, h2c) is actually negotiated on the listening path.
Today that information exists only in prose. CVE descriptions routinely state it ("via a crafted HTTP/2 request…", "in the SSH transport layer…"), but there is no structured field a scanner or vulnerability tracker can rely on. As a result, environment-aware tools must treat every AV:N finding as reachable through every exposed path, which inflates urgent-queue volume and buries the findings that genuinely are exposed.
Proposal
Add two optional structured fields to the CVE Record format (in the affected array and/or available to ADP enrichment containers):
affectedProtocol — the application/transport protocol(s) required to deliver the trigger, using IANA service names where possible (e.g., ssh, http, smtp, dns, tls).affectedAlpn — where relevant, the ALPN protocol ID(s) required (IANA ALPN registry values, e.g., h2, http/1.1, h2c).
Populated by the CNA at publication when the fact is already known (it usually is — it's in the description), or added later through ADP enrichment.
Semantics — conservative by default
- Absence of the field means "unknown" and MUST NOT be used to downgrade exposure or reachability. No record gets safer by omission.
- Presence lets a consumer rule a delivery route in or out with evidence: if the affected protocol is not in use on the asset, or not carried by the exposed path in front of it, the finding can be de-prioritized for that route — with a machine-readable reason attached.
Why this helps the ecosystem
- Prioritization at scale: exposure-aware triage (SSVC's exposure inputs, reachability-based frameworks such as FedRAMP's internet-reachable determination under the 2026 VDR/VER rules) currently depends on parsing prose per-CVE. A structured field turns a per-finding research task into a join.
- It's machine-readability for facts already published: this proposal adds no new analysis burden on CNAs — it captures, in a field, what the description already says. Where the CNA doesn't know, the field is simply omitted.
- Precedent: the record format already scopes applicability by product and version (
affected/CPE). Protocol and ALPN are the same kind of applicability scoping, one layer down the stack.
Discussion points
- Best home for the fields:
affected[] entries vs. a dedicated container vs. ADP-only enrichment.
- Vocabulary governance: IANA service-name and ALPN registries cover most cases; an
other + free-text escape hatch handles the rest.
- Relationship to CVSS v4
AT (Attack Requirements): AT:P flags that a deployment condition exists; these fields would make one very common class of condition (protocol dependence) machine-readable.
Problem
A network attack vector (CVSS
AV:NorAV:A) tells a consumer that a vulnerability is deliverable over a network — but not over what. Many network-vector vulnerabilities are only triggerable via a specific protocol, or even a specific negotiated ALPN:h2,h2c) is actually negotiated on the listening path.Today that information exists only in prose. CVE descriptions routinely state it ("via a crafted HTTP/2 request…", "in the SSH transport layer…"), but there is no structured field a scanner or vulnerability tracker can rely on. As a result, environment-aware tools must treat every
AV:Nfinding as reachable through every exposed path, which inflates urgent-queue volume and buries the findings that genuinely are exposed.Proposal
Add two optional structured fields to the CVE Record format (in the
affectedarray and/or available to ADP enrichment containers):affectedProtocol— the application/transport protocol(s) required to deliver the trigger, using IANA service names where possible (e.g.,ssh,http,smtp,dns,tls).affectedAlpn— where relevant, the ALPN protocol ID(s) required (IANA ALPN registry values, e.g.,h2,http/1.1,h2c).Populated by the CNA at publication when the fact is already known (it usually is — it's in the description), or added later through ADP enrichment.
Semantics — conservative by default
Why this helps the ecosystem
affected/CPE). Protocol and ALPN are the same kind of applicability scoping, one layer down the stack.Discussion points
affected[]entries vs. a dedicated container vs. ADP-only enrichment.other+ free-text escape hatch handles the rest.AT(Attack Requirements): AT:P flags that a deployment condition exists; these fields would make one very common class of condition (protocol dependence) machine-readable.