ARE — Autonomous Remediation Engine

The Autonomous Remediation Engine (ARE) takes a finding, reads the source code, writes a fix, builds it, verifies it against 7 scanners in 3 passes, and creates a Change Request if all checks pass. It uses claude-opus-4-8 for code analysis and patch generation.

What the ARE does and does not do

Does:

• Read actual source code (not just metadata)
• Generate working code patches (unified diff format)
• Build and compile the patched code
• Run 3 scanner passes to verify the fix is effective and introduces no regressions
• Create a Change Request for CCB approval
• Route dual PRs: one to the compliance vault, one to the customer's staging branch

Does not:

• Deploy to production (requires CCB approval and human review)
• Fix all finding types (structural refactors and PS/PE/AT controls require human work)
• Guarantee fixes for proprietary or obfuscated codebases
• Work without write access to the repository

The 11-Step Pipeline

These steps are derived from the orchestrator source. Every step is logged to remediation_job_steps in the database.

The 3 Verification Stages

The ARE applies the "fail-closed" principle: a fix that cannot be fully verified is not promoted to a Change Request.

If Stage 2 or Stage 3 fail, the job status is set to failed and a failure reason is recorded. No Change Request is created.

The 7 Scanners

All scanners run in parallel within each stage. Scanner output is normalized to a common schema before comparison.

All 7 scanners run in parallel. A scanner that times out or is unavailable logs a warning and yields zero findings — it does not fail the job. Grype always runs and cannot be disabled.

Build System Support

The ARE auto-detects build systems using recursive manifest discovery:

Workspace-aware discovery handles monorepos — each build unit is identified and built independently.

Fix Strategy Types

The AI selects one of six fix strategies based on finding type:

Job Lifecycle

Job created (status: pending)
      │
      ▼
status: scanning  (Steps 1–4)
      │
      ▼
status: analyzing  (Step 5)
      │
      ▼
status: patching  (Steps 6–7)
      │
      ▼
status: verifying  (Steps 8–10)
      │
      ▼
status: awaiting_approval  (Step 11 — CCB Change Request created)
      │
      (CCB approves)
      ▼
Dual PR routing:
  → Compliance vault internal PR (evidence)
  → Customer staging branch PR (code)

Fail-Closed Behavior

If any step fails, the job moves to failed status with a failure_reason. Failure reasons are logged to both remediation_job_steps and CHRONICLE. No code is pushed to any branch when a job fails.

Common failure reasons:

Change Control Board (CCB) integration

The ARE does not push code directly to any branch after verification. Instead, it creates a CCB Change Request and waits for approval. This is not a safety shortcut — it is the compliance-correct behavior under CM-3.

The Change Request created at Step 11 includes:

• The finding being remediated (scanner, CVE ID or rule ID, severity)
• The diff that will be applied
• Stage 1, 2, and 3 scanner results
• Build verification logs
• Risk assessment generated by the AI
• RAMPART gate check results for the sandbox branch

The CCB reviews these artifacts before approving. On approval, the ARE routes dual PRs.

Dual-PR routing and compliance significance

Every approved remediation creates two pull requests:

Why two PRs?

The separation between compliance evidence and customer code is intentional. The vault PR preserves a signed, immutable record of the remediation — what was found, what was fixed, and when — regardless of what happens to the customer's repository. If the customer modifies the fix before merging, or does not merge it at all, the vault PR still documents that a working, verified fix was generated.

This separation satisfies CM-3(b) (which requires maintaining records of change requests and their disposition) independently of whether the change is applied.

Finding types the ARE can and cannot fix

Can fix autonomously:

Cannot fix autonomously (requires human work):

Confidence threshold

The ARE uses a confidence score (0.0–1.0) to decide whether to attempt a structural_refactor fix strategy. For all other strategies, it attempts the fix regardless of confidence. For structural_refactor:

• Confidence ≥ 0.85: Attempt the fix
• Confidence < 0.85: Report insufficient_confidence and exit gracefully without creating a PR

This threshold prevents the ARE from making large, complex code changes when it cannot reliably predict the outcome.

Prerequisites

• REAEGIS GitHub App installed on the repository with write access
• Repository has at least one build manifest (package.json, go.mod, requirements.txt, etc.)
• Finding is of a type that the ARE can remediate (SCA CVEs, code patterns, IaC misconfigs, secrets)

Monitoring ARE jobs

ARE jobs are visible in the Remediation tab of each finding. Each job shows:

• Current status (pending, scanning, analyzing, patching, verifying, awaiting_approval, completed, failed)
• Step-level logs for each of the 11 pipeline steps
• Scanner output from all 3 stages
• The generated diff (viewable inline before CCB approval)
• Links to the sandbox branch and Change Request

Failed jobs include a failure_reason that explains which step failed and why. The most common failure reasons and their remediation:

Related pages

• RAMPART Engine — How findings are created
• GitHub Integration — GitHub App permissions required for ARE
• CHRONICLE Engine — How ARE steps are audit-logged
• Change Control — CCB workflow and Change Request lifecycle