Skip to main content

CI/CD Integration

Path: /cicd · Sidebar: CI/CD → Pipelines

apPosture plugs into your delivery pipeline so every build is scanned and risky releases can be stopped at the gate - shifting security left without slowing teams down. The gate is fail-closed, the agent is checksum-pinned, and you roll out enforcement on your own terms with Monitor → Block mode.

How it works​

agent (or webhook)  →  ships source per repo/branch  →  apPosture scans  →  gate verdict
                                                          (SAST/SCA/secrets/IaC)   ↓
                                                          pass ✓ / warn ⚠ / fail ✗ → CI

There are two ways to wire it in:

  • Pipeline agent - a checksum-verified agent.sh runs in your CI, ships the source keyed by repo/branch, and acts on the gate verdict.
  • Zero-pipeline webhook - a signature-verified GitHub/GitLab webhook triggers a server-side clone → scan → gate → PR decoration, with no pipeline edit.

Both are covered in Setup.

Gate enforcement​

The gate runs in one of two modes (toggled on the Gates page, server-side - no pipeline change):

  • Monitor (default) - evaluate and record, but never break the build.
  • Block - enforce: a failing gate fails the build.

PRs are decorated with a commit status, a summary comment and optional inline annotations. Only default-branch runs update the posture baseline; PRs are diffed against it so the gate can fail on new risk only.

The Pipelines page​

Path: /cicd

  • Scan results per service, with the gate verdict and a running count of in-flight pipelines.
  • Drill into a run (/cicd/runs/[id]) for the gate decision, the new vs existing findings that drove it, the scanners that ran, and an on-demand AI fix for any finding.

Services​

Path: /cicd/services

The registry of microservices/apps wired into pipelines. Each repo maps to one application by its normalised clone URL (not its display name), so the same repo never splits across services and findings accumulate into one posture.

Operating at scale​

Enable the distributed queue (background worker + scheduler) and CI runs execute on workers: they survive a backend restart, scale horizontally, and are re-delivered if a worker dies. A reaper fails any run orphaned past a timeout. Per-actor in-flight caps and SARIF size limits guard against abuse.

Next​

  • Setup - add the agent or a webhook (GitHub Actions, GitLab CI, Jenkins, Azure, Bitbucket).
  • Gates & Policies - define what blocks a release and roll out Monitor → Block.
Last updated on