Audit us: our engine is open, our reports are signed, and we'll show you the receipts

Every security product is a trust claim. "We found 14 vulnerabilities" means nothing unless you can check it. So this post is the boring, verifiable underbelly of Vergate: where the code lives, how findings are evidenced, how reports are signed, and the time our scanner caught our own launch mistakes.

#1. The engine is open — read how every check works

The scanner engine that powers Vergate's security findings is standalone and source-readable, with no dependency on our hosted platform. Each check is a documented class with a name, a description, a category and a priority. There is no proprietary "AI vibes" layer that produces findings — every finding is the output of a check you can read, running against your site.

If you ever wonder "how does it decide that?" the answer is: go read the check. It's not hidden, it's not patented, it's not a trade secret. That's a decision we made on purpose — security tooling that can't explain itself shouldn't be trusted with your site.

#2. Every finding shows its work

A finding isn't a verdict, it's an evidence packet:

• Severity (critical → info) and likelihood (observed / likely / possible)
• The evidence — the exact URL, header or payload that triggered it
• A description and a remediation with concrete changes

"Observed" means we reproduced it: here's the request, here's the response, here's why that matters. If you want to double-check us, re-run the same check and watch it fire again. We're not infallible — automated scanners produce false positives — which is why we label confidence honestly instead of shouting "CRITICAL" at everything. And on the other side of the ledger, we also say what we don't catch: no scanner catches everything, including ours. We say that in our terms and in our docs, because it's true.

#3. Reports are signed and tamper-evident

Any scanner can print a PDF. Ours are provable: every downloaded report carries a keyed hash (HMAC) of its exact bytes, and you can verify it through a public endpoint on vergate.dev. Edit the file after signing — change a severity, add a finding, remove one — and verification fails.

Why does this matter? Because a signed report is a document you can hand to a client, a compliance reviewer or your own future self, with cryptographic proof it hasn't been touched since we produced it. It's the difference between "trust the vendor" and "verify the artifact." We chose the latter.

#4. The receipts: our own scanner caught our own mistakes

The best transparency story we have is the embarrassing one. Within an hour of launching vergate.dev, we ran Vergate against Vergate. It found:

• a missing security header we'd forgotten (the kind of thing we'd written blog posts about)
• a TLS redirect nuance that would have degraded a subset of visitors
• an outdated component with a known CVE

We fixed all three, re-scanned, and confirmed clean. Nobody reviews their own launch perfectly — but a scanner that nags you about the checklists you preach about is a scanner you can trust, precisely because it doesn't care about your feelings.

#The standard we hold ourselves to

When you evaluate any security tool, ask it the questions we designed Vergate to answer:

1. Can I read how the checks work? If the logic is a black box, run.
2. Does every finding show evidence? A severity without a proof is a guess.
3. Can I verify a report after the fact? If the report is just pixels, it's marketing material.
4. What does the tool admit it can't catch? Tools that claim everything are the ones to fear.

Run our free scan on your own site — no account, no credit card — and read the evidence on the findings. That's the whole pitch: verify us the way you'd verify any claim about your security. We're set up for it.