Open any vulnerability queue and you're looking at a list of claims. A scanner matched a signature, a version string, or a config pattern, attached a severity, and moved on. Whether an attacker could actually do anything with it, in this environment, from where they'd realistically be standing, is a question nobody has answered yet. The queue passes that question to a human and calls it triage.
We hold SecNode to a stricter rule: a finding isn't a finding until it's been reproduced. If an agent can't demonstrate the failure, it doesn't ship the claim.
What unverified findings actually cost
- Triage time: every claim has to be re-investigated by an engineer before anyone can act on it, which means the tool outsourced its hardest job.
- Misplaced effort: teams patch what scored highest, not what's exploitable, so real exposure waits behind theoretical exposure.
- Eroded trust: after enough false positives, engineers stop reading the reports. The tool becomes noise with a dashboard.
What verification means here
Verification is not running the scanner twice. When a SecNode agent suspects a weakness, it forms a hypothesis about how the system fails, then tests it: reach the target from a position an attacker could plausibly hold, exercise the flaw, and observe the impact. The whole attempt runs inside enforced scope, non-destructively, with approval gates in front of anything sensitive.
If the hypothesis survives contact with the environment, the agent records every step. If it doesn't, the claim dies quietly and no one gets paged. Speculation is supposed to die in the reasoning loop; that's what the loop is for.
A severity score is an opinion about a class of bugs. A reproduction is a fact about your system.
What ships with a verified finding
- A working reproduction: the exact steps that demonstrate the failure, replayable by an engineer.
- The path: where the attacker starts, what they traverse, and what trust boundaries they cross.
- Blast radius: what's reachable once the flaw is exercised, judged against the Memory Layer's model of your environment.
- A drafted fix: the same reasoning that proved the flaw writes the patch and the ticket.
Why this changes how teams work
When every finding arrives proven, the queue stops being a list of homework and becomes a list of decisions. Engineers review evidence instead of re-deriving it. Priorities follow demonstrated impact instead of catalog severity. And the number of items is far smaller, because most claims never survive verification in the first place.
The point isn't that severity scores are useless. They describe the class. But the class was never the question. The question is what an attacker can do to you, and the only honest answer is one you can replay.