How we find what vendors hide.
A systematic approach to detecting undisclosed security patches, measuring vendor disclosure compliance, and translating technical findings for regulatory action.
Deceptive Remediation / Silent Patch Detection
We analyze commit histories at scale, identifying commits that carry security-relevant code changes but lack corresponding CVE assignments, security advisories, or public disclosure of any kind. Our proprietary Ghost Patch Scanner classifies commits by their code change patterns, commit message signals, and comparison against known vulnerability databases.
This is not keyword matching. The scanner analyzes what the code change does, not what the commit message claims it does. When a vendor changes an authorization check, adds input validation, or modifies a cryptographic operation, the scanner identifies the security class of the change regardless of how the vendor described it.
Fork Propagation Analysis
Open-source infrastructure is rarely used in isolation. A single upstream project may have dozens of forks, each serving different financial platforms. When the upstream vendor silently patches a vulnerability, downstream forks have no mechanism to assess their own exposure.
Our Cascade Propagation Engine maps every fork of a target project, identifies which security patches each fork has and has not incorporated, and quantifies the exposure window for each. The output is a precise map of who is vulnerable, to what, and for how long.
Impact Confirmation
Detection without verification is noise. Every finding flagged by our tooling undergoes manual confirmation. We trace the vulnerable code path, confirm that the condition is reachable in production configurations, and assess the actual security impact.
Findings that survive verification are classified by severity using CVSS 3.1 scoring. Findings that do not survive verification are documented and discarded. We do not report hypothetical vulnerabilities.
Regulatory Translation
A confirmed vulnerability with a CVSS score means nothing to a securities regulator. The same finding, expressed in terms of investor exposure, market manipulation risk, and custody failure, is actionable.
Regulatory: “The alarm system protecting $7.16 billion in assets traded on OSC-registered platforms catches break-ins 12% of the time. The alarm company knows. They have not told anyone.”
Every finding we produce is presented in both languages. The technical version is for peer review and MITRE filing. The regulatory version is for enforcement action. The gap between these two versions is where vendor silence has historically thrived.
MITRE-Direct Disclosure
We file CVEs directly with MITRE, bypassing vendor-controlled CNA processes. When a vendor is the one concealing the vulnerability, asking the vendor to assign a CVE is asking the fox to inventory the henhouse.
Our disclosure timeline is 72 hours from vendor notification to MITRE filing. This is not a courtesy period for the vendor to prepare a fix. This is a notification that a public record is about to be created. Vendors who have demonstrated good-faith disclosure practices earn longer timelines. Vendors who have demonstrated concealment do not.
The methodology works. The numbers prove it.
6,700+ silent patches documented. 25+ CVEs filed. 0.44% industry disclosure rate measured and published. Every number comes from this process.