SSM.4: SSM documents can be shared publicly

What does AWS Security Hub SSM.4 check?

SSM.4 fails when an SSM document owned by the account is shared publicly, with its Permissions attribute set to the special value "all" rather than private or shared with named account IDs. The check covers the documents you author, where a public setting is almost never intended.

Why does SSM.4 matter?

An SSM document is executable automation: patch runbooks, snapshot jobs, Automation workflows. A public document leaks its entire body: every step, parameter default, and comment, which commonly includes internal hostnames, bucket names, package-mirror URLs, and IAM role names. That hands an attacker both reconnaissance and a template for impersonation, supply-chain, and phishing attacks against your processes.

How do I fix SSM.4?

1. Find documents with public permissions (Permissions value "all") and remove the public share.
2. Re-share only with the specific account IDs that genuinely need them.
3. Enable the account-level block-public-sharing setting for SSM documents.
4. Audit document bodies for embedded secrets or internal identifiers before reuse.

# Close the highest-impact public exposure first: databases.
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --no-publicly-accessible --apply-immediately
  echo "$db: public access removed"
done

# Ratchet S3 shut at the account level so no bucket can be made public again.
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
    'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'