Ankos
Guides

Catch PCI drift in CI/CD

Wire the Ankos CLI into your pipeline so a new public bucket, a disabled trail, or an over-permissive role surfaces within a day — not at your next QSA assessment. Free, read-only, QSA-safe output.

PCI posture decays between assessments. Someone opens a bucket to debug an incident, a CloudTrail gets disabled during a migration, a role picks up AdministratorAccess "just for now." None of it is malicious; all of it is invisible until your next assessment — unless something is watching.

The Ankos CLI is that something. It's free, read-only, and runs on your existing cloud credentials, so it drops into any pipeline. This guide is the why and the loop; for copy-paste configs per platform, see CI/CD integration.

The CLI reports evidence readiness, never a compliance verdict. A failing CI gate means "evidence regressed, look at it" — your QSA still makes the final determination.

The loop

scheduled scan → report (CI gate) → drift surfaces in the PR / job summary
        ▲                                          │
        └──────────────  fix, re-scan  ◄───────────┘

Three moving parts:

  1. Scan on a schedule (and/or on each deploy) — collect current evidence.
  2. Report with a CI gatereport --format github posts a readiness summary to the job summary, and --fail-on sets the exit code so the build breaks on regressions.
  3. Act on the signal — the finding shows up where engineers already look (the PR, the job summary), so it gets fixed in a day, not a quarter.

The minimal setup

The whole gate is two commands:

ankos scan -o ./evidence
ankos report ./evidence --format github --fail-on action-needed
  • --format github writes a readiness table (score, top findings) to $GITHUB_STEP_SUMMARY and emits inline ::warning:: annotations.
  • --fail-on action-needed exits non-zero when there are action-needed findings, so the job goes red. Use --fail-on critical (via ankos drift, below) if you only want serious regressions to break the build.

Run it on a daily schedule: trigger so drift surfaces even when nobody ships. The full GitHub Actions / GitLab CI / CircleCI / self-hosted configs are in CI/CD integration.

Compare against a baseline with ankos drift

report --fail-on answers "is the current state clean?" ankos drift answers "what changed since a known-good baseline?" — which is usually the more actionable question in CI.

# Sunday: capture the week's baseline
ankos scan -o ./baseline

# Daily: compare and break the build only on posture regressions
ankos drift ./baseline --fail-on critical

Drift reports a Direction (↓ Degrading / ↑ Improving / → Stable) and groups changes into Degradations (posture worsened), Improvements, and informational Changes. The exit code is driven by --fail-on (critical, high, or any), so you can let low-severity churn through while breaking the build on a new 0.0.0.0/0 ingress rule. See ankos drift.

Keep the output QSA-safe

The GitHub summary and annotations are worded as readiness, not verdicts — "N findings need attention", never "failed". That matters: these artifacts land in PRs and Slack, and they should never read as Ankos issuing a compliance judgment. The exit code drives CI; the wording stays assessor-safe.

Across assessment cycles

CI keeps a single cycle clean. When the next assessment opens, you don't start from zero — still-valid evidence carries forward with an attestation, so a year-2 assessment builds on year-1. See carry-forward.

Next steps