ACSETalk to us
  1. Home
  2. Solutions
  3. IaC security

IaC security

Security fixes that land in your Terraform, not around it.

When your cloud is defined in code, a fix made in the console is drift waiting to be undone by the next apply. ACSE writes the fix into the code that owns the resource, tests it against a plan, and opens it as a draft for your team to review like any other change.

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

No drift from security fixes

The fix lives in your code, so the next pipeline run keeps it instead of reverting it.

02

Reviews in the tools you use

Your engineers see a draft pull request in their own repository, with the evidence of each check attached.

03

One fix for every consumer

When a shared module causes the problem, ACSE fixes it there and carries the change through each layer that uses it.

From finding to code

How the change is made and checked

  1. Trace the resource to its sourceACSE finds the repository, file and module that define the resource, at an exact commit. Resources without code are labelled as console-created.
  2. Apply the ruleA deterministic patch engine applies the remediation directive for that check, guided by the provider’s schema.
  3. Validate offlineACSE runs terraform plan with pinned versions, re-evaluates the planned state against your policy and judges the blast radius.
  4. Follow it to productionAfter the merge, ACSE observes the pipeline run and compares the plan your pipeline publishes with the plan it validated.
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 core module

In large estates, an exposed resource usually comes from a core module, consumed by a line-of-business module and composed into an application. Fixing only the application leaves every other consumer exposed.

ACSE maps the chain through your private module registry and proposes a change set: the fix in the core module, with version bumps through each layer, proven end to end before one approval.

  • Full list of consumers before you approve
  • One approval bound to the whole change set
  • Or fix only your own composition, if you prefer
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

Delivery

Choose how fixes reach your code

Set delivery per repository. Validation, approval and evidence are the same either way.

01

Draft pull request

ACSE opens a draft at the exact commit. After approval it marks the PR ready for review; your team merges.

02

Patch only

For repositories where ACSE has read-only access: a signed patch you apply. ACSE matches your own PR to it by content.

03

Runbook for console resources

For resources not managed by code, the read-only checks and CLI commands a person runs.

Kubernetes

Manifests get the same treatment

For workloads on Kubernetes, ACSE patches the manifest that defines them, whether plain YAML, Helm values or Kustomize, and dry-runs the result offline against the API schemas before review.

The fix follows the same chain as Terraform: rules write it, tests prove it, a person approves it, your pipeline applies it.

Kubernetes, fixed in the manifestA cluster of three nodes with their pods. One pod runs a privileged container; the fix is a patch to its manifest.privileged containerMANIFEST PATCHsecurityContext:- privileged: true+ privileged: falseCLUSTER · NODES · PODS

Questions

What people ask us

Which IaC and repository platforms are supported?

Terraform on GitHub, with Terraform Cloud’s private registry for module chains. Other repository platforms and IaC tools are planned.

Does ACSE scan our pull requests before deployment?

ACSE evaluates your running cloud and the planned state of the fixes it proposes. It is not a pre-merge scanner for every change your team makes.

Will ACSE ever merge a pull request?

No. Every pull request opens as a draft, a person approves it in ACSE with step-up MFA, and your team merges it.

Is the code written by AI?

No. Fixes come from remediation directives applied by a deterministic engine. Optional AI can draft a patch for a finding with no directive, and that draft passes the same validation and approval.

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.

ReadClouds

Kubernetes

ACSE checks Kubernetes workloads and managed clusters for risky settings and fixes them in your YAML, Helm values or Kustomize overlays, dry-run before review.

ReadPlatform

Integrations

ACSE works with the tools your teams already use: GitHub and Terraform for fixes, your OIDC identity provider for sign-in and MFA, Teams and your SIEM.

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