AWS Security Hub Automation Rules: How They Work

AWS Security Hub CSPM automation rules match finding fields and update selected fields; they do not execute remediation against AWS resources. Use them to normalize severity, add context, change workflow status, or suppress findings. For CSPM, use EventBridge when a finding must trigger a notification or an external response workflow.

AWS now documents two automation rule models. This guide focuses on Security Hub Cloud Security Posture Management (Security Hub CSPM), whose findings use the AWS Security Finding Format (ASFF). The newer AWS Security Hub experience has a separate rule model based on Open Cybersecurity Schema Framework (OCSF) findings. The criteria, actions, APIs, and Region behavior differ, so use the guide for the service and finding format you operate.

What Security Hub CSPM automation rules do

A CSPM rule compares incoming findings with one or more criteria, such as account ID, resource type, severity, resource tags, or control status. For matching findings, it can update supported ASFF fields, including Severity, Note, and Workflow. Rules are useful for applying consistent triage context across accounts or products.

Setting Workflow.Status to SUPPRESSED changes how the finding is handled; it does not fix the affected resource or stop a security control from running. If you want Security Hub CSPM to stop generating findings for a control, disable that control instead. See AWS's guide to automation rule behavior and supported ASFF fields.

Choose the rule model that matches your findings

Rule model	Finding format and API	What it can do
Security Hub CSPM ASFF rules	ASFF; CreateAutomationRule	Update supported finding fields such as severity, note, confidence, and workflow status. Suppression is a workflow status.
AWS Security Hub OCSF rules	OCSF; CreateAutomationRuleV2	Update supported OCSF fields such as Comment, SeverityId, and StatusId, or create tickets through supported Jira Cloud and ServiceNow ITSM integrations.

These are separate rule models, not interchangeable payload versions. For the newer OCSF model, see AWS's documentation for automation rules in AWS Security Hub and Security Hub automations.

Their deployment scope also differs. A CSPM rule applies only in the Region where it was created; the CSPM administrator can apply it to matching findings from member accounts in that Region. With Region aggregation in the newer Security Hub, rules created in the home Region apply to linked Regions. Create rules for Regions outside that linked set separately. Follow the appropriate AWS guide when planning account and Region coverage.

Create a Security Hub CSPM automation rule

Create and manage CSPM rules from the Security Hub CSPM administrator account. Create a rule in each Region where it should apply. You can use the console or the CreateAutomationRule API and AWS CLI.

Create the rule in the console

In the Security Hub CSPM console, choose Automations, then Create rule and Create custom rule. Give the rule a name, define at least one criterion, and select at least one automated action. Choose whether it starts enabled or disabled. Where supported, review the matching-findings preview before enabling the rule. The AWS creation guide covers the current console and API steps.

Choose finding criteria

Criteria refer to ASFF finding fields. For example, a rule can match a particular AwsAccountId, the AwsS3Bucket resource type, a HIGH severity label, and a FAILED compliance status. The compliance status criterion applies to findings generated by controls. For control findings, AWS recommends using a stable control ID instead of a title or description that can change; see its Security Hub CSPM automation guidance.

Choose finding-field updates

CSPM automation rule actions update finding fields. AWS currently supports Confidence, Criticality, Note, RelatedFindings, Severity, Types, UserDefinedFields, VerificationState, and Workflow. They are not direct EventBridge targets: selecting an SNS topic, invoking Lambda, and changing an S3 policy are not CSPM automation rule actions.

Example: add context and raise production findings

This AWS CLI example matches high-severity, failed control findings from the account whose ID you provide, then changes their severity and note. Run it with CSPM administrator credentials in the target Region. Replace the example account ID and Region, and set --rule-order to a distinct value among rules that can match the same finding.

aws securityhub create-automation-rule \
  --rule-name "Escalate high severity in production" \
  --description "Add triage context to high severity failed control findings" \
  --rule-order 1 \
  --rule-status ENABLED \
  --no-is-terminal \
  --criteria '{
    "AwsAccountId": [{"Value": "123456789012", "Comparison": "EQUALS"}],
    "SeverityLabel": [{"Value": "HIGH", "Comparison": "EQUALS"}],
    "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Severity": {"Label": "CRITICAL"},
      "Note": {
        "Text": "Production finding promoted by automation policy.",
        "UpdatedBy": "security-automation"
      }
    }
  }]' \
  --region us-east-1

