Silent Patch Bounty Program

Same rules they use on researchers. Applied to vendors.

Bug bounty platforms built a system where vendors triage, downgrade, and reject researcher findings using severity classifications and scope rules. We adopted the same framework. Same triage language. Same severity scoring. Same finality. The difference: the target is concealment, not code.

01

Community Reports

You found a silent patch in an open-source project. A dependency bump that quietly resolved a CVE. A commit message that says “refactor” but changes authentication logic.

Submit the evidence. If validated against the taxonomy and a CVE is filed, you earn a bounty. Anonymous submissions accepted.

Open to all
02

Whistleblower Reports

Your organization is suppressing vulnerability disclosure. Hiding patches behind misleading commits. Pressuring researchers into silence via NDA. You have original information derived from your own knowledge, communications, or observations in your employment.

Under Ontario’s Securities Act and Commodities Futures Act, contractual provisions designed to silence you from reporting securities-related misconduct are void. Your NDA does not protect your employer. It protects you. Employers who take reprisals face enforcement action and civil liability, including reinstatement and two times lost pay.

Submit through Whiten Baker and the evidence reaches regulators through our pipeline. Not through you. Anonymous submissions accepted. Protections apply regardless of whether enforcement action results.

03

Vendor Self-Disclosure

You know you have undisclosed patches. You know our scaffolding is monitoring your ecosystem. You can wait for us to flag it and deliver it to a regulator inbox. Or you can come forward.

Self-disclosed patches are filed as “proactive disclosure” instead of “detected concealment.” The CVE still gets filed. But the narrative changes from “caught” to “cooperated.”

Amnesty window open
Detection Coverage

Every way they hide. Every way we find it.

Vendors fix vulnerabilities without telling anyone. They relabel security patches as “refactoring.” They bury critical fixes inside thousand-line feature PRs. They use bot accounts, ghost contributors, and foundation intermediaries to obscure who knew what and when.

We mapped every technique. All of them. Then we built automated detection for each one.

Detection Engine: Mythos Scaffolding
93.4%
Composite
Confidence

7-layer augmented architecture built for continuous silent patch detection. Currently active across 9 of 32 supported ecosystems. Expanding.

Theoretical ceiling: ~94.3%. Further augmentation degrades system stability. We publish our ceiling because no honest system claims 100%.
Coverage Summary
52
Techniques
Validated
31 fully automated · 10 heuristic · 11 context-dependent · 5 closed informational
Detection Tiers

Three layers. Zero gaps.

31

Automated Detection

Commit-level obfuscation, history manipulation, platform abuse, dependency chain laundering, build-level concealment, and behavioral evasion. The scaffolding classifies every code change in real time. No human in the loop.

Zero human review required
10

Heuristic Detection

Pattern analysis across oversized PRs, conditional compilation tricks, rename-then-fix sequences, and AI-assisted refactoring disguises. Higher noise floor. The scaffolding flags; an analyst confirms.

Scaffolding flags · Analyst confirms
11

Context-Dependent

Cross-company fix laundering, foundation intermediaries, audit suppression, NDA silencing, planted contributors, and temporal dispersion. Requires organizational intelligence. Temporal correlation is the signal.

Analyst-led · Scaffolding correlates
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
Evidence 01 / Submission
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.
H1: Alive H2: Alive H3: Alive
Evidence 02 / Triage
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.
H1: Strained H2: Alive H3: Alive
Evidence 03 / The Patch
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.
H1: Critical strain H2: Strained H3: Consistent
Evidence 04 / Silence
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.
H1: Eliminated H2: Critical strain H3: Consistent
Evidence 05 / The Fix
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.
H1: Eliminated H2: Eliminated H3: Confirmed
Evidence 06 / The Platform
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.
H1: Eliminated H2: Eliminated H3: Confirmed + Systemic
Evidence 07 / The Pattern
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.
H1: Eliminated H2: Eliminated H3: Policy-level
H1 · Innocent

Good-Faith Process

Eliminated at Evidence 04
H2 · Innocent

Process Failures

Eliminated at Evidence 05
H3 · Adverse

Coordinated Suppression

Sole survivor · Confirmed by all evidence
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.”

The Critical Finding

The conspiracy vulnerability.

The most sophisticated hiding techniques share a common dependency: coordinated silence across multiple people.

Cross-company fix laundering requires engineers at two separate organizations to agree, without written record, to disguise a security fix as routine maintenance. Audit laundering requires auditors and executives to agree that findings will never be published. NDA silencing requires legal teams, platform operators, and researchers to all comply indefinitely.

Every one of these is a conspiracy. And conspiracies have a well-documented failure mode.

The practical result.

Vendors who attempt organizational hiding take on more risk than vendors who simply disclose. The hiding does not reduce their exposure. It converts a fixable compliance issue into potential fraud.

One person sinks the ship.

One engineer who gets passed over for promotion and decides to talk.
One contractor whose NDA expires and starts a blog.
One auditor who gets subpoenaed in an unrelated case and has to produce engagement records.
One Slack message that surfaces in discovery during litigation.
One researcher who decides the $500 bounty is not worth permanent silence and files with MITRE directly.

Every person added to the conspiracy is a point of failure. Every legal agreement is a document that proves knowledge of the vulnerability and intent to suppress disclosure.