Skip to main content

CI/CD Setup

Path: /cicd/setup · Sidebar: CI/CD → Setup

The Setup page is an in-app, copy-paste guide for wiring scanning into your pipeline. This page summarises the flow; always use the live page for the exact, tokenised snippets for your instance.

Prerequisites​

  1. A write-capable API token for the pipeline to authenticate with (create one under Account Security - tokens are prefixed apt_). Read-only tokens are rejected by the run endpoint by design.
  2. The repository connected via Integrations (or the agent ships source directly from the checkout).

The pipeline agent​

The agent is downloaded and checksum-verified before it runs - never a blind curl | sh:

# download, verify the published SHA-256, then run
curl -fsSL "$APPOSTURE_URL/api/v1/ci/agent.sh" -o apposture
curl -fsSL "$APPOSTURE_URL/api/v1/ci/agent.sh.sha256" | sha256sum -c -
chmod +x apposture
./apposture test --app "$REPO" --severity-threshold high --fail-on new

The agent auto-detects GitHub Actions / GitLab CI / Jenkins (repo, branch, commit, PR id), ships the source, triggers the scan, waits for the gate verdict, and exits non-zero if the gate fails - failing the pipeline stage (unless the gate is in Monitor mode).

Agent commands​

CommandWhat it does
testRun the source scanners (SAST/SCA/secrets/IaC) and gate the build. (default)
monitorSnapshot the default branch to set the baseline; never fails the build.
uploadSend a SARIF report only (bring-your-own scanner).
containerScan a built image with Trivy on the runner and upload its SARIF.

Useful flags: --severity-threshold critical|high|medium|low|none, --fail-on new|all, --scanners sast,sca,secrets,iac, --no-gate.

Delta (incremental) PR scans​

On a PR run with a known changed-file set, the agent sends the diff and the server skips scanners whose input class didn't change (SCA when no manifest changed, IaC when no IaC file changed). The default branch / monitor always full-scans, so the baseline stays complete and nothing is permanently missed.

Platform examples​

The in-app Setup page generates ready-to-paste snippets for GitHub Actions, GitLab CI, Jenkins, Azure Pipelines and Bitbucket. A GitHub Actions example:

- name: apPosture security gate
  env:
    APPOSTURE_URL: https://aspm.apposture.com
    APT_TOKEN: ${{ secrets.APPOSTURE_TOKEN }}
  run: |
    curl -fsSL "$APPOSTURE_URL/api/v1/ci/agent.sh" -o apposture
    curl -fsSL "$APPOSTURE_URL/api/v1/ci/agent.sh.sha256" | sha256sum -c -
    chmod +x apposture
    ./apposture test --app "$GITHUB_REPOSITORY" --severity-threshold high --fail-on new

Zero-pipeline webhook scanning​

You don't have to edit a pipeline at all. Point a GitHub/GitLab webhook at apPosture and a push or pull/merge request triggers a server-side clone → scan → gate → PR decoration:

  • Signature-verified - GitHub HMAC-SHA256, GitLab shared token.
  • Replay-protected - duplicate deliveries are dropped.
  • Secure by default - webhooks are opt-in; a global secret or a per-repo secret (set per integration, so one leaked secret can't forge another repo's events).
  • Pushes to the default branch set the baseline (monitor); PRs are gated.

Operating at scale​

  • Distributed queue - enable the distributed worker/scheduler so CI runs execute on workers (survive a restart, scale horizontally, re-deliver on worker death) and a reaper fails any run orphaned past a timeout.
  • Abuse guards - a per-actor in-flight cap (HTTP 429 beyond it) and a SARIF upload size limit protect the scan pipeline.

Wiring it together​

  1. Create the write-capable API token.
  2. Register the service (or let the first run auto-register it).
  3. Add the agent step (or a webhook).
  4. Set the gate enforcement mode - start in Monitor.
  5. Run the pipeline; view results under Pipelines.
Start in Monitor mode

Run the gate in Monitor first so teams see findings without failing builds, then flip to Block from the Gates page once the baseline is clean - no pipeline change required.

Last updated on