The false-positive tax
Most scanners are pattern matchers. They emit a possibility for anything that resembles a known-bad shape. A dependency with a CVE in its manifest is flagged whether or not the vulnerable code path is ever reached. A static rule fires on a fragment that looks like injection whether or not any attacker-controlled input arrives there. The output is a queue of maybes.
Every maybe is a bill. Someone has to open it, reproduce it, decide whether it is real, and only then begin the fix. Most items never reach that far. The queue grows faster than it drains, the team learns that the queue exaggerates, and the genuine finding drowns next to the fifty that were never true.
That is the false-positive tax. It is not the cost of running the scan. It is the cost of reading it, and it is paid by the scarcest people you have.
Noise is not a finding
A finding is a claim about the world. "This might be exploitable" is not a claim, it is a hypothesis, and shipping a hypothesis as a result is how the queue fills with things nobody trusts. Kissaki draws the line there. It reports a vulnerability only when it can attach the evidence that the vulnerability is real.
The evidence is a reproducible proof: the concrete artifact that shows impact rather than resemblance. For a broken object authorization flaw, that is the request that read another tenant's record. For an SSRF, it is the outbound call the server was coerced into making. For a leaked credential, it is the secret located in the tree. The proof travels with the finding, so the reader is never asked to trust a severity label on faith. They are shown what happened and how to make it happen again.
Where Kissaki cannot prove impact, it says nothing rather than pad the queue. Silence on an unprovable case is a feature, not a gap: it keeps the reader's attention on the results that carry their own justification.
How the proof gets made
Two properties make that discipline possible. The first is that detection is deterministic. The same input returns the same finding on every run. There is no sampling and no model that answers one way today and another tomorrow. A result you can reproduce is a result you can attach evidence to, and a result you can regress against later.
The second is orchestration. The deterministic scanners do not work in isolation. Autonomous agents drive them across the whole surface at once: dependency, licence and end-of-life runtime analysis; static analysis and secret detection across the repository; container images, Kubernetes manifests and infrastructure as code; cloud posture on AWS, Azure and GCP; and web and API testing for broken object and function authorization, mass assignment, business logic, JWT handling, injection and SSRF.
The orchestration is what turns a static signal into an attempt. The agent takes a route the code analysis flagged as suspect and drives the actual request against the running API. The output is then not "this endpoint looks like it lacks an authorization check" but the response that returned data it should not have. That attempt, captured, is the proof. Determinism is what lets it be replayed; orchestration is what lets a suspicion in one scanner be settled by a live test in another.
Continuous, because proof reproduces
Proof is not a one-time audit artifact. Every asset rescans automatically, every 24 hours, and every 12 for cloud accounts. Because detection is deterministic, a finding either reproduces on the next run or it does not. A fixed issue closes itself. A regression is caught without a human polling the queue.
The same property is what lets a change be gated. When a pull request is measured against a reproducible baseline, a regression can be refused before it merges, because "regression" has a precise meaning here rather than a heuristic one. Reachability correlation ties a proven finding from the line of code to the endpoint where it is actually exposed. When a fix is offered as a pull request, it is opened for review and never applied for you.
Every one of those behaviours depends on the finding being a fact first. You cannot gate on a maybe, and you cannot safely automate a fix for a vulnerability you only suspect. Proof is the precondition for everything downstream of the scan.
What proof does for triage
When a finding carries its proof, triage stops being adjudication and becomes scheduling. The question is no longer "is this real" but "when do we fix it", which is the question a security team should be spending its attention on. The reproduction is doing the arguing, so the meeting does not have to.
Remediation trust follows from the same place. An engineer handed a proven finding does not push back on it, because an artifact is not an opinion. Exported records carry that weight with them. A SARIF or PDF report becomes an account of what was demonstrated, not a list of what a tool suspected. Control mapping points those proven findings at the SOC 2, ISO 27001, DORA, NIS 2 and HIPAA requirements they bear on, which is only defensible because the underlying finding is evidence rather than a guess.
The line we will not cross
This is not a claim that Kissaki finds everything. Determinism has an edge. A class of issue that cannot be reproduced from the outside will not be proven from the outside, and Kissaki does not dress a guess up as a result to cover that gap. Honest coverage is bounded coverage.
What it refuses to do is inflate. There is no possibility filed as a finding, and no result stated more strongly than the evidence behind it. The whole platform is EU-hosted, with zero retention, which is the same instinct applied to your data as to your findings: keep only what can be justified.
Scanners produce noise. Noise is not a finding. Kissaki proves impact, or it says nothing.