ankos remediate

ankos remediate reads an evidence directory produced by ankos scan, analyzes the findings, and emits remediation output in several formats. Use it to drive a sprint of work, generate infrastructure-as-code starter files, hand a prioritized list to someone unfamiliar with the underlying AWS services, or export the work as tickets for your own tracker — all free and local.

Synopsis

ankos remediate <evidence-dir> [flags]

Quick start

# Per-finding suggestions with AWS CLI commands (default)
ankos remediate ./ankos-evidence-20260526-153045

# Generate Terraform HCL files for each finding
ankos remediate ./evidence --format terraform -o ./fixes/

# Generate Kubernetes manifests
ankos remediate ./evidence --format kubernetes -o ./k8s/

# Sprint-based plan with effort estimates for a team of 3 on 2-week sprints
ankos remediate ./evidence --format plan --team-size 3 --sprint-weeks 2

# Same, but anchored to a specific target audit date
ankos remediate ./evidence --format plan --target-date 2026-09-15

Flags

Format + output

Filtering

Plan-format specific

Misc

Output formats

cli (default)

Per-finding suggestions with concrete AWS CLI commands you can run (after review) to fix each issue. Severity-prioritized, with PCI requirement mapping inline.

Example output (abbreviated):

CRITICAL  S3 bucket public access disabled
          PCI 1.3 — Restrict inbound traffic
          Fix:
            aws s3api put-public-access-block \
              --bucket my-bucket-name \
              --public-access-block-configuration \
                "BlockPublicAcls=true,IgnorePublicAcls=true,..."

HIGH      KMS key rotation not enabled
          PCI 3.7 — Cryptographic key management
          Fix:
            aws kms enable-key-rotation --key-id <key-arn>

This format prints to stdout by default. Pipe to less or redirect to a file for review.

terraform

Generates a tree of .tf files — one per AWS service area — that you can drop into a Terraform module and terraform plan against your state. Resources are written with lifecycle blocks and clear naming so a reviewer can decide what to apply.

ankos remediate ./evidence --format terraform -o ./fixes/
ls ./fixes/
# iam.tf  s3.tf  kms.tf  vpc.tf  ...

With --module-style, each service area gets its own subdirectory with main.tf / variables.tf / outputs.tf — drop them into your existing modules tree.

kubernetes

Generates Kubernetes YAML manifests for findings relevant to EKS or ECS workloads (pod security policies, network policies, secret rotation jobs, etc.). Same layout — one file per concern area.

plan

A sprint-by-sprint remediation roadmap with effort estimates, dependencies, and an explicit owner column ready for assignment. Sized to your team:

ankos remediate ./evidence --format plan \
  --team-size 3 --sprint-weeks 2 --target-date 2026-09-15

Plan output groups findings by:

1. Severity — critical/high first
2. Effort estimate — small (under 1 day), medium (1-3 days), large (1 week+)
3. Dependencies — if a fix depends on another fix, they're sequenced

When --target-date is set, the plan back-schedules from that date. If there's not enough capacity (team size × weeks × sprint count) to cover the critical+high findings before the date, the plan flags the gap explicitly so you can argue for more headcount or a date slip.

csv, markdown, json — export to your tracker

The same task list as plan, rendered for import into wherever your team already tracks work. No account, no upload — fully local and free.

# CSV — import into Jira, Linear, Asana, monday, or a spreadsheet
ankos remediate ./evidence --format csv -o tasks.csv

# Markdown checklist — paste into a GitHub/GitLab issue, Notion, or a doc
ankos remediate ./evidence --format markdown -o tasks.md

# JSON — the full plan for scripts and pipelines
ankos remediate ./evidence --format json -o plan.json

The CSV has one row per task with Summary, Description (the fix plus the QSA "why"), Priority (mapped to Highest/High/Medium/Low), Issue Type, Labels, PCI Requirement, Estimate (hours), and Sprint — column names most importers recognize, with mapping on import for the rest. The four manual policy items (incident response, security policy, training, vendor assessments) come through under a Manual sprint so they aren't lost.

These exports are stateless by design: the CLI never tracks "done." Your tracker owns assignment and completion; re-run a scan and the items you've fixed simply drop off the next export.

--seed-ledger — push tasks onto your Ankos Ledger (Team)

On the Team plan, skip the export/import round-trip: push the plan's tasks straight onto the matching entries of your active Ledger cycle as checklist items.

ankos remediate ./evidence --seed-ledger

Each task is matched to the ledger entries for its PCI requirement and added as a checklist item (carrying its severity and effort estimate). The command reports exactly what landed — including any tasks it couldn't map to an entry, so nothing is silently dropped:

✓ Seeded 23 task(s) into cycle 2026-Q2 as checklist items (4 already there).

⚠ 2 task(s) didn't map to a ledger entry, so they weren't seeded:
    • Rotate exposed access key (PCI 8.3.1)
    • Document key-management procedures (PCI 3.6)
  These are usually findings outside your current cycle's scope.

Like the file exports, seeding is stateless and idempotent: the CLI never marks tasks done. Re-scan and re-run to refresh — items already present are left untouched (including ones your team has checked off), and findings you've fixed simply stop being added. Completion lives in the Ledger.

Requires an API key (ankos auth set-key) and an active Team plan, plus an active assessment cycle to seed into. Free users get the same plan via --format csv.

Filtering with --severity

For a focused remediation sprint, filter to just critical + high:

ankos remediate ./evidence --severity critical,high --format plan

The plan format respects severity filtering so you can produce a "30-day plan" (criticals only), a "quarter plan" (criticals + highs), and a "full backlog" with the same evidence directory.

Pairing with --ignore-file and --scope-file

• .ankosignore — accepted findings are excluded from remediation output. If you've reviewed and risk-accepted a finding, it shouldn't re-appear as work to do.
• .ankosscope — out-of-scope resources are excluded. Remediation effort focuses on the CDE; out-of-scope items are someone else's problem (or yours, but not for PCI reasons).

Exit codes

remediate doesn't have a CI gate equivalent to report --fail-on — the intent here is generating work artifacts, not blocking builds. Pair it with ankos report for the gating side.