Background
Growth that outran the security review
The platform had grown quickly, and its cloud environment had grown with it, without a deliberate security review along the way. The engagement began when a credential used by the platform was exposed through a third-party service and abused by an attacker.
The incident itself was contained quickly. The harder finding was what the investigation surfaced underneath it.
The problem
Structural issues that made the leak dangerous
The exposure was not just bad luck. Four structural gaps had made it possible and would have made any future leak just as damaging:
Long-lived credentials on disk
Production servers held static AWS credentials in plain configuration files.
One key, broad reach
A single access identity carried wide permissions across many unrelated services.
No documentation
The environment had no map - nobody could reason about what a leak could actually reach.
No incident playbook
No record of what normal looked like, and no defined response when it did not.
The solution
A full review and remediation, described at a high level
Every change was designed so it could be verified and, where relevant, rolled back, and was carried out with no disruption to the running service.
Removed long-lived credentials from production
The application was migrated to workload identity. Production servers now obtain short-lived, automatically rotated credentials and hold no static secrets on disk.
Replaced broad access with least privilege
The single over-privileged identity was split into a set of single-purpose identities, each limited to exactly one function with the minimum permissions it needs.
Hardened critical data
Tamper-resistant protections were added to the most important data stores, including versioning and delete protection, so accidental or malicious deletion cannot cause irreversible loss.
Documented the environment
Complete documentation of the cloud setup was produced from scratch, along with an incident timeline and a remediation record.
The result
A documented, defensible baseline
The platform moved from a state where one leaked key could cause broad damage to a least-privilege environment with no long-lived secrets on disk, tamper-resistant critical data, and complete documentation.
Before
- Static credentials sitting on production disks
- One identity with reach across the platform
- No map of the environment
- No incident playbook, no baseline
After
- Short-lived, auto-rotated credentials, none on disk
- Blast radius contained to one narrow function
- Critical data protected against deletion
- Full documentation and a remediation record
The blast radius of any future credential exposure is now contained to a single narrow function, and the team has, for the first time, a documented and defensible baseline to operate from.
Services applied