GuardDuty promotes weak runtime signals to CRITICAL once Inspector, Macie and Security Hub add context

GuardDuty's rule is a threshold. A single CVE finding on a host tells you a vulnerability exists, not that an attacker is exploiting it ^[5]. A lone runtime signal that does not match a known offensive-tool path typically stays below the Critical threshold when there is no resource-state context ^[12]. The new indicators supply that context. Each one has its own supplier, and each supplier has to be switched on.

The prerequisite list is the adoption cost. Inspector on EC2 and EKS feeds VULNERABILITY and MALICIOUS_PACKAGE ^[7], so one enablement covers two of the five indicators, or 40% ^[16]. Security Hub posture data, scored against AWS Foundational Security Best Practices, feeds MISCONFIGURATION ^[8]. Reachability Analyzer must run on production VPCs for REACHABILITY ^[9]. Macie feeds SENSITIVE_DATA ^[11]. All of it sits on top of Runtime Monitoring across EC2, ECS and EKS, and AWS calls every signal that produces a potential anchor ^[10].

ECS appears only in that last line. The Inspector requirement names EC2 and EKS ^[7][10]. We would check what an ECS task actually receives before assuming parity with an EKS pod.

AWS says the net-new share reaches roughly one in four prioritized runtime-process attack sequences, with little change on the network IOC surface ^[17]. It reports the pattern across many customer accounts within the first week ^[18]. This is AWS's count over AWS's customers. For it to transfer, your fleet needs Runtime Monitoring plus the suppliers, and a similar mix of unpatched CVEs and misconfigurations on the same hosts. The figure is a share, so a quiet account and a busy one can both sit at one in four. An account whose findings are mostly network IOC should expect little of it, since that is the surface that barely moved ^[17].

AWS says customer feedback has consistently named noise in individual runtime findings as a major pain point ^[19].

The VULNERABILITY indicator carries an EPSS score ^[14]. According to the FIRST EPSS overview, it is the probability, from 0 to 1, that a published CVE will be exploited in the wild in the next 30 days ^[6]. AWS says it does not replace CVSS, which describes inherent severity, and calls EPSS the more useful number for incident response ^[15]. In our view that is the right sort key for a sequence already in progress on a host. CVSS can stay the key for the patch backlog.