The TigerGate CLI runs the full code scan suite in your pipeline — SAST + SCA + secrets + quality + IaC (plus a container-image scan when you pass --image) — uploads findings to the platform, and by default enforces your quality gate to block the build on new high-severity issues. It’s distributed as the Docker image tigergate/tigergate-cli, whose entrypoint is tigergate. Every scan engine is pre-baked, so there’s nothing to provision on runners.

The scanner image

tigergate/tigergate-cli:1.0.0     # exact version pin (recommended — reproducible)
tigergate/tigergate-cli:latest    # rolling latest
Each release publishes an exact MAJOR.MINOR.PATCH tag plus a moving :latest. Pin the exact version in CI for deterministic builds. Run a scan directly — the primitive behind every snippet on this page:
docker run --rm \
  -e TIGERGATE_API_KEY \
  -v "$PWD":/workspace \
  -w /workspace \
  tigergate/tigergate-cli:latest \
  scan --type all --scan-scope full --upload
  • -e TIGERGATE_API_KEY — pass the CI key in; don’t bake it into the image.
  • -v "$PWD":/workspace -w /workspace — mount the repo and run inside it.
  • scan --type all --scan-scope full --upload — subcommand + flags (CLI reference). The gate runs by default; add --quality-gate=false for report-only.
The container exits 0 when the gate passes and non-zero when a finding matches --fail-on (default critical,high) or the scan errors. The image only needs network to reach your region’s platform API — https://api.tigergate.dev/api/ci on us1, the default, and the --region flag picks any other (Regions) — plus outbound access to refresh public vulnerability feeds. TIGERGATE_API_URL overrides the region for a self-hosted instance.

1. Configure defaults in the dashboard

The CLI reads its scan config and gate policy from the platform, so most teams never touch a flag. Configure it once and every pipeline run picks up the right config. Under CI/CD → Quality Gates, edit the Organization Default (or add a per-repo override). The gate is a set of numeric thresholds — a build fails when a count exceeds its limit:
ThresholdDefault
Max new critical0 (any new CRITICAL fails)
Max new high10
Max new medium / lowunlimited (-1)
Max complexity / duplication %25 / 5
Min coverage · blocked licensesoptional
To disable the gate for a run (scan + upload, never fail the build), pass --quality-gate=false. See Quality gates for the full editor.

2. Create a CI/CD key

1

Generate the key

Go to Settings → Organization → API Keys, open the CI/CD Keys sub-tab, and click Create CI Key. Give it a name (e.g. ci-cd-quality-gate) and optionally an expiry. Copy the tgci_… value (shown once). See API keys.
2

Add it to your CI's secrets store as TIGERGATE_API_KEY

CIWhere
GitHub ActionsRepo → Settings → Secrets and variables → Actions
GitLab CIProject → Settings → CI/CD → Variables (mark “Masked”)
Bitbucket PipelinesRepo → Repository settings → Repository variables (Secured)
JenkinsManage Jenkins → Credentials → Secret text
CircleCIProject → Project Settings → Environment Variables
Azure Pipelines / TFSPipeline → Variables (mark “Keep this value secret”)
AWS CodeBuildProject → Environment → Environment variables (type Secrets Manager)
Google Cloud BuildSecret Manager, referenced via availableSecrets
Drone CIRepo → Settings → Secrets
Travis CIRepo → Settings → Environment Variables
BuildkiteAgent secrets hook, or the AWS/GCP/Vault secrets plugin
TeamCityProject → Parameterspassword type
TektonA Kubernetes Secret, referenced from the Task
3

Tell the pipeline which region the key belongs to

tgci_ keys are scoped to one region — a key issued in one is rejected by every other, and the authentication error names the region and endpoint that were tried.Every snippet below carries the region line next to the key, commented out — they run as written on us1, the default, and one uncommented line moves a pipeline to any other region. It is the region that issued the key, not where the runner happens to be.Set it once per pipeline, wherever that pipeline keeps TIGERGATE_API_KEY:
CIHow
GitHub ActionsTIGERGATE_REGION in env:, or region: <code> on the action, or --region <code> on the CLI
Azure Pipelines / TFSTIGERGATE_REGION in the step’s env:, or region: <code> on the task
JenkinsTIGERGATE_REGION in environment { }, or the REGION build parameter
GitLab CI · Bitbucket Pipelines · everything elseTIGERGATE_REGION as a pipeline / repository variable, or --region <code> on the command
Setting TIGERGATE_API_URL (self-hosted, staging, air-gapped) overrides the region entirely — pass one or the other, not both. An unknown code fails the build rather than falling back to us1.

