Use case · Engineering and DevOps
Stop a vulnerable release before it ships.
Vulkro fails the build only on problems it can prove, and only on what this change added, so the gate stays switched on.
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
- Jenkins
- CircleCI
With Vulkro Cloud, the release gate and pull-request checks need no CI change: connect the repository and they run there.
01The problem
Most security gates end up switched off.
Teams want a gate. What they often get is a red build they learn to ignore.
- Blocked by old debtA pull request fails for problems that were in the code long before it.
- Blocked by guessesA pattern match fails the build the same way a proven problem does.
- Buried in a logThe reason for a red build sits in a CI log, not on the pull request.
02How Vulkro helps
Fail on what is new and proven. Report the rest.
The gate compares the change with its base branch. Problems already there are reported but do not block. A new, proven one stops the merge and shows on the pull request.
Pull request #482 · Add order exportChecks
A severity gate, a baseline file and SARIF output, plus a comparison with the base branch and comments on the pull request. In CI, a key from your portal licenses the run.
03Why it holds up
Precise, and checkable.
- 01Exit codes CI can trust0 for clean, 1 for findings, 2 when the scan could not run. A crash never passes as clean.The same contract on both command-line tools
- 02Proven firstCritical and High are kept for problems Vulkro can back with evidence: a traced data flow, a verified secret or a matched advisory.Not checked findings never fail a build
- 03No surprises on the pull requestDevelopers see the same findings in the editor first, so the gate rarely has to say no.One engine in the editor, the terminal and CI