Evidence-Verified Findings: How 2MNY Confirms Vulnerabilities Are Real
Every critical and high finding is re-checked live after the scan: the platform re-fetches the evidence and labels each finding Verified Live, Remediated, Unreachable or Not Machine-Verifiable.
Most scanners hand you a list of alerts and leave you to figure out which ones are real. 2MNY takes a different approach: every critical and high finding gets re-verified after the scan completes — the platform re-fetches the evidence URL it captured during the scan and records what it finds. Your reports show the outcome as a badge on each finding.
This is how the verification layer works, and what each label means.
The verification pass
During a scan, each finding captures its evidence — the response, URL, or artifact that proves the issue exists. After the scan, the verification engine (called the maestro oracle internally) re-requests the evidence URLs of all critical and high severity findings:
- The pass runs twice daily across the platform, covering the last 24 hours of critical/high findings.
- A backlog drain runs daily, progressively re-verifying older critical/high findings that were never checked — bounded to 400 findings per day so your sites never see a traffic spike.
Verification only ever reads: it sends a HEAD request first (falling back to a small ranged GET when a server rejects HEAD). It never submits forms, never exploits, never modifies anything.
The four verification badges
| Badge | Meaning | What it means for you |
|---|---|---|
| VERIFIED LIVE | The evidence URL still responds exactly as it did during the scan — the vulnerability is confirmed present right now, not just when the scan ran | Fix this — it is real and reachable |
| REMEDIATED (VERIFIED) | The evidence URL now returns 404/410 — the exposure is gone | Good news; the finding is on its way out of your next report |
| UNREACHABLE AT CHECK | The server did not respond to the verification request (timeout, 5xx, or blocking) | Check again later; the scanner could not confirm either way |
| NOT MACHINE-VERIFIABLE | The finding's evidence is not a re-checkable URL (e.g. a DNS record observation or a policy analysis) | Human review determines validity |
Where you see verification
- Report header — an Evidence Verification band summarizing how many critical/high findings were re-checked and their outcomes, with the date of the most recent check.
- Per finding — a badge next to each critical/high finding in the Complete Vulnerability Register.
- Admin dashboards — verification chips on findings lists and a per-scan verification snapshot.
The false-positive safety net (negative controls)
Verification is the positive side of quality control. The negative side runs daily too: every HTTP-surface scanner is also run against a known-clean control site built inside the engine. A scanner that reports problems on a clean target is a scanner producing false positives — its unresolved findings are automatically quarantined (suppressed, evidence preserved) and its accuracy is down-weighted until the issue is fixed.
Together, the two mechanisms mean:
- A finding in your report was produced by a scanner that passed its clean-control test, and
- If it is critical or high, its evidence was re-checked live after the scan.
Frequently asked questions
Does verification change my findings? No. Verification is advisory — it labels findings, it never deletes or auto-closes them. Only rescan diffs (a finding no longer present in the next scan) resolve findings permanently.
What about medium/low findings? Verification effort is focused where it matters most: critical and high findings drive risk, so they get the live re-check. Lower severities are still covered by the negative-control system.
Can I request re-verification? Yes — contact support or re-run a scan; every new critical/high finding enters the verification queue automatically.