Skip to main content
emnode / learn
Compliance Low severity

AWS Security Hub · SSM

SSM.3: SSM associations are non-compliant

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SSM.3 check?

SSM.3 scrapes State Manager association statuses and fails any managed instance whose latest association execution is anything other than COMPLIANT. An association binds an SSM document — patch baseline, inventory gather, agent config — to target instances on a schedule.

Why does SSM.3 matter?

The association is the contract: "this instance will be patched every Sunday", "this instance will report inventory hourly". A failed association means that contract is silently unmet, so the instance has drifted from its declared configuration. SOC 2 and ISO 27001 explicitly require continuous monitoring and evidence that controls are operating, and a NON_COMPLIANT status is exactly the artifact auditors look for.

How do I fix SSM.3?

  1. Open the failing association and read its execution history to find which step errored.
  2. Fix the underlying cause — missing permissions, an unreachable instance, or a bad document parameter.
  3. Re-run the association and confirm it reports COMPLIANT.
  4. Alert on association failures so drift surfaces before an audit does.

Remediation script · bash

# 1. AWS Config: bind to the service-linked role, record all resources, then start.
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
aws iam create-service-linked-role --aws-service-name config.amazonaws.com 2>/dev/null || true
aws configservice put-configuration-recorder \
  --configuration-recorder "name=default,roleARN=arn:aws:iam::${ACCOUNT}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig,recordingGroup={allSupported=true,includeGlobalResourceTypes=true}"
aws configservice start-configuration-recorder --configuration-recorder-name default

# 2. IAM Access Analyzer: create an external access analyzer in this Region.
aws accessanalyzer create-analyzer --analyzer-name external-access --type ACCOUNT

# 3. Systems Manager: enroll an instance role, then confirm it is managed.
aws iam attach-role-policy --role-name app-instance-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].{Id:InstanceId,Ping:PingStatus}' --output table

Full walkthrough (console steps, edge cases and verification) in the lesson Enable AWS security tooling (Config, Access Analyzer, SSM).

Part of the learning path See what's happening
  • SSM.1 Instances are not managed by Systems Manager, so no patching or audit
  • SSM.2 Instances are missing security patches
  • SSM.4 SSM documents can be shared publicly
  • SSM.6 SSM Automation runs are not logged
  • SSM.7 SSM documents can be shared publicly