ACSETalk to us
  1. Home
  2. Learn
  3. Automated remediation

Guide

Automated remediation, without the surprises

Automated remediation means closing a finding with little or no manual work. Done well, it shrinks the backlog. Done carelessly, it changes production without review and gets undone by the next deploy. The difference is in how the fix is made and where it lands.

Talk to usSee how it works
A fix you can readA storage bucket shown as an exploded drawing. Versioning and encryption are already in place; the public access block is the change ACSE proposes, as a draft pull request.VERSIONINGenabled · checkedPUBLIC ACCESS BLOCKthe fix · in a draft prDEFAULT ENCRYPTIONaws:kms · checkedaws_s3_bucket.data
01

Compare the approaches

Direct cloud writes, guided runbooks and fixes as code each trade speed against control.

02

Know what safe requires

A short list of properties separates a fix you can trust from one you hope works.

03

Keep fixes fixed

Changing the source, not the live resource, stops fixes from drifting back.

Approaches

Three ways teams automate fixes

01

Direct cloud writes

A function or bot changes the resource through the cloud API as soon as a finding appears. Fast, but it bypasses review and fights your infrastructure code.

02

Guided runbooks

Each finding comes with the commands to fix it, and a person runs them. Safe and reviewable, but slow at scale.

03

Remediation as code

The fix is written into the infrastructure code that owns the resource and opened for review. Versioned, reviewable and reversible.

The trap

Why direct writes backfire

Most cloud resources are defined in infrastructure as code. When a bot changes the live resource, the code still says the old thing. The next deploy puts the misconfiguration back, or the pipeline fails on drift.

Direct writes also skip the checks a team relies on: nobody reviewed the change, nobody knew what else depended on the resource, and there is no record an auditor can follow.

  • Drift between code and cloud
  • Unreviewed production changes
  • No reliable undo or audit trail
One fix, every consumerThree stacked modules: a core module, a line-of-business module and the composition that is exposed. The fix is made once in the core and carried through each layer under one approval.CORE MODULEthe fix lands here · v1.4.3LINE-OF-BUSINESS MODULEversion bumpedCOMPOSITIONthe app that is exposedONE APPROVAL · EVERY HOP

What safe requires

Six properties of a trustworthy fix

  1. It changes the sourceThe fix lands in the repository and module that own the resource, at a known commit.
  2. It is minimalIt changes only what the finding needs, so a reviewer can read the whole diff.
  3. It is tested before reviewA plan is run and the planned state is checked against the same policy that raised the finding.
  4. Its blast radius is statedWhat else the change touches is listed, along with what is still unknown.
  5. A person approves itSomeone accountable approves the exact change they reviewed, not a summary of it.
  6. It is verified afterwardsAfter deployment the resource is read again, and watched for a period, to confirm the outcome.
Detection across the estateChecks pass over every resource. Most pass; three fail and are labelled with the reason: public access, a plain HTTP listener, and storage not encrypted at rest.public accessplain http listenerunencrypted at restCHECKS RUN IN YOUR ACCOUNTread-only · on a schedule or on demand

How ACSE approaches it

Remediation as code, governed end to end

ACSE writes each fix from a remediation directive, applied by a deterministic patch engine, and opens it as a draft pull request in your repository. It runs terraform plan offline, re-checks the planned state against your policy and judges the blast radius before anyone reviews it.

A security approver confirms with step-up MFA, bound to the exact view they saw. ACSE never merges. After your pipeline deploys, ACSE re-reads the resource, watches it through an observation window and seals the record.

  • Draft pull request, signed patch or CLI runbook
  • Never a direct write to your cloud
  • Optional AI drafts go through the same chain
Nobody approves their own changeTwo people, a risk owner and a security approver, each confirm one change with step-up MFA. Neither of them wrote it.RISK OWNERSECURITY APPROVER✓ step-up mfa✓ step-up mfaONE CHANGEtwo people · neither of them the author

Questions

What people ask us

Isn’t a pull request slower than fixing it directly?

It adds a review, but it removes the rework. A fix in code stays fixed, passes your pipeline and leaves a record. A direct write often has to be made twice.

What about resources that aren’t in code?

Those need a person to act in the console or CLI. A good tool gives them the exact read-only checks and commands. ACSE shows these as a CLI runbook.

Should every fix be fully automatic?

Teams usually start with human approval on every change and widen automation as trust builds. ACSE requires a person to approve every fix today.

Keep reading

Related

Platform

Fix

ACSE turns a cloud misconfiguration into a validated pull request in your own Terraform, generated by rules and approved by a person. Never auto-merged.

ReadSolutions

Fix existing findings

Whoever detected the misconfiguration, ACSE turns it into a reviewed fix in your own code, verifies the cloud afterwards and keeps a signed record.

ReadLearn

Policy as code

Policy as code makes security rules versioned and testable. Learn where policies run, a healthy lifecycle, the common pitfalls and how to simulate first.

Read

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to usExplore the platform