How We Built Tenant Isolation for hackaws.cloud. And How Dam Secure Finds What We Miss
hackaws.cloud is an autonomous AWS penetration testing platform. Customers connect their AWS accounts, configure a foothold identity, and our agent performs real lateral movement and privilege escalation, building a live attack graph as it works.
That means we store AWS account IDs, IAM role ARNs, assumed-role credentials, and full attack path graphs. If tenant isolation fails, one customer could see another customer's AWS infrastructure map, or perform confused deputy attacks to assume roles in other customers' accounts. In an extreme scenario, chained with another bug, an attacker could even access stored credentials. The stakes are about as high as they get for a multi-tenant SaaS.
Tenant isolation isn't new territory for us. At Plerion, where I'm Chief Innovation Officer, we face the same class of problem: our cloud security platform ingests customer cloud configurations, vulnerability data, and identity graphs across thousands of accounts. The compliance requirements alone (SOC 2, ISO 27001) demand rigorous tenant boundaries. hackaws.cloud gave us a greenfield opportunity to apply those lessons from day one rather than retrofitting them.