Skip to main content
emnode / learn
Compliance Critical severity

AWS Security Hub · SSM

SSM.4: SSM documents can be shared publicly

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SSM.4 check?

SSM.4 fails when an SSM document owned by the account is shared publicly — 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.

Remediation script · bash

# 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'

Full walkthrough (console steps, edge cases and verification) in the lesson Block public access to AWS resources.

Is SSM.4 a false positive?

If you deliberately publish a sanitised document to the AWS community, it will still flag — the control treats any public document as a finding, so keep public copies free of internal detail and accept or suppress the finding knowingly.

Part of the learning path Trim your network spend
  • SSM.1 Instances are not managed by Systems Manager, so no patching or audit
  • SSM.2 Instances are missing security patches
  • SSM.3 SSM associations are non-compliant
  • SSM.6 SSM Automation runs are not logged
  • SSM.7 SSM documents can be shared publicly