Repository navigation
map CVSS vector string to automatable? #1187
Description
Similar to #195 , is there a way to map a CVSS vector to an outcome for Automatable
Art suggested Automatable = yes may be sufficiently equivalent to AV:N AC:L (AT:N) PR:N UI:N.
Would that work? Is that a "close enough" mapping that it's useful? If it's useful, we can add some text to the same part of the documentation alongside the Technical Impact mapping discussed in #195
Activity
karelorigin commentedon Jun 23, 2026
@j--- unfortunately, CVSS vectors can only be used to rule out automation status (
AU: N).AV:N/AC:L/PR:N/UI:NguaranteesAU:Xat most.Vulnerabilities within libraries, for example, typically have those attributes but cannot be assumed to be automatable due to the absence of a single enumerable interface. Similarly, a vulnerability within a product that is not typically exposed on the internet may also have
AV:N, which makes forAU:Nin practice. Environmental prerequisites may determine a product's vulnerable state (AT:P/AC:H), but do not necessarily hinder an attacker's ability to automate exploitation for those instances if applicable (AU:Y).zmanion commentedon Jun 23, 2026
I would question AV:N for a library that was not primarily designed to process network data or "...a product that is not typically exposed on the internet." I get there is a difference between "routable network" and "internet" but in practice I don't think this distinction matters much. Also if often comes down to the poorly aging concept of "internal" networks.
CVSS attempts to address through "reasonable worst case," which can be somewhat subjective. It's also an abstraction problem, a library can be used a lot of different ways, some of those ways parse untrusted data, possibly recieved over a network. CVSS also supports different scenarios for the same vulnerability, at least the CVE implementation of CVSS does.
I agree that AT:P (or AC:H) may or may not map to AU:N, but AT:N + AC:L clearly supports AU:Y.
CVSS guidance says that:
I think this still supports mapping to AU:Y, if an attacker can reach a lot of vulnerable image library instances over the network, that's automatable.
j--- commentedon Jul 30, 2026
I might suggest the utility of this mapping would be using the CVSS environmental metrics for a deployed system to help support a decision to move from
AU:YtoAU:N. So the goal would be to agree on some conditions that clearly map toNo.I would imagine that the following CVSS metric fragment would mean automatable should be
No, right? "AV:L/AC:H/AT:P/PR:H/UI:A"I'd be surprised if @karelorigin felt that one was unclear, still, but would like to know the argument if so. Thanks!
Santoshkumarpuppala commentedon Aug 19, 2026
@j--- asked for the argument if the No mapping is unclear, so here is one narrow case, from access-control flaws in web applications.
The Automatable definition asks whether steps 1–4 can be reliably automated, and step 1 is reconnaissance. For an access-control flaw, reconnaissance means enumerating the identifiers of other tenants' objects — and that property is invisible to the vector. Take two bugs in the same endpoint, both AV:N/AC:L/AT:N/PR:L/UI:N: one keys on sequential integer ids, the other on a 128-bit token the owner alone ever sees. The first is fully automatable. The second isn't automatable at all, because there is nothing to enumerate. Same vector string, opposite answers, and the proposed mapping returns Yes for both.
So I land where @karelorigin does, by a different route than the library case — the vector is silent on target enumerability, and for this class enumerability is most of what Automatable is asking. It's also a route the reasonable-worst-case reading doesn't reach, since here the two vectors are literally identical rather than arguable.
On the specific fragment, AV:L/AC:H/AT:P/PR:H/UI:A — I'd agree that's No, and not a close call. The one thing I'd note is that almost nothing scores that way, so it's a rule that would rarely fire. If the goal is conditions that clearly map to No, the ones I actually see in the wild are AV:L on its own and UI:A on its own. Each breaks delivery or exploitation without needing the rest of the vector to agree.
Either way the asymmetry looks right to me: document a set of sufficient conditions for No, with no mapping to Yes at all. That says what the vector can support.