map CVSS vector string to automatable?

[j---]

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

[karelorigin]

@j--- unfortunately, CVSS vectors can only be used to rule out automation status (AU: N). AV:N/AC:L/PR:N/UI:N guarantees AU:X at 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 for AU:N in 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]

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:

...a library that performs image conversion would reasonably be used by programs that accept images from untrusted sources over a network. In the reasonable worst-case, it would pass them to the library without checking the validity of the images. As such, an analyst assessing a vulnerability in the library that relates to the incoming data should assume an Attack Vector (AV) of Network (N)...

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---]

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:Y to AU:N. So the goal would be to agree on some conditions that clearly map to No.
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!