Software is writtenfaster than anyone reads it.

SECTION 01 // THE PACE

Review has to run at the speed the code is written.

The security problems that actually reach production are not exotic. A value from a web request reaches a database query without being escaped. An endpoint that returns another customer’s record has no check on who is asking. A dependency picked up months ago has a published vulnerability that nobody went back for. Every one of those is the kind of thing a careful reviewer catches, and none of them survives being read by someone who has the time.

Nobody has the time. When a change lands every few minutes and much of it was drafted by an assistant, the reviewer becomes an approver, and approval is not review. So the useful question is not whether a deep analysis is possible. It is whether a deep analysis can finish in the seconds a person is willing to wait, on the machine the change was made on, on every change rather than once a quarter.

That is the first constraint, and it decides most of the architecture. A review that has to be scheduled becomes a review that gets skipped, and the gap between the two is exactly where the vulnerabilities live.

SECTION 02 // THE VERDICT

A result you cannot reproduce cannot gate a release.

If a tool answers differently on the same code, it cannot be the thing that says no. It will fail a build one morning for no reason anyone can explain, someone will re-run it, it will pass, and within a week it is switched off or waved through. Then nothing is gated at all, and the organisation records a control it does not have.

So nothing in the review samples, and no model decides whether a problem exists. Two runs of the same version over the same code return the same list, in the same order, on any machine. A difference between two reviews is therefore a change in your code, which is the only thing that makes a comparison between them worth reading.

This is asserted in our build rather than promised on a page like this one. Two tests run the same review twice and compare the output, one of them through the parallel path, and they exist because the promise had already broken quietly on a large codebase once. A fix that nothing holds in place is not a fix.

There is optional AI help in the product, and it sits strictly outside that line. A small model running on your own machine can explain a finding in context or draft a fix for one. It never creates a finding, never removes one, and the accuracy test we publish is scored with it switched off. The cost of this position is real: we give up every technique that would raise the catch rate at the price of an answer that wobbles. We would rather have the answer you can build a release gate on.

SECTION 03 // THE BOUNDARY

Code that never leaves the machine is a property, not a promise.

Your codebase is full of half-finished ideas, comments nobody meant to publish, customer names in test fixtures and credentials somebody still has not rotated. None of that needs to sit on another company’s disk in order to discover that a query is being assembled by string concatenation.

Every vendor says it takes security seriously. That is a promise, and a promise is only as good as the network, the staff access controls and the incident response of the company making it. A property is a different kind of thing: it is true whether or not we behave well, and you can test it yourself this afternoon.

The review runs on your machine. What it reads, the map it builds of how your product fits together and the findings it writes all stay there. One small call leaves, and it carries licence and usage information: no code, no file names, no findings. Switch the product into offline mode and even that call is refused rather than quietly skipped, with a licence file standing in for it, which is how it runs on machines that have no route out at all.

$ VULKRO_OFFLINE=1 vulkro scan .
Offline mode: outbound calls refused.
CVE bundle: local copy, SHA-256 checksums verified.

  SECURITY FINDINGS

    2 critical, 5 high, 11 medium
    ↳ report written to vulkro-report.html

You do not have to take the paragraph above on trust, which is the entire point of writing the product this way. Run it under whatever your team uses to watch a process, and watch what it does. A review does not reach for anything on its own, so the only thing there is to catch on the wire is the licence check, and nothing at all when offline mode is on.

This position costs us the thing most vendors would not give up. We have no telemetry, so we do not know which features get used or which errors people hit. We find out when somebody writes to us. That is a worse product-management position and a better deal for you, and we are not going to quietly reverse it with an anonymous opt-in later.

SECTION 04 // THE SPLIT

The engine is ours. The scorecard is not.

Vulkro is not an open-source project and we do not describe it as one. The detection engine is the licensed product: it is how the company pays for itself, and it stays closed. Pretending otherwise would be the first dishonest sentence on a site built around not writing any.

What is published is everything you need to check the claim. How accuracy is measured, what counts as a real find and what counts as a false alarm, the full result, the release notes, and the reasoning behind every finding the product prints on your own screen. In the published test, the product finds 47 of 83 documented vulnerabilities and misses 36 of them (measured against vulkro 0.18.0 on 2026-07-18).

Those 36 stay in the test. Taking them out would raise every figure we publish and measure nothing.

Every vulnerability in this test is a real, publicly documented bug in a real application, confirmed by reading the code at that exact version. The ones Vulkro cannot find stay in the test rather than being removed. A vendor that publishes only the flattering half of a result is telling you where to look, and a figure with no method behind it is decoration. The full result, the scoring rules and the places the scanner loses are all on one page.

SECTION 05 // COMMITMENTS

What we hold ourselves to.

• Your code stays yours. The review never transmits code, file names, paths or findings. The licence check carries usage information only. This is the one commitment we will not negotiate, at any contract size.
• The method stays published, misses included. If a release catches less than the one before it, the same published test shows it. Vulnerabilities the product cannot find stay in that test instead of being quietly retired.
• Breaking changes get a deprecation window. A setting, an option or a field in machine-readable output does not disappear on you. The old name keeps working, with a visible warning, for at least one release.
• Nothing bills you by surprise. There is no checkout on this site. Licences are issued directly by our team on terms you agree to first, and when a term ends the product asks you to renew rather than charging you. Your reports, history and settings are already on your disk and stay there.
• We do not describe a capability you cannot run today. Anything announced but not yet installable is labelled as such, everywhere it appears, until the day it ships.

CODA // DISAGREE WITH ANY OF THIS

Then tell us where we are wrong.

The best messages we get are the ones that start by saying a finding is wrong, or that the product missed something obvious. Both are fixable, and neither gets fixed if nobody says it. There is no form on this site and no chatbot in front of the inbox: write to [email protected] about the product, to [email protected] about licensing a team, and to [email protected] about a security problem in Vulkro itself (the security policy covers what is in scope).

If you would rather read the company facts without the argument around them, the about page has them: what we make, how it is built, and how it is sold.