Configure API security scanning in a CI/CD pipeline

The three steps every pipeline needs

• Push — register the API endpoints and target credentials. Idempotent: name + base_url identify the same project.
• Scan — trigger the test and wait for the result. --fail-on high turns high/critical findings into exit code 1.
• Verdict (optional) — compare against a baseline and fail only on new regressions, so accepted findings never block deploys.

export LIVEAPISEC_API_KEY="$LIVEAPISEC_KEY"

liveapisec push \
  --name my-api \
  --base-url "$API_BASE_URL" \
  --endpoint "GET /users" \
  --endpoint "POST /payments"

liveapisec scan \
  --project "$PROJECT_ID" \
  --branch "$BRANCH" \
  --commit "$COMMIT_SHA" \
  --wait --fail-on high

GitLab CI example

Store the key as a masked CI/CD variable. The job fails the pipeline when a high or critical finding is found.

stages: [test, security]

api-security:
  stage: security
  image: python:3.12-slim
  before_script:
    - pip install liveapisec
  variables:
    LIVEAPISEC_API_KEY: $LIVEAPISEC_KEY
  script:
    - liveapisec push --name my-api --base-url "$API_BASE_URL" \
        --endpoint "GET /users" --endpoint "POST /payments"
    - liveapisec scan --project "$PROJECT_ID" \
        --branch "$CI_COMMIT_BRANCH" --commit "$CI_COMMIT_SHA" \
        --wait --fail-on high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Exit codes and what fails the build

• 0 — OK: no findings at or above --fail-on, or no --fail-on flag.
• 1 — gate failed: findings at or above the threshold were found.
• 2 — usage error, API error, or missing/invalid key.

liveapisec scan --project "$PROJECT_ID" --wait --fail-on high      # high + critical
liveapisec scan --project "$PROJECT_ID" --wait --fail-on critical  # critical only
liveapisec scan --project "$PROJECT_ID" --wait                     # never fail on findings

Gate only on new findings (verdict vs baseline)

--fail-on high fails on any high finding, including ones you already know and accepted. verdict diffs the new scan against a baseline and fails only when new findings reach the threshold — matching by category, target and title. Both scans must belong to your organisation.

liveapisec verdict \
  --project "$PROJECT_ID" \
  --scan "$NEW_SCAN_ID" \
  --baseline "$BASELINE_SCAN_ID" \
  --fail-on high

A typical setup: baseline depth on every push + verdict versus main, and a full deep scan on a nightly schedule.

Save a report as a CI artifact

liveapisec all runs scan → verdict → compliance → report and saves a certificate PDF. Use --format md to produce a human-readable report you can upload even when the gate fails (if: always()), so reviewers see exactly which findings are new.

liveapisec all --project "$PROJECT_ID" \
  --format md --report-out security-report.md

# GitHub Actions / GitLab: upload security-report.md as an artifact
# with if: always() so it exists even when the job fails.

Common CI mistakes

• Using a short-lived JWT as target credentials — it expires before the scan. Use OAuth2 client credentials.
• Not setting LIVEAPISEC_API_KEY and relying on a developer login — CI has no interactive login.
• Running the deep suite on every commit — use baseline per push and deep nightly.
• Scheduling scans against an internal/localhost URL — internal targets are on-demand only; use --tunnel for localhost.
• Treating compliance output as a certification — mappings are indicative evidence, not an audit.

FAQ

Does LiveAPISec support GitHub Actions?

Yes. Install the CLI with pip/pipx, add `LIVEAPISEC_KEY` as a repository secret, and run `liveapisec push` + `liveapisec scan --wait --fail-on high`. There is a dedicated guide with a complete workflow YAML at /docs/github-actions.

How do I avoid failing the build on already-known findings?

Use `liveapisec verdict` with a baseline scan. It fails only on new findings at or above the threshold, so accepted risk does not block every deploy.

How long should a CI security gate take?

The baseline suite is designed for every commit (seconds per endpoint) and the first report is ready in about two minutes. Schedule the deep suite nightly or before releases.