Working definition
Automated does not mean automatic.
Automated infrastructure remediation is the execution of defined change logic against a scoped infrastructure target, followed by a retained result that can be checked against the intended state. In GAEZLA, this is currently expressed through supported hardening benchmarks and their assigned targets.
A scanner finding does not start that execution by itself. An operator selects an applicable benchmark path, reviews the effective control scope, and confirms a remediation run. A completed run is also not the same as a verified fix: control results and verification evidence determine what actually happened.
Separate records
Observation, assessment, execution, and verification are different facts.
Keeping these records separate prevents a recommendation, queued job, or completed run from being presented as proof that the desired infrastructure state was reached.
| Record | What it establishes | What it does not establish |
|---|---|---|
| Scanner finding | The configured scanner observed an issue on an asset and returned evidence or remediation guidance. | That a supported hardening control exists, a change ran, or the finding is fixed. |
| Hardening audit | The applicable controls returned pass, fail, skipped, not-applicable, unsupported, or error state. | Permission to mutate the target or proof that a later remediation succeeded. |
| Remediation run | Supported change logic was requested for a defined assignment and control scope. | That each control was attempted successfully or reached its desired state. |
| Verification evidence | The returned before, desired, and after state and any structured failure stage. | Automatic closure of a separate scanner finding or universal proof beyond the retained result. |
Remediation path
From observed risk to a reviewable outcome.
This is the GAEZLA hardening path. It does not imply that every scanner finding maps to a benchmark control or that every configured executor can change target state.
- 01
Keep the observation intact
GAEZLA can retain a configured scanner’s asset finding, evidence, guidance, and source-run provenance. That record is an observation, not executable authority.
- 02
Choose a supported benchmark path
Review the benchmark’s executor capability and target applicability. Remediation remains unavailable where the executor supports audit only.
- 03
Scope the target and controls
Use the assignment, global control state, per-target overrides, parameters, and optional selected-control list to define the requested work.
- 04
Confirm and dispatch
The product interface asks the operator to confirm a remediation run. Supported agent work is then baked into a signed payload and placed on the target’s visible queue.
- 05
Retain the returned result
The result keeps run mode, target assignment, status, per-control outcomes, and bounded evidence returned by the executor.
- 06
Review verification separately
Before, desired, and after snapshots can show whether the observed state matched the intended state; structured errors preserve where the attempt failed.
Supported scope
The executor capability decides whether remediation is available.
Agent-based hardening
Audit and supported remediation.
Agent-playbook benchmarks can expose audit and remediation. The assignment identifies the agent target, the effective controls are baked into the workload, and signed work is queued for execution.
API-based hardening
Audit-only today.
Current API-based hardening executors expose audit capability but reject remediation mode. The benchmark surface reports the capability instead of presenting a write path that is not implemented.
Selected controls
Scope can be narrower than the benchmark.
A run can carry a selected list of controls. The service validates that each selected control belongs to the assignment’s benchmark and rejects the request if that scope changes before execution.
Evidence model
A successful request and a verified desired state are not interchangeable.
Returned hardening evidence is validated and bounded before storage. For remediation, the per-control record can preserve the attempted operation, its target, and the state observed around the change.
Before
What state was observed?
The pre-change snapshot can retain a bounded value and whether the target value existed.
Desired
What state was requested?
The desired snapshot makes the intended result inspectable instead of leaving it implicit in a script.
After
What state was returned?
The after snapshot can be compared with the desired value while retaining a distinct remediation outcome.
Failure stage
Where did the attempt stop?
Precondition, write, and verification errors remain distinguishable, with bounded error code and message context.
Failure is evidence
Unsupported and unsuccessful outcomes remain visible.
Unsupported executor
The relevant executor cannot perform the requested control or remediation operation.
Authentication or permission failure
The target path could not authenticate or did not have the authority required for the operation.
Precondition or write failure
The attempt did not pass its prerequisite or could not apply the requested value.
Verification failure
A write may have been attempted without the returned after state establishing the desired result.
Control still failed
A run can finish while individual controls retain failed or other non-passing outcomes.
Boundaries
What the GAEZLA remediation path does not promise.
No automatic finding-to-fix chain
Scanner findings and hardening assignments remain separate records. A finding does not silently trigger a remediation run or close itself afterward.
No universal benchmark coverage
Remediation depends on an applicable benchmark, a supported executor, a valid assignment, effective controls, and a reachable authorized target.
No guaranteed successful change
Execution can return unsupported, authentication, permission, control, write, or verification failures that require operator review.
Evaluation checklist
Questions to ask before automating infrastructure remediation.
- Which source produced the observation, and is its provenance retained?
- Does an applicable hardening benchmark exist for the target?
- Does the benchmark executor support remediation or audit only?
- Which assignment, controls, overrides, and parameters define the change?
- How does the operator distinguish audit from state-changing remediation?
- How is work signed, queued, and restricted to the intended target?
- Are before, desired, after, outcome, and failure stage retained per control?
- Can a completed run remain visibly non-compliant when controls fail?