3. Per-CI snippets

The canonical pattern is one scan per trigger:
  • Pull / merge request → --scan-scope diff — scans only the code the PR changed and gates on it. This is the enforcement point.
  • Push to the default branch → --scan-scope full — scans the whole repo.
Add --quality-gate=false to any command to upload results without failing the build (report-only / observation mode).
Every job runs inside the CLI image (tigergate is on PATH, all GITHUB_* variables are auto-present, so branch / base / PR context is detected automatically).
name: TigerGate Security
on:
  push:
    branches: [main]
  pull_request:

env:
  TIGERGATE_API_KEY: ${{ secrets.TIGERGATE_API_KEY }}
  # TIGERGATE_REGION: eu1        # the region that issued the key; omit for us1

jobs:
  pr-scan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    container:
      image: tigergate/tigergate-cli:latest 
    permissions:
      contents: read
      pull-requests: write   # PR summary comment
      statuses: write        # commit status
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }   # full history for the diff gate
      - run: tigergate scan --type all --scan-scope diff --upload

  full-scan:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    container:
      image: tigergate/tigergate-cli:latest 
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: tigergate scan --type all --scan-scope full --upload
PR-delta detection — gating only on the code a PR introduces — is automatic on GitHub Actions, GitLab CI, Azure Pipelines (and TFS / Azure DevOps Server, which share the same variables), and Bitbucket Pipelines: the CLI reads their native base-branch variables. On every other platform, export your target branch into CI_MERGE_REQUEST_TARGET_BRANCH_NAME (shown in the snippets above) for a true PR-vs-base diff, or run a whole-repo gate with --scan-scope full. Without a base, the CLI diffs against HEAD~1.

4. Scan-type flags

--type all runs every scan type. To narrow or tune a run from the pipeline:
FlagEffect
--type sastRun only one type (sast, sca, secrets, quality, iac, image)
--type sast,secretsRun only these types
--type allFull suite (default)
--scan-scope diffReport only PR-changed code (full = whole repo, auto = both; default auto)
--quality-gate=falseReport-only — upload but never fail the build
--fail-on criticalOverride which severities fail the build (default critical,high)
--exclude node_modules,distSkip paths
--component web --component-path apps/webScope the run to one monorepo component (own gate + own status check)
Per-run overrides suit one-off triage (e.g. --type secrets --quality-gate=false for a fast secret sweep). For permanent changes, edit the repo’s dashboard settings so every PR sees the same policy.
# Secrets-only sweep, no gate
tigergate scan --type secrets --upload --quality-gate=false

# Full scan, fail only on CRITICAL
tigergate scan --type all --upload --fail-on critical
Want findings to link to the running cloud asset? Add the build/deploy metadata flags — see Code → cloud tracking. Container-image scanning runs automatically inside --type all when you pass --image; standalone container scanning lives under Container Security.

5. Monorepos

With one gate per repository, a frontend PR fails on a pre-existing backend critical the frontend team can’t fix. Split the repo into components — one CI job per component, each with its own gate, its own paths, and its own status check.
1

Define the components in the dashboard

Under CI/CD → Quality Gates, create one config per component: pick the repository, set Component (e.g. web) and Component paths (e.g. apps/web, libs/shared), then set that team’s thresholds.
2

Run one job per component

The contract is the same on every CI system, and only three things matter:
  1. One job per component, each passing --component <key>. That is what produces a separate quality gate and a separate status check.
  2. Full git history — the CLI decides whether a component is affected by diffing against the PR base branch. A shallow clone has no base ref, detection fails open, and every component scans.
  3. Do not let one component’s failure cancel the others, or you cannot tell “skipped because untouched” from “cancelled by a sibling”.
Anything that can run N jobs can do this. Where the platform has a native matrix, use it; where it does not, repeat the job per component — the behaviour is identical.The region is set exactly as in step 3 and every job inherits it; the docker run snippets below pass TIGERGATE_REGION through explicitly, because a variable the CI holds is not visible inside the image unless -e names it.
jobs:
  security:
    runs-on: ubuntu-latest
    container: { image: tigergate/tigergate-cli:latest }
    strategy:
      fail-fast: false
      matrix:
        component: [web, api]
    permissions:
      contents: read
      statuses: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: tigergate scan --scan-scope diff --component ${{ matrix.component }}
        env:
          TIGERGATE_API_KEY: ${{ secrets.TIGERGATE_API_KEY }}
          # TIGERGATE_REGION: eu1   # omit for us1
