Use case · Engineering and DevOps
Stop a vulnerable release before it ships.
A gate that fails on every old warning gets switched off within a week. Vulkro fails the build on what is proven, and, with the diff-scoped gate, only on what this change introduced.
Vulkro Core · Vulkro for Salesforce · VS Code extension
Anyone can run their own SQL through the order search
- Entry pointsrc/routes/orders.ts:4
router.get('/api/orders', async (req, res) => {Express route · no sign-in needed - Callsrc/routes/orders.ts:5
const rows = await searchOrders(req.query.q)the search term passed straight on - Sinksrc/services/orders.ts:4
pool.query("SELECT * FROM orders WHERE customer_name LIKE '%" + term + "%'")SQL built from the request, no binding
- Who can reach it
- Anyone, no sign-in
- What is at stake
- Every customer's data
- Guards on the path
- None. The value is never bound
- Disposition
- Proven: traced from the request to the query
- Fix
- Bind the value:
pool.query('... LIKE $1', [`%${term}%`])
01The problem
Most security gates end up switched off
Teams want a gate. What they get is a red build they learn to ignore.
Blocked by old debt
A pull request fails for findings that were in the code long before it, so the author cannot fix them and stops reading.
Blocked by unproven findings
A finding that only matched a pattern fails the build the same as one with a proven path to the sink.
Results in a log
The reason for a red build sits in a CI log nobody opens, not on the pull request where the review happens.
02How Vulkro handles it
What each part of Vulkro does
- Fails on Critical and High by default, and only findings with evidence behind them keep that severity (Free)
- Findings that cannot be decided from source never fail the build, and are still reported (Free)
- Only what is new against a branch or commit: `vulkro gate`, the changed-lines lane and the ratchet (Pro)
- Results on the pull request as a summary comment, inline comments or annotations (Pro)
- The same exit-code contract and SARIF for code scanning (Free)
- Fail only on findings new since a git ref (Pro)
- Pull-request output for GitHub, GitLab, Bitbucket and Azure DevOps (Pro)
- In a pre-commit hook without Pro, the free check runs on the changed files instead of refusing the commit
- The same engine and suppressions as CI, in the editor
- A parity check that maps your editor view to the CI command
- A baseline in the editor that shows only what is new
03The workflow
Steps from first scan to fix
- 01Vulkro Core
Add the scan to CI
One install line and one scan step. Exit 0 passes, 1 fails on findings, 2 means the scan itself could not run.
- 02Vulkro Core
Gate on what is proven
The default policy fails on Critical and High, which Vulkro reserves for findings with evidence behind them.
- 03Vulkro Core
Scope it to the change
Compare against the base branch so existing debt never blocks a pull request, only what this change added.
- 04Vulkro for Salesforce
Put it on the pull request
Upload SARIF, or post the new findings as review comments where the reviewer already is.
- 05VS Code extension
Fix before pushing
Developers see the same findings in the editor first, so the gate rarely has to say no.
04What you get
What you get
- Exit codes
- 0 for clean, 1 for findings, 2 for an error. A crash never passes as clean.
- Proven first
- Critical and High are kept for findings Vulkro can back with evidence: a proven data flow, a verified secret or a matched advisory.
- New only
- The diff-scoped gate compares two trees, so a new caller into old vulnerable code still counts (Pro).
- On the PR
- SARIF for code scanning on Free, comments and annotations on Pro.
- Free and Pro
- A severity gate and a baseline are free. The diff-scoped gate family and pull-request output are Pro.
Questions
Common questions
- What is free and what is Pro?
- A gate on severity, with your own baseline file and SARIF output, is free on both CLIs. Failing only on findings new since a git ref, the ratchet, and comments and annotations on the pull request are Pro.
- What does "new" mean exactly?
- vulkro gate scans your branch and the base ref and compares the two finding sets. The changed-lines lane is faster but only sees findings on lines the change touched.
- Which CI systems work?
- Anything that runs a command and reads an exit code. The docs have ready snippets for GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI and Jenkins.