Get started

Install, sign in, scan, then gate the release.

Three commands to a first result and one more to make a bad merge fail. The install is a single binary with no service to run, the sign-in happens once per machine, and every scan after that reads your code from disk and sends none of it anywhere.

Start the 14-day trial How licensing works →

One binary, no service
One sign-in per machine
The scan itself needs no network

$ vulkro scan .

[CRITICAL] SQL injection in order lookup
  ↳ checkout.py:214 VULK-1042
[HIGH] Missing authorization on invoice download
  ↳ routes/invoice.ts:47 VULK-2117

4 findings: 1 critical, 2 high, 1 medium
CVE bundle: as of 2026-08-14 (11 hours ago)

A first run on a repository you already have. Every row cites the file and the line it was reported at.

01 / Install

One binary, anywhere on your PATH.

There is no installer, no daemon, no editor plugin required and nothing that runs in the background. Unpack it, put it on your PATH, and the command is available.

install vulkrosingle binary

curl -fsSL https://dist.vulkro.com/install.sh | bash

zsh, Intel and Apple silicon

Or download the tar.gz, check it against the published SHA-256, and put the binary anywhere on your PATH. Downloads

Every release ships a SHA256SUMS manifest next to the archives.

For Vulkro for Salesforce use install-sf.sh or install-sf.ps1 at the same location.

The installer resolves the current version, verifies the checksum, and drops the binary on your PATH.

Policy blocks piping a script into a shell in plenty of organisations, and that is a reasonable policy. Every archive is listed by version and platform on downloads, next to the SHA256SUMS manifest to check it against. Vulkro for Salesforce is a separate binary at the same location.

02 / Sign in

One sign-in starts the trial.

Scanning runs against a verified entitlement, so the CLI pairs with your account once per machine. Approving the device starts a 14-day trial of the full product. No card, nothing to cancel.

Create the account. An email address is enough. The portal is where devices are approved and seats are listed.
Run the sign-in command. The CLI prints a short code and opens your browser. Approve the code and the device is paired.
No browser on the machine? Paste a pairing code from the portal instead, or set a stored device token in the environment for a CI runner. All three routes end at the same signed lease.
No network at all? Air-gapped machines install a signed, machine-bound license file and never sign in. How licensing works.

Rollouts and air-gapped installs

$ vulkro login

Confirm this code in your browser: KWZR-4832
Opening: https://app.vulkro.com/connect
Waiting for approval...

Logged in. This device is now active.
Lease valid through 2026-08-29

Once per machine. The lease it installs is what keeps working while you are offline.

03 / First scan

Point it at the repository and read the summary.

Run it at the root of a project you already know. No configuration file, no rule selection, no project registration: the scanner detects the languages present and maps the routes your framework declares.

vulkro scan .The everyday run. Findings grouped by severity, each one citing a file and a line.

vulkro scan quick .Faster and stricter: high-confidence findings in source files, scoped to the last commit.

vulkro scan deep .The widest net: every confidence level, nothing dropped for being hard to reach. Expect more to read.

vulkro serveThe local console on your own machine, if you would rather click through the result than scroll it.

console - project overviewcheckout-service

Health

63/100No change in findings since the previous scan

1 critical, 2 high, 1 medium148 endpointslast scan just now

Deploy gate: fail1 critical (max 0)

The same result in the local console. The gate states the rule it applied rather than handing you a grade.

The gate verdict is the part to look at. A score on its own is decoration, so the strip always states the rule it applied rather than handing you a grade. The same verdict is what the CLI returns as an exit code, which is section 05 below.

04 / Read the result

Every finding carries the evidence for itself.

A finding is a claim about your code, so it arrives with the location it was reported at, the class of defect, the rule that fired, and the path the data took to get there. Open a row to see the path.

console - findings4 findings

