How we keep findings true: false positives we found on our own domains

The domains in this story are Infiqon's own: secqon.com, www.secqon.com and docqon.com, a sibling product. No customer data is involved. Our own domains are where we find our mistakes first, and publishing them is the fastest way to show what a SecQon finding is worth.

A scanner's output is only useful compared with the truth. On 28 August 2026 we audited a live report of docqon.com finding by finding: each of its 8 findings was checked independently by hand with curl and dig, and the report contained no mock data.

We did the same for secqon.com, and the scan and our hand-built list disagreed on 4 findings. That time the scan was right: the resolver on the machine building the list had been failing in bursts. But it pointed straight at a class of bug in the scanner too — a DNS lookup that failed was being read as a record that did not exist. The check now concludes a record is absent only from a real answer from the DNS, and reports "DNS lookups could not complete" otherwise.

That fix did not catch the next problem, because nothing failed. We compared the free instant check running locally with the same check in production. docqon.com matched exactly: 8 findings, score 85, in both. secqon.com did not: 5 findings and a score of 87 locally, 7 findings and 86 in production.

The two extras were No CAA record and DNSSEC not enabled. secqon.com publishes 10 CAA records and 2 DNSKEYs. The resolver our production service used could not serve those record types, and answered with a well-formed, successful, empty reply — which the check read as "none published".

A guard against failure is no guard against a confident wrong answer. So before concluding that a record type is absent, the check now asks the same resolver for that type on a control name known to have it. If the resolver cannot return it there, the check says it could not complete and makes no claim. The production findings were marked as false positives.

On 29 August www.secqon.com was told it had no DMARC record, no CAA record and no DNSSEC — three findings — while secqon.com above it publishes a DMARC policy of p=reject, 10 CAA records and 2 DNSKEYs. DMARC, CAA and DNSSEC are inherited from the parent domain; the checks had only asked about the exact name. Every subdomain asset, a type we sell, would have received the same three false findings.

The checks now follow the inheritance chain up to the registrable domain, as the standards describe (RFC 8659 for CAA, RFC 7489 for DMARC). SPF is not inherited, so it is still evaluated at the exact name.

False positives are the visible failure. The same week we found the quieter one: our deprecated-TLS probe could never report TLS 1.0 or 1.1, on any host, because the client library refused to offer them and the code read that as the server refusing. secqon.com and docqon.com both accept them. That is a false negative, and it is worse, because nobody complains about a finding they never saw. The full story is in "SecQon failed its own scan".

On 30 August we made revalidation structural. Each check now records how to find its finding again. Before a finding reaches the report, SecQon re-runs that exact observation against the live asset, through the same scope guard as the original request. The reproduction transcript is printed beside the finding, and it is the only route to the word "confirmed". Re-tests are grouped, so five missing headers cost one request rather than five.

On the first live run against docqon.com, 14 of 15 findings reproduced. The fifteenth was a status note — a record that a check could not complete — which has nothing to reproduce. A re-test that cannot run is kept distinct from one that ran and did not reproduce, so neither borrows the other's meaning.

The Deep scan of docqon.com on 30 August then had 0 false positives measured against a hand-built list of what was really there. That is a claim about that scan, not a promise about every scan, and we say so because the false positives above are real and documented.

Every finding carries one of four exploitability labels, and each one says what we actually did:

• Demonstrated — a bounded proof of concept changed the application's behaviour. Only three kinds of check can reach this: the reflected-markup proof, the SQL-injection differential and the out-of-band SSRF callback.
• Confirmed — a re-test reproduced the condition. A missing header seen twice is confirmed; it is not an exploit.
• Likely — observed once with evidence, not reproduced.
• Unconfirmed — a tool reported it, or it is a status note. Template matches never become confirmed on their own.

One more fix belongs here. A sweep that was cut short once told a reader that 5 live findings were "resolved" — because the truncated re-scan simply had not reached them. Findings a re-scan did not reach are now reported as not re-tested, never as fixed. A re-test that no longer reproduces a finding tells you the condition is gone, not why.

And when you mark one of our findings as a false positive, it is removed from the counts, the posture score and the compliance tables, so your report reflects your judgement as well as ours.