AWS Security Hub · SSM
SSM.6: SSM Automation runs are not logged
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub SSM.6 check?
SSM.6 fails when Systems Manager Automation is not configured to send execution output to CloudWatch Logs. This is an account-level setting that routes the output of `aws:executeScript` actions in your runbooks to a CloudWatch Logs group; without it, the script output those steps produce is not captured to CloudWatch.
Why does SSM.6 matter?
A single Automation document can patch a thousand instances, rotate keys, or modify infrastructure across the fleet. When a run mis-fires (wrong targets, a bad parameter, a stale role), the question "what did it actually do?" needs an answer in minutes, and the console summary won't provide it. SOC 2 CC7.2, ISO 27001 A.12.4, HIPAA 164.312(b), and PCI DSS 10.2 all require complete logs of automated changes to production.
How do I fix SSM.6?
- Create or choose a CloudWatch Logs group for Automation output.
- Set the CloudWatch log group in Systems Manager Automation preferences.
- Ensure the Automation execution role can write to that log group.
- Set retention on the log group and forward the logs to your SIEM.
Remediation script · bash
# Verify the prerequisite first: API Gateway's account-level CloudWatch role.
# Without it, the logging setting saves but no logs ever flow.
aws apigateway get-account --query 'cloudwatchRoleArn' --output text
# Enable ERROR-level execution logging on every stage of a REST API.
REST_API=a1b2c3d4e5
for STAGE in $(aws apigateway get-stages --rest-api-id $REST_API \
--query 'item[].stageName' --output text); do
aws apigateway update-stage --rest-api-id $REST_API --stage-name $STAGE \
--patch-operations op=replace,path=/*/*/logging/loglevel,value=ERROR
done
# Cap retention on the log group so storage stays bounded (do this every time you enable logging).
aws logs put-retention-policy \
--log-group-name "API-Gateway-Execution-Logs_${REST_API}/prod" \
--retention-in-days 90
# Example for a managed database: publish engine logs to CloudWatch (no per-event charge).
aws rds modify-db-instance --db-instance-identifier prod-db \
--cloudwatch-logs-export-configuration 'EnableLogTypes=["error","audit"]' --apply-immediatelyFull walkthrough (console steps, edge cases and verification) in the lesson Enable application and API logging.
Is SSM.6 a false positive?
This is an account-level setting that captures the output of `aws:executeScript` steps in your runbooks, so it can fail legitimately in an account that runs Automation but no `executeScript`-based documents: the very output the preference captures is never produced, and turning logging on changes nothing observable. It also fails in a member account by design when Automation runs are deliberately driven from a central or delegated administrator account where the CloudWatch logging lives, leaving each member with no local preference to detect. Confirm where your Automation output is actually being captured, then suppress SSM.6 in the accounts that legitimately have no local `executeScript` logging to configure rather than setting an empty log group purely to clear the control.