Severity	Finding	CWE	Rule
CRIT	SQL injection in order lookup`checkout.py:214`	CWE-89	VULK-1042
Dataflow pathVULK-1042 01`checkout.py:214`request handlersource order_id read from request.args, no type or format check 02`services/orders.py:88`helper passed through lookup_order(order_id) unchanged 03`db/query_builder.py:41`query builder concatenated into the WHERE clause with an f-string 04`db/session.py:57`sinksink cursor.execute(sql) runs the assembled statement 4 hops resolved. No sanitiser between the source and the sink.
HIGH	Missing authorization on invoice download`routes/invoice.ts:47`	CWE-639	VULK-2117
HIGH	SSRF via user-supplied URL`proxy-handler.ts:23`	CWE-918	VULK-1180
MED	Hardcoded API token committed to the repository`config/stripe.js:9`	CWE-798	VULK-3304

One row expanded. The hops under it are the resolved path from the request to the sink, each with the file and line it passes through.

Severity

Severity is the impact of the defect, not a confidence score. Marked by shape and label as well as colour, so it survives a greyscale print and a colour-blind reader.

Location and rule

File, line, CWE and a stable rule id. Run the explain command with that id for the rationale, what the rule looks for, and what a correct fix looks like.

The path

For Python, JavaScript, TypeScript and Go the path can cross file boundaries, up to four hops. Java taint is same-file only, so a Java finding is evidenced within the file it is reported in.

Machine-readable output

The same result is available as JSON and SARIF for code scanning, as CycloneDX and SPDX for an SBOM, and as a report you can hand to someone who will never open a terminal.

Everything the scanner checks How the results are measured

05 / Gate the release

Fail the build on what this change introduced.

An existing codebase has history, and a gate that fails on the whole backlog gets switched off in a week. The honest posture for a repository with a past is to block only what is new.

New findings only. The gate command scans the working tree and the project at a baseline ref, then surfaces only what exists in the tree and not in the baseline. Pre-existing debt never blocks a pull request.
Set the baseline once. Point it at your trunk in the CI environment and every job inherits it, rather than passing the ref on every invocation.
Or gate on a severity threshold. For a new project with no history, failing the build on critical and high is simpler and stricter.
Then move it left. The same new-findings-only contract installs as a pre-commit hook, so the check runs before the push rather than after it.

Wiring it into a pipeline Gating dependencies too

$ vulkro gate --base origin/main
Comparing the working tree against origin/main.

[HIGH] SSRF via user-supplied URL
  ↳ proxy-handler.ts:23 VULK-1180

1 new finding. 0 pre-existing findings reported.

$ echo $?
1

Only the finding this branch introduced. The exit code is the whole contract with CI.

The exit-code contract. Every subcommand follows it, so a pipeline can branch on the number without parsing output.
Exit	What it means	What CI should do
0	The scan completed and reported nothing.	Let the build continue.
1	The scan completed and findings were reported. This is what the fail-on threshold trips.	Fail the build and print the findings.
2	The run itself failed: bad arguments, an unreadable path, an internal error.	Page the operator. A broken run must never read as a clean one.

Exit 2 is reserved for operational failure on purpose. A missing path or an unreadable database must never masquerade as a clean scan, and a pipeline that treats every non-zero code the same way will eventually ship on a run that never happened.

06 / Where next

The rest of the team, and the receipts.

You now have a scan, a result you can read, and a gate. What is left is choosing which surface you point it at, and checking our work.

The reviewVulkro

Reviews your code

Goes through every line of your codebase before a release, the way a senior engineer would if they had the time, and tells you what a customer could exploit.

You get: what to fix, and a pass or fail on the releaseWhat it checks

Vulkro for Salesforce

Reviews your Salesforce build

The same review for the part of your business that runs on Salesforce, including the settings in the org itself, and what the AppExchange security review will ask you for.

You get: a straight answer on whether you are ready to submitVulkro for Salesforce

The red teamVulkro RedComing soon

Attacks what they found

Takes the review and works out what an attacker would actually do with it: which small problems chain together into a real break-in, and which ones are noise.

You get: the attack, step by step, before someone else runs itHow it works

One engine behind all three, so the red team works from what the review already foundIt all runs on your machine. Your code never leaves it.

How we measure it Documentation Licensing