Weekly Amazon S3 bucket security audit posted to Slack

Every Monday at 8am, audit the security posture of every bucket in my Amazon S3 account and report the risks to my team in Slack. Use a cron trigger for the schedule.

Start with List Buckets to enumerate every bucket in the account. Then, for each bucket, read Get Public Access Block, Get Bucket Policy Status, Get Bucket Policy, Get Bucket Encryption, Get Bucket Versioning, Get Bucket Logging and Get Bucket Ownership Controls.

Judge each bucket against this safe baseline: public access fully blocked with all four Block Public Access settings enabled, default encryption on, versioning enabled, server access logging on, and a bucket policy containing no statement that grants access to a wildcard principal and no statement that permits plain HTTP instead of requiring secure transport. Object Ownership set to BucketOwnerEnforced is the safe setting, because it disables ACLs as a second route to public access.

Keep this workflow strictly read only. Never call any Put or Delete operation, even when a fix looks obvious. The report recommends and the human decides.

Treat a missing configuration as a finding rather than an error. S3 returns NoSuchBucketPolicy, ServerSideEncryptionConfigurationNotFoundError or NoSuchPublicAccessBlockConfiguration when a setting was simply never configured, which is exactly the risk worth flagging. Catch those specific errors, record them as findings, and carry on to the next check instead of failing the run.

Grade every finding so the report can be ordered worst first. Critical means the bucket is actually reachable by the public, either because the policy status reports it as public or because the policy grants a wildcard principal without a condition that meaningfully restricts it. High means missing default encryption, an incomplete Block Public Access configuration, or a policy that allows plain HTTP. Medium means versioning off, server access logging off, or ACLs still enabled. A bucket's overall severity is that of its worst finding.

List Buckets returns buckets from every region, but the credential carries a single region, so a bucket outside that region returns 301 PermanentRedirect. When that happens, read the correct region from the x-amz-bucket-region response header, which Head Bucket also returns, and retry that bucket against its real region. Never drop a bucket silently. A bucket that still cannot be read after the retry is an unaudited bucket, so report it under a could not check heading rather than counting it as passing.

Post one Slack message using the Slack Bot Send a Message operation, so the report comes from a bot identity rather than from me personally. List only the buckets that fail, ordered worst first, with one plain sentence per bucket saying what is wrong and why it matters, for example that a bucket is readable by anyone on the internet and could leak whatever is stored in it. Write for someone who is not an AWS expert: no operation names and no raw policy JSON. Put any could not check buckets in a short section at the end. If nothing fails, post a single all clear line naming how many buckets were scanned, so the team knows the audit ran.

Then append one row per run to my Google Sheets audit log with Append Values, recording the run date, how many buckets were scanned, how many failed, the count of findings at critical, high and medium, and how many buckets could not be checked. Use USER_ENTERED so the date lands as a real date. Always append and never overwrite earlier rows, so the trend is visible over time and the sheet doubles as evidence for compliance reviews.