TigerGate Docs — code-to-cloud security platform

Connect a repo, run a scan, gate your pipeline, and link findings to what’s actually running. Each step links to a deeper page for detail.

Connect a code provider

Go to Integrations → Code Providers and connect GitHub, GitLab, Bitbucket, or Azure DevOps (GitHub App, OAuth, or a PAT per provider). This is the one credential the platform needs to read your repos and post PR comments.→ Connect a provider

Run your first scan

Two ways to kick off a scan:

From the dashboard — go to Organization → Scan Trigger, pick a connected repository, and run. Good for a first look.
From the CLI — run the scanner image anywhere Docker runs:

docker run --rm \
  -e TIGERGATE_API_KEY \
  -v "$PWD:/workspace" -w /workspace \
  tigergate/tigergate-cli:latest \
  scan --type all --upload

--type all runs SAST + SCA + secrets + quality + IaC in one pass. Findings land in the unified inbox under Code Security → Findings.→ CLI reference · CI/CD integration

Create a CI API key

Organization → API Keys → Create Key, give it a name (e.g. ci-cd-quality-gate), and copy the tg_… value into your CI’s secret store as TIGERGATE_API_KEY. The full key is shown once at creation.→ API keys

Wire it into CI with a gate

Drop the scan into your pipeline. The quality gate runs by default and fails the build on new high-severity findings (per your dashboard policy):

# GitHub Actions — runs inside the CLI image; the entrypoint is the CLI
jobs:
  tigergate:
    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 }
      - name: TigerGate scan + gate
        run: tigergate scan --type all --upload
        env:
          TIGERGATE_API_KEY: ${{ secrets.TIGERGATE_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Start in observation mode with --quality-gate=false, then turn the gate on once the inbox is triaged.

Monorepo? Stop here and set up components first. As written, this single job gives the whole repository one shared gate, so a frontend PR gets blocked by a pre-existing backend finding that team can’t fix. Run one job per component instead — see Monorepos.

→ CI/CD integration · Quality gates

Track build & deploy (code → cloud)

Add the build/deploy metadata so a finding links to the running asset by image digest + commit:

tigergate scan --type all --upload \
  --image registry.example.com/app:$SHA \
  --image-digest "$IMAGE_DIGEST" \
  --deploy-target prod-eks/payments \
  --environment production

Now you can filter “criticals running in production”, and IaC findings map to the cloud resources they declare.→ Code → cloud tracking

What good looks like after onboarding

Every push/PR triggers a scan (provider webhook) and every pipeline run gates the build.
New CRITICAL/HIGH findings block the merge; existing and ACCEPTED/MUTED ones don’t.
PRs get inline comments with AI-suggested fixes.
Findings carry image digest + environment, so production risk is one filter away.

​What good looks like after onboarding

What good looks like after onboarding