Branches, scans and quality gates
Tracked branches
Vulkro Cloud scans the branches you track in each repository.
- The default branch is always tracked.
- Pick other branches when you connect the repository, or later from the repository's Branches tab (Add Branch searches the remote branches).
- A branch's menu has Scan Now, Make Default Branch, Stop Tracking, and downloads of its latest results as SARIF and CSV.
How many branches you can track besides the default branch is set with your plan.
Scheduled scans
Each tracked branch has its own schedule: Off, Every 6 hours, Daily or Weekly. A newly tracked branch starts with its schedule off. Every 6 hours is available on the Team plan and up; on Starter the most frequent schedule is daily.
Scan Now runs a scan at once. On-demand scans count toward your plan's monthly scans.
Scan on push (Team plan and up)
With scan on push, the git host tells Vulkro Cloud about every push, and Vulkro Cloud scans the branch. A pull request (or merge request) into a tracked branch starts a pull-request analysis (see Pull requests).
- In the repository's settings, open Webhook and choose Generate Secret. The secret is shown once.
- Add a webhook on the git host with the address and secret shown there.
- Turn on Scan on Push for each branch that should scan on push.
Every delivery must be signed with that secret, and unsigned or wrongly signed deliveries are refused:
| Host | How a delivery is signed |
|---|---|
| GitHub | X-Hub-Signature-256 (HMAC-SHA256 of the body) |
| GitLab | X-Gitlab-Token |
| Bitbucket (Cloud and Data Center) | X-Hub-Signature (sha256) |
Deliveries are limited to 60 every 10 minutes per repository. Regenerate Secret replaces the secret at any time. Scan on push works on GitHub, GitLab and Bitbucket, not on a repository connected as Other / Self-Hosted.
Quality gates
A quality gate decides whether a branch or a pull request passes. Each condition counts something and fails when the count is above its threshold.
The default gate
Every workspace has a Default gate, on every plan. It fails when a scan finds:
- any new Critical issue,
- any new High issue, or
- any new secret.
"New" means first seen on the repository's default branch within the workspace's new-code period: 30 days by default, from 1 to 365 days, set by a workspace admin on the Quality Gates page.
Your own gates (Team plan and up)
On the Team plan and up you can create, edit and delete gates, and pick which gate each repository uses. A gate's conditions can count:
| Metric | Counts |
|---|---|
| New Critical issues | Critical issues first seen in the new-code period |
| New High issues | High issues first seen in the new-code period |
| New Medium issues | Medium issues first seen in the new-code period |
| New issues | Every issue first seen in the new-code period |
| New proven issues | New issues whose path is proven in the code |
| Open Critical issues | Every open Critical issue |
| Open High issues | Every open High issue |
| New secrets | Secrets first seen in the new-code period |
Each condition has a whole-number threshold (0 fails on the first one). A workspace can have up to 50 gates, and one of them is the default for repositories that do not pick their own (Make Default Gate).
Where the result shows
- The Gate column on the repository's Branches tab, and each scan's record.
- The repository's settings (Quality Gate) and the workspace dashboard.
- On pull requests, if pull-request checks are on: the commit status (or check run) and the summary comment.
Notifications can tell you when a gate fails ("Quality Gate Failed"): see Notifications and Jira.
Locally, too
The same idea runs on your machine and in CI with the scanner: see
vulkro gate and CI/CD integration.