Live
Scaling AI Agent Swarms: Architecture and Ops Implications for EngineersAnonymous authentication for organization‑level Dependabot registries: practical impactCloudflare Queues add immutable jurisdiction controls for data residencyOpen AI Factory Architecture: NVIDIA’s MGX 1.2 Rack Design and New DSX Tooling Arrive at OCPAgents SDK adds web_fetch tool for on‑the‑fly markdown conversionConfigurable Telemetry Identity Capture for GitHub Copilot Enhances AuditingDeploying Agentic AI at Scale in France: New NVIDIA Hardware, Open Models, and Sovereign FrameworksGuardDuty Extended Threat Detection adds five indicator types – practical impact for engineersScaling AI Agent Swarms: Architecture and Ops Implications for EngineersAnonymous authentication for organization‑level Dependabot registries: practical impactCloudflare Queues add immutable jurisdiction controls for data residencyOpen AI Factory Architecture: NVIDIA’s MGX 1.2 Rack Design and New DSX Tooling Arrive at OCPAgents SDK adds web_fetch tool for on‑the‑fly markdown conversionConfigurable Telemetry Identity Capture for GitHub Copilot Enhances AuditingDeploying Agentic AI at Scale in France: New NVIDIA Hardware, Open Models, and Sovereign FrameworksGuardDuty Extended Threat Detection adds five indicator types – practical impact for engineers
AWS

GuardDuty Extended Threat Detection adds five indicator types – practical impact for engineers

Ninja·October 13, 2026·2 min read·via AWS Security Blog
AI SummaryPowered by AI

On May 20, 2026 GuardDuty began attaching five new indicator types—MALICIOUSPACKAGE, MISCONFIGURATION, REACHABILITY, SENSITIVEDATA, and VULNERABILITY—to its extended threat detection attack‑sequence findings. This change gives engineers richer context for weak signals, enabling more focused incident response and security posture management.

GuardDuty’s extended threat detection now enriches attack‑sequence findings with five additional indicator categories. The change matters because teams that already run Amazon Inspector, VPC Reachability Analyzer, Amazon Macie, or AWS Security Hub will see those service signals folded directly into GuardDuty findings, giving a clearer picture of why a sequence is deemed critical.

New indicator types and their sources

The added categories map to existing AWS services:

  • VULNERABILITY – emitted by Amazon Inspector and includes CVE identifiers, CVSS severity, and EPSS exploit‑likelihood scores.
  • MALICIOUS_PACKAGE – also from Amazon Inspector, representing packages flagged by the Inspector MAL‑* research.
  • REACHABILITY – supplied by Amazon VPC Reachability Analyzer, indicating whether a host or cluster can be reached from the internet.
  • MISCONFIGURATION – derived from AWS Security Hub controls, highlighting resources that deviate from AWS or industry best‑practice configurations.
  • SENSITIVE_DATA – sourced from Amazon Macie, flagging the presence of classified data types.

How the indicators appear in GuardDuty findings

Each indicator is attached to an attack‑sequence finding as a discrete element. The finding still carries GuardDuty’s existing suspicious‑activity signals, but the new elements provide the “why” behind the correlation. For example, a VULNERABILITY indicator will list the CVE ID and its CVSS score, while a REACHABILITY indicator will note the internet‑exposed status of the affected resource.

Operational considerations

Teams must already have the prerequisite services enabled; GuardDuty does not provision them automatically. Once the indicators are present, the following operational steps become relevant:

  1. Update alerting pipelines to surface the new indicator fields, ensuring that security dashboards display the enriched context.
  2. Adjust incident‑response playbooks to incorporate source‑specific actions—e.g., patching a VULNERABILITY, remediating a MISCONFIGURATION via Security Hub, or restricting internet exposure flagged by REACHABILITY.
  3. Review the correlation threshold settings in GuardDuty to confirm that the added indicators do not inflate false‑positive rates.
  4. Validate that existing monitoring for Inspector, Macie, and Reachability Analyzer remains aligned with the new GuardDuty output, avoiding duplicate tickets.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Practitioners should verify that Inspector, Reachability Analyzer, Macie, and Security Hub are active in the accounts they protect. Once confirmed, they need to extend their detection and response tooling to parse the five new indicator types, map them to remediation actions, and tune GuardDuty’s severity thresholds accordingly. Ongoing evaluation of the signal‑to‑noise ratio will help determine whether the enriched findings improve detection confidence without overwhelming response teams.

Tags: #guardduty#extended-threat-detection#security#cloud#incident-response
Originally published atAWS Security Blog
Related Articles
AWS

Implementing ML-DSA Signing on AWS for a Quantum‑Resistant Software Supply Chain

4 min read
AWS

Enforcing ML‑DSA Algorithm Policy with SCPs and IAM on AWS

3 min read
GitHub

GitHub adds durable push attribution to commits for Enterprise preview

3 min read