DDactic files vulnerability disclosures with vendors for the same reason a structural engineer reports a building code violation: the defect affects others beyond the organization that happens to be using the building right now. When DDactic's lab measurements identify a vulnerability class in a major cloud platform or CDN, the finding affects every organization using that platform. Filing a disclosure and waiting for the vendor to patch is not altruism -- it is self-interested behavior, because DDactic's customers use those platforms, and an unpatched vendor vulnerability limits what DDactic's hardening recommendations can achieve.
DDactic participates in HackerOne and Bugcrowd programs for platforms that are central to the organizations DDactic assesses: Cloudflare, AWS, Akamai, and others. Findings from this research feed back into the DDactic scan engine after disclosure and patch: a vendor vulnerability that was filed and patched yesterday becomes a version-check scan module today, identifying customers who have not yet applied the patch.
What We File and What We Do Not
DDactic files findings that meet three criteria. First, the finding is reproducible with a specific, documented reproduction case -- not a theoretical vulnerability but an observed behavior with measured impact. Second, the finding affects the target platform's users beyond DDactic's own lab infrastructure. Third, the vendor has a disclosure program or contact that provides a clear path to responsible disclosure with a defined response window. Findings that do not meet these criteria are documented internally but not filed externally, because filing a finding with no remediation path benefits no one.
DDactic does not file findings that are configuration issues rather than vendor vulnerabilities. If an organization has a misconfigured WAF, that is a finding in their DDactic assessment report, not a vendor bug report. The distinction matters because configuration issues require operator action, not vendor patches. Filing them to a vendor bug bounty program would be inappropriate and would dilute the signal for the platform's security team.
The Disclosure-to-Scan-Module Pipeline
The path from vendor disclosure to DDactic scan module follows a specific sequence. After a finding is filed, DDactic adds a "pending disclosure" tag to the internal research record and does not ship a scan module yet -- the vendor needs time to investigate and patch without attackers learning about the vulnerability from DDactic's scan activity. After the vendor confirms the finding and establishes a patch timeline, DDactic develops the scan module in parallel. When the patch is released and publicly announced, DDactic ships the scan module with the next engine update. This sequence ensures that DDactic's scan capabilities track vendor patch status, not just discovery date.
Consolidation vs. Splitting
When DDactic identifies multiple related findings that share a common root cause -- for example, a SSRF vulnerability class that manifests across four different Cloudflare services -- the disclosure strategy is to file one consolidated report describing the class, all observed instances, and the systemic root cause. Filing four separate reports of the same root cause creates noise for the vendor's triage team and risks being treated as multiple low-severity findings rather than one systemic issue. A consolidated report with a clear class description produces faster triage and more comprehensive patching.
Research findings are not customer findings
Vendor vulnerabilities discovered in DDactic's lab research are separate from the findings generated in customer assessments. Customers receive their own application-specific findings; they do not receive DDactic's vendor bug research. The research feeds the scan engine, not the customer report.
Assess Your Platform Versions
DDactic's scan engine includes version checks for known vendor vulnerabilities, identifying customers who are running unpatched versions of platforms where DDactic has filed or observed disclosures.
Run a Free Scan