DedSec Security Research
Ask a security engineer why they stopped trusting a scanner and the answer is almost never "it missed something". It is that they spent a morning chasing a finding, could not reproduce it, could not disprove it either, and closed it with a shrug. Do that four or five times and the tool becomes background noise.
The fix is unglamorous. Every finding carries the evidence that produced it. In Maphra that means the raw response behind the finding is retained per finding, and reports are generated from the same evidence rather than re-keyed into a document. This post is about why that single property carries so much weight.
A finding that says "missing security header on api.example.com, severity medium" is a conclusion. Evidence is what would let a second person reach the same conclusion independently:
That last item matters more than it looks. Two checks can produce the same finding title from completely different reasoning, and only one of them may be wrong.
Here is the single most productive bug class in scanner engineering, and it is worth understanding whether you build these tools or buy them.
A check is looking for a condition — an error string, a marker, a reflected payload. It has both the request and the response in scope. If the matching runs against the wrong side, or against a buffer that concatenates both, then the payload the scanner itself sent satisfies its own condition. The check fires on every asset it tests, with perfect consistency, and produces findings that look entirely legitimate right up until someone reads the evidence and notices that the "proof" is the scanner's own request echoed back.
The same shape appears in subtler forms: matching on a status literal rather than a status code, matching before decoding, matching against a redirect chain rather than the final response, or treating a provider error as a positive result.
You cannot catch any of this from a findings table. You catch it in the first ten seconds of reading the raw exchange. That is the argument for evidence in one sentence.
A large share of external findings are inferences from a version banner. The service says it is running version X, version X has a known CVE, therefore the asset is vulnerable.
Banners are unreliable in both directions. Distribution packages carry backported fixes while keeping the upstream version string, so patched hosts look vulnerable. Hardened deployments strip or fake the banner, so vulnerable hosts look clean. A findings list built purely on version inference will be wrong in both directions and gives you no way to tell which findings are which.
This is what active validation is for. Maphra validates exploitability against the live asset inside an explicit scope boundary you define, with a scope gate that keeps active checks off third-party hosts that merely appear in your surface. The output is a different class of item: not "this version is associated with a vulnerability" but "this specific condition was observed on this host at this time, and here is the exchange".
Both kinds of finding are legitimate. They should not be presented as though they were the same thing, and the evidence is what tells them apart.
Findings are deduplicated across scans and tracked through new, reopened and fixed rather than being re-reported every run. That only works if there is something stable to match on.
Without evidence, deduplication degrades to matching on a title and a hostname, which merges genuinely different issues and splits genuinely identical ones. With the observed detail retained, the same issue on the same endpoint collapses into one item with a history, and — more usefully — a finding that comes back after a fix is recognisable as a regression rather than a new discovery.
A trap that catches experienced teams: failure records persist far longer than the failures do.
Job queues, scan histories and error tables accumulate. Six weeks after a misconfiguration is fixed, the record of it is still sitting there, and someone reviewing the system reads a historical failure as a current one. Investigations get reopened, fixes get re-applied, and occasionally a working configuration gets "corrected" back into a broken one.
The discipline is simple and almost never followed: before declaring anything broken, check the timestamp on the evidence against the date of the fix. Evidence with a timestamp supports this. A finding without one cannot.
Risk scores get challenged. Sometimes by an auditor, more often by the engineering team being asked to do the work at short notice, and the challenge is always the same question: why is this a critical?
A score you cannot decompose loses that argument regardless of whether it was right. Maphra derives risk from observed exposure and its reachability and keeps the inputs visible, with a per-asset breakdown and trend over time, precisely so the answer is "here are the inputs" rather than "the model says so".
The same property is what lets one dataset serve three audiences. A board summary, an audit pack and an engineer's remediation ticket are different presentations of the same underlying observations, generated from the same evidence rather than transcribed at each step. Re-keying is where numbers start to disagree between documents, and disagreeing numbers cost more credibility than any individual finding.
Evidence is not documentation you attach at the end. It is the substrate the rest of the workflow runs on: