ACSETalk to us
  1. Home
  2. Platform
  3. Fix

Remediation as code

The fix arrives as code your team already reviews.

ACSE writes the change to your own infrastructure code and opens it as a draft pull request, already validated against a plan and your policy. Your engineers review it the way they review everything else. Nothing touches your cloud until you merge.

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

Fewer findings, not more tickets

Each finding comes with the change that closes it, so the backlog shrinks instead of moving to another queue.

02

No surprise changes in production

Fixes land in your repository and go through your pipeline. ACSE never writes to your cloud directly and never merges for you.

03

A fix you can read before it runs

Every pull request shows what it changes, what it was tested against, its blast radius and how to undo it.

From finding to pull request

How a fix is made

Fixes are generated from remediation directives: rules that describe the change, applied by one deterministic patch engine. There is no model improvising your infrastructure at runtime.

  1. Find the sourceACSE resolves which repository, file and module own the misconfigured resource, at an exact commit.
  2. Write the changeThe patch engine applies the directive for that check, guided by the provider’s schema, so the edit is precise and minimal.
  3. Prove it before reviewACSE runs terraform plan offline with pinned versions, re-checks the planned state against your policy and judges the blast radius against a versioned guardrail profile.
  4. Open a draft pull requestThe change opens as a draft PR at that commit, with the evidence of each check attached. A person approves it in ACSE with MFA; then your team merges as usual.
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

Layered modules

Fix it once, in the module that owns it

In large estates the exposed resource is rarely where the problem lives. It comes from a core module, consumed by a line-of-business module, composed into the application.

ACSE maps that chain and proposes a change set: the fix in the core module, with version bumps through every layer that consumes it, under one approval. Teams that only want their own composition fixed can choose that instead.

  • Dependency map with the full list of consumers
  • One approval bound to the whole change set
  • Progress tracked hop by hop, read-only
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

Every kind of resource

There is always a next step

Not every resource lives in code. ACSE still gives your team a precise, reviewable way to close the finding.

01

Terraform pull request

For resources managed in Terraform on GitHub: a draft PR at the exact commit, validated before review.

02

Signed patch

For repositories ACSE can’t open pull requests in: a signed patch your team applies, tracked by its patch id.

03

CLI runbook

For resources created in a console: the exact read-only checks and the commands to fix them, shown for a person to run.

Our rule

ACSE never calls a change safe. It says what is known, what is not, and how to undo it.

Every approval view carries the blast radius, unresolved dependencies, residual uncertainty and the recovery plan.

Questions

What people ask us

Does ACSE ever change my cloud directly?

No. Fixes are delivered as code into your repositories, or as a runbook for a person to follow. Your pipeline applies them after your team merges.

Is the fix written by AI?

No. Fixes come from remediation directives applied by a deterministic engine. If you turn on ACSE’s optional AI, it can draft a patch for a finding with no directive, and that draft goes through exactly the same validation, guardrails and human approval.

What if a fix is wrong?

Every approval view includes how to undo the change, and after the merge ACSE re-reads the resource to verify the outcome rather than assuming it. If the state drifts during the observation window, the case reopens.

Which repository platforms are supported?

GitHub with Terraform today, and Terraform Cloud’s private registry for module chains. GitLab, Bitbucket, Azure DevOps and Pulumi are planned.

Keep reading

Related

Platform

Approvals and governance

Every ACSE fix needs a person’s approval with step-up MFA, bound to the exact view they saw. Authors don’t approve their own changes, and two people where policy says.

ReadSolutions

IaC security

ACSE fixes cloud misconfigurations in the Terraform that owns them, as validated draft pull requests or signed patches, so your code and cloud stay in step.

ReadPlatform

Evidence

ACSE records every step of every fix in a signed, hash-chained, append-only record in your own account, which an auditor can verify offline.

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