Skip to content

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 — four 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. A repository with none of these simply gets no findings from this tool; it never substitutes for the other three.
  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: Claude's project-discovery adapters currently only cover JavaScript/TypeScript, PHP, and Go. A repository in any other language (Python, Java, Ruby, etc.) skips the AI analysis phase entirely and only gets findings from the three 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.

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 4.8 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.

Scan status

StatusMeaning
queuedWaiting for a worker to pick it up
cloningstatic_analysisai_analysisprocessingIn progress
completedFindings are up to date as of this commit
failedSee 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.

AI-assisted vulnerability scanning.