Public S3 Bucket, SSRF, and Long-Lived CI/CD Keys
A startup runs a containerized Node.js application on AWS. A researcher reports that a 220 GB S3 bucket containing customer PII is publicly readable because a contractor applied an overly broad bucket policy. The application has an SSRF flaw that can reach IMDSv1 and retrieve the instance role’s temporary credentials; that role allows s3:* on the bucket and ec2:Describe*. The CI/CD pipeline stores static AWS access keys in GitLab variables, and three former engineers still have maintainer access. The WAF is in count mode. A SOC 2 audit is 30 days away, and the customer contract requires breach notification within 72 hours of confirmed unauthorized access. You must sequence emergency remediation, decide whether notification is triggered, and propose an auditable 30-day fix.
1. Sequence emergency remediation without breaking production while preserving evidence. Justify the order.
Read the worked answer
Stop exposure first, preserve evidence second, fix root cause third.
- Immediately apply S3 Block Public Access at the account and bucket level, then replace the overly broad bucket policy with a least-privilege policy. Do not delete the bucket or objects; that destroys evidence. Enable server access logging and CloudTrail data events if not already on, but do not wait for logging before blocking exposure.
- Revoke the instance role’s temporary credentials by stopping or rotating the instance profile, and remove s3:* and ec2:Describe* from the role. Enforce IMDSv2 on all instances. A temporary network block can reduce SSRF reachability while the application fix is developed.
- Rotate the static CI/CD keys immediately, remove former engineers’ maintainer access, and audit pipeline logs for unauthorized use. Move to OIDC federation rather than long-lived keys.
- Put the WAF into blocking mode for the SSRF pattern if it can be done without breaking legitimate traffic; otherwise add a virtual patch at the reverse proxy.
- Preserve S3 access logs, CloudTrail, CI/CD audit logs, and the researcher’s report before remediation changes obscure them.
Order matters because public exposure is ongoing; evidence preservation should not delay blocking public access.
2. Was the 72-hour breach notification triggered? What facts determine the answer, and how would you handle missing or inconclusive logs?
Read the worked answer
Notification is triggered by confirmed unauthorized access to covered data, not by the mere existence of a public bucket. The facts needed are:
- S3 server access logs and CloudTrail data events showing GET requests from outside the company, especially unfamiliar IPs or high-volume enumeration.
- Whether the bucket was indexed or referenced publicly, and whether the researcher downloaded or only viewed objects.
- CloudFront or application logs if the bucket was accessed through the app.
- The data classification and residency of the 220 GB, and whether encryption keys were also exposed.
If logs show external GETs, treat as confirmed unauthorized access and start the 72-hour clock after counsel review. If logs are missing or inconclusive, do not declare no breach; document the uncertainty, preserve what exists, and consider notification based on legal advice and contract terms. The SSRF and role credentials add a second path: check CloudTrail for role assumption and S3 access from the instance role outside normal patterns. Do not wait for the SOC 2 audit to decide. The decision, evidence, and counsel’s advice should be recorded.
3. Propose an auditable 30-day remediation plan that addresses the audit deadline and reduces recurrence risk.
Read the worked answer
Make the 30-day plan auditable and tied to the audit controls.
- Week 1: block public access, least-privilege bucket policy, rotate CI keys, remove former maintainers, enforce IMDSv2, and preserve logs. Produce a timeline and evidence package.
- Week 2: remediate SSRF in code with URL allowlisting and metadata endpoint blocking; add WAF blocking rules and test them. Add pre-merge IaC scanning for public bucket policies and IAM wildcards.
- Week 3: move CI/CD to OIDC federation with short-lived credentials; apply least privilege to the instance role; enable CloudTrail data events and S3 access logging centrally.
- Week 4: access review for all maintainers and IAM roles; tabletop the breach notification process; retest SSRF and public exposure with an external scan; collect evidence for the auditor.
Audit evidence should include policy diffs, scan results, ticket approvals, test output, and access review sign-offs. Do not rely on a screenshot of a setting; show continuous enforcement through automated checks and alerts. The goal is not a one-time cleanup but preventing recurrence before and after the audit.