tigergate/tigergate-cli Docker image) to run in CI, one place to review results.
What you get
The default
--type all also runs a code-quality scan (complexity, duplication, maintainability), and scans a container image when you pass --image. See the CLI reference.
Plus, layered on top:
- One findings view — SAST, SCA, secrets, IaC, and code quality all write into the same Code Security → Findings view, so triage, filtering, and status live in one product instead of one tool per scanner.
- PR review comments — inline on the lines that changed, with AI-suggested fixes. See AI Code Review.
- CI quality gate — fail builds when new vulnerabilities land, configured per-repo or per-org. See Quality gates.
- Monorepo components — scope gates to a subtree so each team owns its own thresholds and its own PR check, and a frontend PR is never blocked by a backend finding. See Monorepos.
- Coverage annotation —
CRITICALfinding in an untested file is scarier than the same finding with 95% coverage. See Coverage. - Compliance tags — every finding ships with framework references (
PCI:6.5.1,SOC2:CC7.1, …) that roll up into per-framework scorecards. See Compliance frameworks.
Connect a code provider
GitHub / GitLab / Bitbucket / Azure DevOps. App or PAT.
Wire it into CI
GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI, Azure Pipelines.
Use the CLI
tigergate-cli — scan locally, upload to platform.Quality gates
Fail builds on new vulnerabilities. UI + YAML.
How a scan flows
A scan moves through four stages — connect a provider, register the repo, trigger the scan, and land findings in the inbox — which then fans out to PR comments, the CI quality gate (pass / fail), coverage annotation, notifications (Slack / email / webhook), and compliance scorecards. You connect a provider once. After that, scans trigger from three places:- On push / PR — provider webhook fires when code lands. Scan starts within seconds. See Provider webhooks.
- From CI — your pipeline runs the
tigergate/tigergate-cliimage (scan --type all --upload) and waits for the verdict. See CI/CD integration. - From the dashboard — manual one-shot for a specific commit, or scheduled scans on a cadence.
Scan performance
The scanners run in parallel. In CI,--scan-scope diff reports only changed code (relative to the PR base), so the gate stays fast on large repos and focuses on newly introduced issues. See the CLI reference.
Findings
Every scan emits findings into the Code Security → Findings view, deduplicated by a stable fingerprint (rule/advisory + location) so re-scanning doesn’t multiply rows. Each finding has:- Severity —
CRITICAL/HIGH/MEDIUM/LOW/INFO - Status —
OPEN(default) /IN PROGRESS/RESOLVED/FALSE POSITIVE/WON'T FIX/ACCEPTED - Rule explanation + suggested fix — TigerGate-authored guidance with links to the canonical CWE / OWASP / CIS reference
- Framework tags —
OWASP-A01:2021,CWE-89,PCI:6.5.1,SOC2:CC7.1 - Coverage badge — Tested / Partial / Untested (when coverage is uploaded)
- Affected file + line range — links straight to the provider’s blame view
Triage workflow
The opinionated path most teams settle into:| Status | Use when | What it does |
|---|---|---|
OPEN | Default — needs triage | Counts against the gate |
IN PROGRESS | Actively being worked | Still open; counts against the gate |
FALSE POSITIVE | Rule fired on something benign | Hidden from the open list; doesn’t gate |
ACCEPTED / WON'T FIX | True positive you’ve decided not to fix (compensating controls) | Hidden from the open list; doesn’t gate |
RESOLVED | Fixed in code | Re-tested next scan; reopens if it regresses |
Rollout
During onboarding, run with--quality-gate=false — the scan still runs and uploads, but the build never fails — so the team can triage the existing backlog (mark false positives, accept compensating-control items, fix quick wins) without blocking merges. Once new findings are understood, drop the flag to enforce the gate. See Quality gates.