CI/CD Integration

Your PCI evidence freezes at the moment of each assessment. Between assessments, infrastructure changes — a new public S3 bucket, a disabled CloudTrail, an over-permissive IAM role added during an incident response. Drift is invisible until your next QSA visit.

The CLI is built to run in CI/CD. Schedule a scan, fail the build on new findings, or simply archive the evidence for the next cycle's carry-forward attestation.

Why scan in CI/CD

GitHub Actions

The minimal scheduled workflow:

# .github/workflows/ankos-pci-scan.yml
name: Ankos PCI Scan

on:
  schedule:
    - cron: '0 6 * * 1'       # Mondays at 06:00 UTC
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      id-token: write           # for OIDC → AWS
      contents: read
    steps:
      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/AnkosScanRole
          aws-region: us-east-1

      - name: Install Ankos CLI
        run: curl -sSL https://get.ankos.dev | sh

      - name: Run scan
        run: ankos scan --output ./evidence

      - name: Verify evidence integrity
        run: ankos verify ./evidence

      - name: Post readiness summary (exits non-zero on action-needed findings)
        run: ankos report ./evidence --format github --fail-on action-needed

      - name: Upload evidence as artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: ankos-evidence-${{ github.run_number }}
          path: ./evidence/
          retention-days: 90

Notes:

• OIDC over long-lived keys. Use the AWS GitHub OIDC integration rather than storing AWS_ACCESS_KEY_ID in secrets. The scan role only needs read-only permissions (SecurityAudit + ViewOnlyAccess is sufficient).
• report --format github writes the readiness summary (score, trend, top findings) to the job summary and emits ::warning:: annotations inline on the PR. --fail-on action-needed makes the job exit non-zero on serious findings — the exit code drives CI while the wording stays evidence-readiness ("N findings need attention", never "failed").
• if: always() on the artifact upload captures evidence even when the report step exits non-zero, so you can debug.

A ready-to-copy version of this workflow ships in the CLI repo at examples/github-actions/pci-evidence.yml.

GitLab CI

# .gitlab-ci.yml
ankos-pci-scan:
  stage: compliance
  image: alpine:latest
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  variables:
    AWS_DEFAULT_REGION: us-east-1
  before_script:
    - apk add --no-cache curl bash ca-certificates
    - curl -sSL https://get.ankos.dev | sh
  script:
    - ankos scan --format json --fail-on any --output ./evidence
  artifacts:
    when: always
    paths:
      - evidence/
    expire_in: 90 days

Pair this with a scheduled pipeline in CI/CD → Schedules in the GitLab UI.

CircleCI

# .circleci/config.yml
version: 2.1

jobs:
  ankos-pci-scan:
    docker:
      - image: cimg/base:current
    steps:
      - run:
          name: Install Ankos
          command: curl -sSL https://get.ankos.dev | sh
      - run:
          name: Run scan
          command: ankos scan --format json --fail-on any --output ./evidence
      - store_artifacts:
          path: ./evidence
          destination: ankos-evidence

workflows:
  scheduled-pci-scan:
    jobs:
      - ankos-pci-scan
    triggers:
      - schedule:
          cron: '0 6 * * 1'
          filters:
            branches:
              only: main

Self-hosted runners (any CI)

The CLI is a single static binary. If your CI doesn't have outbound internet (or you prefer pinned versions), download a specific release and store the binary in your runner's filesystem.

# Pin to a specific version
curl -fsSL -o /usr/local/bin/ankos \
  https://releases.ankos.dev/cli/v1.0.0/ankos-linux-amd64
chmod +x /usr/local/bin/ankos

ankos scan --format json --fail-on any --output ./evidence

Patterns

Diff against last scan

Two scans, compared, surface drift:

ankos scan --output ./scan-current
diff <(jq -S . ./scan-last/iam.json) \
     <(jq -S . ./scan-current/iam.json)

A non-empty diff means IAM evidence changed. Wire this into your pipeline to alert when specific collectors' evidence shifts between runs. For a built-in version of this with baseline tracking and CI exit codes, use ankos drift.

Send to S3 for long-term archive

ankos scan --output ./evidence
aws s3 cp ./evidence/ s3://my-compliance-archive/$(date -u +%Y/%m/%d)/ \
  --recursive --sse aws:kms

Now you have a tamper-evident, encrypted-at-rest archive of every scheduled scan. When the next QSA cycle starts, the carry-forward attestation can cite the actual evidence file's S3 path + hash, not just "we ran the scan."

Upload directly to the Ankos ledger

If you're already using the Ankos SaaS, skip the artifact-upload dance and push scan results straight into your active cycle:

ankos auth set-key --key "$ANKOS_API_KEY"   # secret stored in CI
ankos scan --upload --format json

The CLI matches each collector's evidence to the right entries in the ledger. Multiple scheduled scans accumulate as evidence rows under each entry — no overwrites, no manual triage.

What NOT to do

• Don't store evidence in your application repo. Use CI artifacts, S3, or the Ankos ledger. Evidence in version control creates a dilemma about whether to commit secrets the scan might surface (it shouldn't, but defense in depth).
• Don't use a single shared API key across environments. If you upload from CI, create a dedicated API key per scope (dev / staging / prod). The free CLI without --upload needs no auth at all and is the right default for pre-revenue or pre-paid teams.
• Don't --fail-on any on prod scans you don't review daily. A single transient AWS API throttle will fail your build. Use the pattern in your dev / staging pipeline; use plain ankos scan (which exits 0 unless setup fails) for the prod scheduled job, and alert on the artifact's summary instead.