Automatable asks one question: can an attacker reliably automate the first four kill chain steps, reconnaissance, weaponization, delivery and exploitation, for this vulnerability? Yes means an attacker can run it at scale with no human in the loop. It matters because machine speed shrinks your response time. If you know nothing, assume yes.
Definition
The SEI's SSVC documentation defines two values:
- No: attackers cannot reliably automate steps one to four.
- Yes: attackers can reliably automate steps one to four.
The four steps are reconnaissance, weaponization, delivery and exploitation. The documents say the CVSS Automatable metric was developed alongside this SSVC decision point and the two are intended to be interchangeable. CVSS adds an explicit Not Defined value. SSVC does not.
When the answer is no
The documentation lists reasons a step may not be reliably automatable:
- the vulnerable component cannot be searched or enumerated on the network
- weaponization needs human direction for each target
- delivery needs a channel that widely deployed network security configurations block
- exploitation is unreliable because protections such as ASLR are on by default
When the answer is yes
If the flaw allows remote code execution or command injection, the expected answer is yes. The CVSS FAQ aligns Automatable Yes with wormable, a flaw usable by a self-replicating attack that spreads at machine speed. It advises treating such flaws as more urgent, and acting as soon as a public proof-of-concept exists.
Chaining changes the answer
The SSVC page raises a subtle point. Suppose flaw A affects systems that are normally not reachable from outside, so scanning for them fails and A looks like a no. Now suppose flaw B is automatable and can be reliably chained to A. B automates the reconnaissance for A. The analyst should then reflect that chain when answering for A.
For your own estate, that means looking at what sits in front of internal services. A weak edge can turn a no into a yes for everything behind it.
The default
SSVC says that if nothing is known about Automatable, the safer assumption is yes. This is deliberate. A blank would otherwise slip through as a low value.
Where to get the answer
CISA says its Vulnrichment program publishes SSVC decision points for CVEs it analyzes, including Automatable, Exploitation and Technical Impact, in the CISA container of the CVE record. It says it never overwrites the originating CNA's data. BOD 26-04 relies on the same Automatable and Technical Impact definitions, so the federal patch timeline and your own tree can share data.
So you rarely have to guess. Pull the value from the CVE record, then override only when you hold better information and write down why.
Using it
Put Automatable in your triage view next to KEV status and internet exposure. A flaw that is automatable and on an internet-facing asset is a candidate for your fastest lane even before a fix is ready, because mitigation can be as simple as removing exposure.
Safeguard's reachability analysis and asset discovery help with the exposure half of that picture. Try the exploitability check demo.
Quick check
Is a remote code execution flaw automatable?
Usually yes. The SSVC documentation says remote code execution or command injection should expect a yes.
What if the vulnerable system is not reachable from the internet?
It may be no on its own, but an automatable flaw in a system in front of it can chain to it and change the answer.
Sources
- SEI SSVC documentation: Automatable
- FIRST: CVSS v4.0 Specification Document
- FIRST: CVSS v4.0 FAQ
- CISA Vulnrichment repository
- CISA: BOD 26-04
Last reviewed: 19 October 2026.
