The ASFF Finding Format

Security Hub aggregates findings from dozens of sources, each with its own structure. To make them comparable it converts everything into one schema: the AWS Security Finding Format (ASFF). Understanding ASFF lets you read, filter, and automate on any finding regardless of where it came from.

ASFF is a standardized JSON structure with defined fields that every finding must populate. Because the fields are consistent, you can write one set of rules, filters, or automations that work across GuardDuty, Macie, Inspector, and partner findings alike.

Key fields include an Id uniquely identifying the finding, a ProductArn naming the service that produced it, and an AwsAccountId. These let you trace any finding back to its source account and service, essential in multi-account aggregation.

The Types field classifies the finding using a namespace taxonomy (such as a software-and-configuration or unusual-behavior category), while Title and Description give human-readable summaries. Together they tell an analyst at a glance what the finding is about.

ASFF normalizes severity into a consistent structure with a normalized score and label (such as INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL). Because severity is expressed the same way for every source, you can prioritize fairly across services that originally used different scales.

The Resources array lists the affected resources with their ARNs, types, and details. This is how you know exactly what a finding touches, which is critical for routing remediation to the right resource and for understanding blast radius.

ASFF tracks lifecycle with a Workflow status (NEW, NOTIFIED, RESOLVED, SUPPRESSED) and a RecordState (ACTIVE or ARCHIVED). Analysts update workflow status as they handle a finding, so the queue reflects what still needs attention versus what is done.

For control-based findings, ASFF includes a Compliance field reporting PASSED, FAILED, or WARNING against a standard. This is how standard checks surface in the same format as threat findings, unifying posture and threat data in one schema.

Because every finding shares this schema, you can build EventBridge rules and Lambda functions that key off ASFF fields like Severity.Label or Resources.Type. One automation can react to findings from many sources, which is the whole point of normalization.

Because ASFF fields are standardized, you can build precise filters and insights on them: show only HIGH and CRITICAL findings, only a given account, or only a resource type. The same fields power EventBridge event patterns. Mastering which ASFF field holds which piece of information lets you slice the finding stream exactly as an investigation requires.

Whereas BatchImportFindings injects new findings, BatchUpdateFindings lets you change a finding's workflow status, severity, or note, but only certain fields and only by the account that owns the finding, not the originating product's fields. This separation keeps source data trustworthy while still letting analysts manage triage state, a nuance the exam occasionally tests.

Recall the purpose of ASFF.

ASFF is Security Hub's standardized JSON schema for all findings. Key fields include Id, ProductArn, AwsAccountId, Types, normalized Severity (label and score), Resources (ARNs), Workflow/RecordState lifecycle, and Compliance status. The shared schema enables consistent filtering and EventBridge-driven automation, and you can import custom findings via BatchImportFindings.