The same finding can have three correct answers. Where automation is safe, where it takes down production, and how to tell before anything runs.
Automated vulnerability remediation is the use of software to resolve security findings, such as patching a package, removing a permission or changing a configuration, with little manual work. Done well, it decides per finding whether a change is safe, runs safe changes through your own change process, confirms them with a rescan, and declines the rest in writing.
Detection got very good. Every misconfigured bucket, over-permissioned role and outdated package now shows up in a console within minutes. Closing them did not keep pace. In Tamnoon’s State of Cloud Remediation 2026 research, 53% of all findings ever detected across 14.86 million detections were still open, up from 41% a year earlier. A critical finding stayed open 150 days on average, up from 128. The same eight misconfigurations made up a fifth of all alert volume, and they kept coming back after they were closed.
The reason is rarely the scanner. It is the change. Every remediation is a change to production, every change has an owner, and nobody approves a change a machine cannot explain. So remediate buttons stay off, tickets age, and the backlog grows. Automated vulnerability remediation is the attempt to close that gap without trading a security risk for an outage.
Most products automate some of these steps. The ones that are safe to leave running do all seven, in this order.
Cloud security platforms, vulnerability scanners, container and identity tools all report the same environment differently. Remediation starts by putting them into one queue, each finding resolved to the asset it is about.
Many alerts describe one problem: the same misconfiguration on a hundred resources, or three findings that form one attack path. Across Tamnoon customers, 142 alerts resolve into one piece of work on average.
Who uses the resource, what depends on it, who owns it, what changed recently, what the access logs show. This is the step most automation skips, and the one that decides whether a change is safe.
Act, when the change is proven safe. Decline, when it cannot be, with the evidence and the manual path. Ask, when one fact is missing, naming the fact and the person who has it.
The approved change runs under an identity you grant, through the ticketing, pipeline and approval steps your organization already uses, with the rollback prepared before anything moves.
A change is not done when it runs. It is done when the scanner that raised the finding agrees the finding is gone.
Overrides and outcomes feed back, so the same class of finding gets the same answer next time, and a closed finding that reappears is caught.
“Automated remediation” covers three different designs. They fail in different ways.
| Scripts and playbooks | Remediate buttons and agents in a scanner | A decision engine | |
|---|---|---|---|
| What triggers a change | A rule matches an alert | A person clicks, or an agent acts on the scanner’s own finding | A verdict on each finding, from any scanner |
| Reads the environment first | Only what the script checks | Rarely beyond the alert | Usage, dependencies, ownership, recent changes |
| When it is not sure | Runs anyway, or fails | Leaves it to the person who clicked | Asks for the missing fact, or declines in writing |
| Who carries the risk | Whoever wrote the rule | The engineer who pressed the button | Proven before it runs; owners approve |
| The record | Logs | A ticket status | A written receipt for every yes and every no |
| How it usually fails | The rule outlives the environment it was written for | The buttons stay off because nobody wants to own the outcome | It starts slower: autonomy is earned class by class |
The same finding can have three correct answers. What decides is not the alert but what the environment says about the resource. These eight come from findings in Tamnoon’s own cloud.
| Finding | What to read first | What the answer turned on |
|---|---|---|
| A role grants a write permission it does not need | Ninety days of access logs; the buckets’ ownership settings; the deploy path | Never used, and cannot work on these buckets: safe to remove. |
| A bucket is readable by everyone | Who reads it: sites, emails, documents, a CDN | It serves the company logo; removing access breaks it everywhere. Put delivery behind a CDN first. |
| CDN responses lack security headers | The existing response-header and CORS policies | The quick option replaces the CORS policy and breaks the apps. The owner picks the route. |
| A secret has never been rotated | Every consumer; whether a tested rotation procedure exists | Fifteen consumers and no tested rotation. Map consumers, test once, then rotate. |
| Production queues lack customer-managed key encryption | Producers, peak volume, key-management limits | An unlisted producer could be throttled. Confirm the peaks, start with one queue. |
| A container image carries a vulnerable browser | How the image is built; whether its base has a patched package | No build pipeline to rebuild it with. Find the build method first. |
| An IAM role looks orphaned | Every policy that references it | One key policy could not be read. Deleting could leave a dangling principal. |
| Header findings on provider-managed endpoints | What each endpoint actually is | There is nowhere to set a header. Not actionable; record why. |
Changes that are safe to automate share three properties: the evidence that nothing depends on the current state can be read, the change is small and reversible, and a rescan can confirm it. Everything else needs a fact or a decision only a person has.
Want these verdicts on your own findings? Tamnoon reads the findings your scanner already raised, closes what Tamnoon can prove safe through your own controls, and declines the rest in writing with the evidence why. Book a demo →
It is as safe as what it reads before it acts. The failure mode has a name: autoimmune remediation, automation that fires changes without understanding the blast radius. The scanner is right that the finding exists; the change is wrong for the environment, and production pays.
Ask these six questions, word for word, of every vendor, including us.
A vendor that cannot show one decline from production has not solved the hard part.
Tamnoon is the self-healing engine for cloud exposures. Tamnoon proves each remediation safe and runs it through your own change process. The rest are declined in writing, with the evidence.
It takes findings from whichever scanner raised them and gives each one a verdict: SAFE, RISKY or AWAITING DATA, with the evidence it read. SAFE changes run through your change process, with owners approving and a rescan confirming. RISKY is a written decline. AWAITING DATA names the missing fact and asks the person who has it. Autonomy is earned per class of finding.
One customer’s quarterly reviews: 3x fewer open findings over four quarters (6,074 to 2,041), with 93% fewer new alerts arriving each quarter by the end.
Bring us your ugliest finding →
Software that resolves security findings, such as patching, removing permissions or changing configurations, with little manual work. Done well, it decides per finding whether a change is safe, runs safe changes through your change process, confirms them with a rescan, and declines the rest in writing.
Removing a permission a role never uses, rebuilding an image with a patched package through its pipeline, enabling encryption on a storage resource, moving a public bucket behind a CDN, rotating a secret once its consumers are known, and adding security headers through an existing policy. Each is safe only when the environment shows nothing depends on the current state.
It is as safe as what it reads first. Changes proven against usage, dependencies and ownership, run with a rollback ready and confirmed by a rescan, are safe to automate. Changes made on the alert alone are how automation breaks production.
Changes whose impact cannot be read from the environment: secrets with unknown consumers, resources other accounts depend on, vendor integration roles, resources defined in code but changed in the console, and production changes without a tested rollback.
Models that read evidence, plan a change and judge whether it is safe. Three tests separate useful from risky: the decision comes from your environment’s evidence, a reviewed procedure executes rather than code generated at run time, and every decision is written down for review.
Faster closure of the classes that are safe, fewer alerts per piece of work, consistent decisions across scanners, a record an auditor can read, and engineers spending their time on the findings that need judgment.
Remediation removes the vulnerability. Mitigation reduces exposure while it remains, for example with a compensating control. Both are changes; both should be proven safe before they run.
Vulnerability management finds, prioritizes and tracks. Remediation changes the environment. Most programs automated the first and left the second manual, which is why half of what gets found stays open.
It should. Ask a vendor for a verdict, in the same format, on a finding from a scanner it did not build. Tamnoon takes findings from whichever scanner raised them.
Source for market figures: Tamnoon, State of Cloud Remediation 2026, 14.86 million detections across hundreds of environments and ten cloud security platforms. Method and limitations on the report page.
Everyone automates the yes. We mastered the no.
Tamnoon reads the findings your scanner already raised, closes what Tamnoon can prove safe through your own controls, and declines the rest in writing with the evidence why.
