Docs
Scanning
The four scanners, auto-scan and pull request checks.
The four scanners
Every plan includes all four, and scans never use credits.
| Scanner | Finds | Engine |
|---|---|---|
| Code (SAST) | Security bugs in your own code, matched by our rule pack | Opengrep |
| Dependencies (SCA) | Packages with published vulnerabilities, from osv.dev | OSV-Scanner |
| Secrets | Keys, tokens and passwords committed to the repository | Gitleaks |
| Infrastructure (IaC) | Misconfigured Terraform, Kubernetes, Dockerfiles and other infrastructure code | Checkov |
What a scan reads
A scan reads a snapshot of one commit. Nothing runs your code, and the snapshot is deleted within 48 hours (data lifecycle). Secret values are redacted before a finding is stored.
Your repository's own scanner settings, such as .semgrepignore, .gitleaks.toml, .checkov.yaml and osv-scanner.toml, are ignored: in a pull request they could switch checks off. To silence a finding, triage it instead.
Each scanner has a fixed time budget per scan. A repository that needs longer fails that scanner with “repository too large for the free scan budget”, and the other scanners still report.
Starting a scan
Members and above start a scan with Scan now on a repository, unless that repository is already being scanned.
Your plan sets the largest repository, scans per day and scans at a time (see pricing). A scan that is refused doesn't count against the day's quota.
Auto-scan
With auto-scan on, every push to the default branch and every opened, reopened or updated pull request starts a scan. Admins switch it on per repository, in the repository list or the repository's Settings tab.
- GitHub: nothing more to do. The App already receives the events.
- GitLab: the first time, swarmbase asks for the
apiscope so it can add a webhook and post commit statuses. You need the Maintainer role on the project. - Bitbucket: the first time, swarmbase asks for the Webhooks permission.
Pull request checks
A pull request scan looks only at the files the pull request changes. Dependencies are scanned only when a manifest or lockfile changed.
The result appears on the pull request as a check run on GitHub, a commit status on GitLab and a build status on Bitbucket. A finding is new when the default branch doesn't already have it open or triaged.
- The check fails when the pull request adds a critical finding.
- Other new findings are reported without failing the check (neutral on GitHub).
- The check shows counts by severity and a link to the scan, never code, file paths or secret values.
When a finding is fixed
A full scan of the default branch marks the findings it no longer sees as fixed, for each scanner that succeeded. A fixed finding that comes back is reopened. Findings you ignored or marked as false positives stay that way.