How Scanning Works

Pipeline

Every scan runs the same pipeline regardless of what triggered it:

1. Clone — a shallow, single-commit checkout of exactly the commit being scanned (not the whole repository history).
2. Static analysis — deterministic tools run in sequence:
   • Gitleaks for exposed secrets (API keys, credentials committed by accident).
   • Semgrep for known vulnerability patterns, with language-specific rule packs layered on top of a baseline OWASP/security-audit pack.
   • OSV-Scanner for known-vulnerable dependencies, reading whatever lockfile the project already has (package-lock.json, composer.lock, go.sum, etc.) — nothing extra to configure.
   • Trivy for Infrastructure-as-Code misconfigurations — Dockerfiles, Terraform, Kubernetes manifests, CloudFormation — and for restrictive dependency licenses: only strong-copyleft licenses (GPL/AGPL and stricter) are flagged, since those can oblige you to release your own source. Permissive (MIT/Apache/BSD) and weak-copyleft (MPL/LGPL) licenses are intentionally not reported, to avoid burying the ones that actually matter.
   • Hadolint for Dockerfile-specific issues — unpinned base images, running as root, unsafe RUN shell commands (via embedded ShellCheck) — broader Dockerfile coverage than Trivy's misconfiguration checks alone. A repository with no Dockerfiles gets no findings from it.
   • A repository that doesn't contain a given category of file (no IaC, no Dockerfiles, no restrictive-licensed dependencies) simply gets no findings from that tool; none of them ever substitute for the others.
3. AI analysis — Claude reviews source files for the class of issue static analysis structurally can't catch: missing authorization checks, business-logic flaws, unsafe assumptions about caller identity. Secrets found by Gitleaks are redacted before any code reaches the model.
4. Processing — findings are deduplicated against what's already open for the repository (a finding that already exists doesn't create a duplicate; one that's no longer present gets marked fixed automatically).

Language support

Gitleaks (secrets) and OSV-Scanner (dependency CVEs, read from whatever lockfile is present) run on every repository regardless of language — neither is language-specific.

Semgrep's baseline OWASP/security-audit rules also run on every repository, with deeper, language-specific rule packs layered on top for:

JavaScript, TypeScript (plus React and Node.js framework packs), Python (plus Django and Flask), PHP, Go, Java, Ruby, C#, Rust, Kotlin, Scala, Swift, and C.

A repository whose primary language isn't in that list still gets the full baseline coverage — it just misses the extra language-specific rules.

AI analysis is narrower than the deterministic tools: Claude's project-discovery adapters currently cover JavaScript/TypeScript, PHP, Go, Python, Java, C#, and Ruby. A repository whose primary language isn't one of those (for example Rust, Kotlin, Scala, Swift, or C) skips the AI analysis phase entirely and only gets findings from the deterministic tools above.

Scan types

• Full — every eligible source file in the repository. Runs on push and on manual/scheduled/API triggers.
• Diff — only files changed in the pull/merge request. Runs on PR/MR-triggered scans, keeping AI cost proportional to the size of the change rather than the whole repository.

Software Bill of Materials (SBOM)

Every scan also generates a CycloneDX SBOM — a machine-readable inventory of every dependency detected in the repository, in the format tools like Dependency-Track and most compliance workflows expect. The latest one is always available from the Software Bill of Materials card on the repository page as a .cdx.json download.

The SBOM reflects the most recently scanned commit and is regenerated on each scan, so it never goes stale. Generating it reads only your lockfiles and manifests — no extra configuration, and a repository with no dependencies simply produces an SBOM with no components rather than an error.

Cost control

AI analysis result are cached per file (keyed off file content + the active scan policy), so re-scanning an unchanged file — extremely common on repeated pushes to the same branch — costs nothing the second time. This is the single biggest lever on AI spend, and it's on by default.

Your organization's plan sets two independent limits: how many repositories can be actively scanned, and how many scans a single repository can run in a rolling 30-day window. Hitting either limit doesn't silently drop the scan — it still creates a visible failed scan row explaining why, since silently skipping a scan is a trust problem for a security tool, not just an ordinary usage cap.

Model choice (bring your own key)

By default, AI analysis runs on Claude Sonnet 5 using the platform's own key, at no extra cost to you. From Settings → General → AI analysis, you can supply your own Anthropic API key to use Claude Opus 5 instead — spend for those scans is billed directly to your own Anthropic account, tracked separately from platform cost on the same Settings page. Without a key on file, model choice always stays on the platform default, regardless of any prior selection — removing the key reverts immediately.

A key is verified with a real (free) call to Anthropic before it's saved, so a typo or an already-revoked key is caught immediately rather than surfacing later as a failed scan. If a saved key stops working (revoked, expired, billing issue), scans fail with a specific "AI key" error and — if Slack is connected — a notification, rather than a generic failure.

Turning AI analysis off

AI analysis is on by default. If you'd rather run only the deterministic tools — for a repository where you want to keep every scan entirely local to the four scanners, to cut AI cost, or simply because the AI phase isn't useful for that project — turn off Include AI analysis in the repository's scan policy. Deterministic findings (Gitleaks, Semgrep, OSV-Scanner, Trivy) still run exactly as before; only the AI review phase is skipped, and the scan notes that AI was skipped by configuration rather than failing.

Scan status

Status	Meaning
queued	Waiting for a worker to pick it up
cloning → static_analysis → ai_analysis → processing	In progress
completed	Findings are up to date as of this commit
failed	See the scan's error message — most commonly a lost Git provider connection (a "Reconnect" link is shown directly) or a plan limit

Scheduled scans

A repository that hasn't been scanned in 24 hours is automatically re-scanned once a day, even with no new commits — this exists specifically to catch newly-disclosed CVEs in dependencies that haven't changed (OSV-Scanner's database updates independently of your code). Turn this off per-repository from the repository's scan policy if it doesn't fit your workflow.