3

Require the component checks in branch protection

Each job reports as TigerGate Security (web) / TigerGate Security (api). Add those contexts instead of the single TigerGate Security one.
4

Keep one unscoped job on the default branch

Component runs only contain their own findings. Run tigergate scan --scan-scope full with no --component on merges to the default branch so the dashboard keeps the whole-repo inventory.
The CLI decides which components a PR concerns by diffing against the base branch and intersecting the changed files with each component’s paths. Untouched components exit 0 in seconds with a passing status and create no scan run.
Don’t filter component jobs with on.pull_request.paths (or GitLab rules:changes). A required check whose job never runs leaves the PR pending forever. Let every component job start and let the CLI skip the irrelevant ones.
Component model, path precedence, scoping rules and branch-protection detail: Monorepos.

What the scan does

  1. Detect repo + branch + PR context from the CI environment.
  2. Scan (parallel): SAST + SCA + secrets + quality + IaC (+ image with --image), plus SBOM.
  3. Upload findings to the platform.
  4. Evaluate the quality gate and post commit status + PR comment.
  5. Exit 0 when the gate passes (or --quality-gate=false); exit non-zero when a finding matches --fail-on.
The gate decision:
  • The CLI fails the build on new CRITICAL / HIGH findings by default (--fail-on critical,high); --quality-gate=false makes it upload-only.
  • On GitHub / GitLab / Azure / Bitbucket the CLI detects the PR’s base branch, distinguishing new-code findings from the existing backlog (elsewhere it diffs against HEAD~1).
  • The dashboard Quality Gate layers numeric thresholds on top — max new critical / high / medium / low, complexity, duplication, min coverage, blocked licenses — counting new-code-only or the whole codebase per its New code only setting.
Tune it under CI/CD → Quality Gates — see Quality gates.

PR comments

When the connected provider credential (GitHub App / Azure DevOps PAT / GitLab token / Bitbucket App Password) has PR-write permission, TigerGate posts a summary comment with the gate verdict and a link to the findings. Inline comments and AI-suggested fixes come from the AI code review — see AI Code Review. Report-only mode (--quality-gate=false) still posts comments; the build just doesn’t fail.

Troubleshooting

SymptomLikely causeFix
401 Unauthorized on uploadBad / revoked API keyRecreate the CI/CD key, update the CI secret
Gate keeps passing despite findingsThresholds too loose, or --quality-gate=false setLower the max-counts under CI/CD → Quality Gates; remove --quality-gate=false
Gate fires on backlog findingsThresholds too strict for existing codeRaise the max-counts or enable New code only under CI/CD → Quality Gates
dubious ownership / git errors in-containerMissing safe.directory configSet GIT_CONFIG_COUNT / GIT_CONFIG_KEY_0 / GIT_CONFIG_VALUE_0 as shown in the GitLab / Bitbucket / Jenkins / Azure tabs
Diff gate scans the whole repoNo base branch detectedExport CI_MERGE_REQUEST_TARGET_BRANCH_NAME, or ensure fetch-depth: 0
IaC findings not appearingIaC needs --type all or --type iacConfirm the scan type; see IaC scanning
Unknown-flag errorOutdated image predates the flagdocker pull tigergate/tigergate-cli:latest
PR stuck on a required check that never reportsA component job was filtered out with paths / rules:changes, so it never ran and never posted its statusRemove the path filter and let every component job start — the CLI skips untouched components itself and still posts a passing status
Component job scans the whole repo, or never skipsNo component paths resolved. --component alone selects the gate and check name but does not scope findings or enable the skipPass --component-path, or set Component paths on that component’s gate; see Monorepos
One component’s verdict overwrites another’s on the same commitBoth jobs ran without --component, so both posted the same status contextGive each job its own --component so the contexts differ
New-code gate reports every check as skippedNew-code mode is on but the run carried no new-code signalAdd --scan-scope diff, or set a new-code baseline for the repo + branch; see Quality gates

Air-gapped runners

Pull the image once and mirror it to your internal registry:
docker pull tigergate/tigergate-cli:latest 
docker tag tigergate/tigergate-cli:latest  registry.internal.example.com/tigergate/tigergate-cli:latest 
docker push registry.internal.example.com/tigergate/tigergate-cli:latest 
Then use registry.internal.example.com/tigergate/tigergate-cli:latest in the snippets above, and point TIGERGATE_API_URL at your self-hosted TigerGate instance.