Opinion
The remediation race is over, and attackers won
"Attackers need minutes to turn a cloud misconfiguration into a breach," writes Neta Rozy, co-founder and CEO of Era Security. "No remediation process, human or automated, will ever be fast enough."
I've spent more than a decade in the cloud, learning its ins and outs and how much depends on a solid, secure foundation. The lesson that keeps repeating itself is how little it takes to bring that foundation down. Most cloud breaches don't start with a clever exploit. They start with a key left in a public storage bucket, a role with far more permissions than it needs, or a service nobody meant to expose to the internet.
None of this is a secret. Cloud security tools flag these problems every day, and the industry's answer has always been remediation: find the issue, prioritize it, open a ticket, fix it. The assumption is that if you fix fast enough, you stay ahead. Even before AI, that assumption didn't hold. The remediation we had was never good enough. Fixes were partial, tickets were closed as "accepted risk," and the next deployment often brought the same misconfiguration right back.
Then AI arrived on the attackers' side. An attacker who finds an exposed key can now go from first access to full control of a cloud account in under ten minutes. In an AI-assisted intrusion documented by Sysdig, credentials left in a public storage bucket let an attacker rewrite code running in the environment and gain administrator access.
Fixing a single cloud security issue still takes around ten days at a typical large enterprise, and up to 35 at a mid-size company. Intruder measured these times across 3,000 organizations. Ten minutes against ten days. That race is over, and attackers won. And no team closes that gap by working harder, for two reasons.
First, the queue never empties. Every deployment creates new identities, storage, keys and network paths, and weak identity controls show up in 98% of large enterprises. Teams fix yesterday's findings while engineering creates tomorrow's. Fix an overly broad permission in production but leave it in the deployment template, and the next deployment brings the problem back.
Second, critical fixes still need a person. Tightening a permission or closing a port in production can take down the application that depends on it, so someone has to review and approve the change. That caution is reasonable. It's also the window attackers use. Their AI doesn't wait for a change-approval meeting and doesn't mind failing nine times out of ten. It needs one exposed key to work once. Defenders need every fix to work, everywhere, without breaking anything.
Even if autonomous remediation worked perfectly, it would still act after the misconfiguration existed and the window had opened. A tool that closes a gap in an hour beats a ticket that closes it in a month. Against a ten-minute attack, it's still fifty minutes too late.
The way out is to stop racing. Instead of fixing problems faster, make them impossible to create, and make the ones that slip through worth less to an attacker.
That starts with guardrails: rules applied across every cloud account that block public storage, deny permissions that allow privilege escalation and refuse to issue long-lived access keys. Most organizations are nowhere near this. Our research team found that most cloud environments have fewer than 5% of the guardrails they need to stand up to AI-driven attackers.
Then harden what's left. Strip permissions nobody uses. Replace permanent keys with short lived credentials. Close internet exposure by default. When a key leaks, and one will, it should open almost nothing. If an application only needs to read one dataset, its credentials should grant exactly that access. Giving it permission to change other identities or rewrite unrelated services gives an attacker room to move that the application never needed.
The number of open findings will never be small enough to matter against a ten-minute attack. The number of identities that can reach administrator access can go to zero. For each identity, that means tracing whether its permissions let it assume another role, change that role's permissions or create a new privileged identity. A role that looks limited on its own may still give an attacker a route to administrator access.
Breaking will always be faster than fixing. The organizations that come out ahead will be the ones with the least left to fix.
Neta Rozy is co-founder and CEO of Era Security.