This changes the finding's displayed severity and note. It does not change the affected AWS resource or control result. If a later rule also updates severity, its action may determine the final value.

Order rules and understand when they run

Rule order and overlapping actions

Security Hub CSPM applies rules in ascending numerical RuleOrder. When multiple rules update the same field, the rule applied last wins; a larger order value therefore takes effect later. The console assigns order automatically, while API and CLI requests set it explicitly. Give overlapping rules distinct order values and check the actual order rather than assuming an older rule takes precedence. If a matching rule should end further evaluation, use the terminal-rule option (IsTerminal in the API).

Verify matching findings and results

Use the console preview when it is available, then inspect matching findings to confirm their fields changed as intended. Automation rules evaluate new and provider-updated findings after rule creation. A manual finding-field update through BatchUpdateFindings does not trigger another automation-rule evaluation. If the expected action does not appear, check the rule's enabled state, account and Region, criteria values, and whether the finding was updated by its provider.

Use EventBridge for notifications and response workflows

Route Security Hub CSPM findings with EventBridge

Security Hub CSPM also sends new and updated findings to EventBridge. Automation rules update a finding before EventBridge rules evaluate it, so an EventBridge pattern can match the updated values. For example, this CSPM pattern matches critical findings whose workflow status is NEW:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL"]},
      "Workflow": {"Status": ["NEW"]}
    }
  }
}

Configure a target such as an SNS topic, Lambda function, Step Functions state machine, or SQS queue. EventBridge routes the matching event; an SNS topic can deliver a notification, while a function or runbook must implement investigation or a resource change. Provider updates can emit another event, and EventBridge can retry target delivery; make state-changing handlers safe to repeat and configure a dead-letter queue for events that exhaust retries. See AWS guidance for Security Hub CSPM response workflows, finding event patterns, EventBridge retries and dead-letter queues, and duplicate target invocations. For retry, delivery, and target design, see our guide to EventBridge best practices.

Make resource remediation explicit

If a finding should change a resource, route it to a deliberately designed response workflow. A Lambda function or Systems Manager Automation runbook can make that change, subject to its IAM permissions and input validation. Test the target on representative findings and verify that the resource itself changed. Updating a finding to RESOLVED or SUPPRESSED alone is not remediation. Our guide to Amazon Inspector and Security Hub CSPM shows the same distinction for vulnerability findings.

Use custom actions for a person-triggered workflow

A Security Hub CSPM custom action lets an analyst select findings and send them to EventBridge for processing. It is a user-triggered path, separate from an automation rule that runs when provider findings match criteria. The emitted event uses the Security Hub Findings - Custom Action detail type; create the EventBridge rule and target that handle the response. See AWS's guide to sending findings to a custom action.

Maintain and troubleshoot rules

Common reasons a rule does not have the expected effect

• Wrong model: CSPM criteria use ASFF fields. The newer Security Hub model uses OCSF; a field or API payload from one model is not valid for the other.
• Wrong Region or account scope: CSPM rules are Regional and are managed by the CSPM administrator. Confirm the finding is visible in that Region and account scope.
• Wrong update source: CSPM rules evaluate new and provider-updated findings; they do not run again because a user called BatchUpdateFindings.
• Overlapping rules: a later rule can overwrite a field changed by an earlier rule. Review order and terminal settings.
• Expected a resource change: rule actions edit finding fields. Check that the separate EventBridge target was invoked and that its role allows the required resource operation.

For a control finding, use its control ID when a filter should survive title or description edits. Avoid broad suppressions unless the criteria describe a finding you intend to remove from active triage.

Conclusion

Summary

Security Hub CSPM automation rules help standardize finding triage by matching ASFF fields and updating supported finding fields. Keep them distinct from the newer OCSF-based Security Hub rule model. Use EventBridge and an explicit target workflow for notifications or resource remediation, then verify both the finding update and the target's result.