Investigative Framework

We tried to prove them innocent. Here is what happened.

Every finding we deliver uses Analysis of Competing Hypotheses. The CIA developed it. Intelligence analysts, forensic accountants, and securities regulators use it. We use it because it is the only framework that survives cross-examination.

The method: list every possible explanation for the evidence, including every innocent one. Then systematically test each explanation against the facts. You are not building a case for guilt. You are destroying every path to innocence. What survives is irrefutable because you already killed every alternative.

ACH Protocol
List all hypotheses, including every innocent explanation
Score each piece of evidence against ALL hypotheses
Eliminate hypotheses the evidence contradicts
The survivor is the conclusion, not the starting point
Live Example / Redacted

Case File: Consensus engine vendor and a major bug bounty platform.

A researcher submits a critical finding to a vendor through a major bug bounty platform. What follows is tested against three competing hypotheses.

H1 · Innocent

Good-Faith Process

The vendor operates a legitimate security program. Reports are triaged honestly, findings are remediated, and disclosure follows industry norms.

Starting status: Assumed true
H2 · Innocent

Process Failures

The vendor intends to operate properly but suffers from miscommunication, understaffing, or honest mistakes in triage and remediation timing.

Starting status: Assumed true
H3 · Adverse

Coordinated Suppression

The vendor and platform coordinate to close valid reports without credit, suppress disclosure, and silently patch while denying the finding externally.

Starting status: Must be proven
A researcher submits a critical vulnerability with a full proof of concept. The platform confirms it is “byte-accurately real.”
We test this against all three hypotheses. A real finding has been submitted and acknowledged. All three hypotheses survive. A good-faith process would accept this. An honest mistake has not happened yet. Suppression has not begun yet.
The confirmed finding is closed as “Informational” – not valid, not actionable – by a triager account with no prior history consistent with an independent security professional.
Under H1, the vendor’s good-faith process determined the finding was not exploitable. But the finding was already confirmed real. We try harder: perhaps the triager applied different severity criteria. H1 survives, but now requires an assumption. Under H2, an inexperienced triager made an honest mistake. H2 survives. Under H3, the triager account exists to close reports. H3 survives.
72 hours after closing the report as non-actionable, the vendor releases a patch addressing the exact behavior described in the submission.
Under H1, this is a coincidence. The vendor independently discovered, verified, and remediated the same vulnerability in three days while simultaneously determining the external report was not valid. H1 now requires two coincidences stacked on top of each other. Under H2, the triage was a mistake but the engineering team saw the report and acted. If so, why was the report not reopened? H2 now requires the mistake to be uncorrected despite internal awareness.
The patch receives no CVE. No security advisory. No downstream notification. 50+ fork networks continue running the vulnerable version.
Under H1, a good-faith process assigns CVEs to confirmed security fixes. A vendor with a legitimate security program does not ship a security patch with no advisory. H1 is dead. Under H2, the CVE was forgotten. But the advisory was also forgotten. And the downstream notification was also forgotten. Three independent omissions from a single honest mistake. H2 is dying.
The patch itself was generated by an AI tool (signature in commit metadata), merged by an account with no prior commit history, reviewed by zero humans, and merged in 83 seconds.
Under H2, this is understaffing. The team was stretched thin and used AI assistance. But a team stretched thin does not create a new account to merge a single commit. A team stretched thin does not generate a fix with an AI tool for a vulnerability they officially classified as non-actionable three days earlier. H2 cannot explain why a finding closed as “not valid” generated an emergency AI-assisted patch merged by a ghost account. H2 is dead.
The researcher requests platform intervention. The platform refuses. The vendor’s self-triage stands. No bounty is paid. The vendor’s own program rules state that the researcher should receive credit for confirmed findings.
Under H3, the platform’s refusal is consistent with a system where vendors control their own triage outcomes and the platform has no commercial incentive to override paying customers. The platform is not a neutral arbiter. It is a vendor-funded service that profits from report volume, not report outcomes.
The vendor’s patch introduced a new guaranteed denial-of-service condition. Four additional security fixes were bundled into the same release with zero CVE assignment. There is no safe version of this software. Seven CVEs were filed independently through MITRE. Zero were acknowledged by the vendor.
The vendor did not fail to disclose once. They failed to disclose seven times in a single release. This is not a process failure. This is a disclosure policy. The policy is silence.
ACH Conclusion

Every innocent explanation was tested first and failed.

No single piece of evidence convicts. The conviction comes from the systematic elimination of every alternative. This is how every finding we deliver is structured. Not “we found guilt.” Rather: “we searched for innocence, exhaustively, and it does not exist in the evidence.”

Now Playing
Burt — Brazen or Stupid?
0:00 / 0:00
Audio could not load. Check the <audio> src URL below.
Player