Responsible Disclosure

What is responsible disclosure?

Responsible disclosure is the practice of reporting a security vulnerability privately to the organisation that can fix it, giving it a reasonable time to do so, and publishing details only afterwards. The industry now prefers the term coordinated vulnerability disclosure (CVD), because “responsible” was read as a judgement about the finder and because the process involves coordination between finder, vendor and often a coordinator such as a national CSIRT.

The alternatives mark the extremes: full disclosure publishes immediately, with the argument that users deserve to know; non-disclosure keeps the vulnerability secret, which is what happens when there is no process. Typical embargo periods are 45 to 90 days, with extensions when a fix needs more time and shorter deadlines when the vulnerability is already being exploited.

Where is it defined?

Two ISO standards define the process. ISO/IEC 29147 covers vulnerability disclosure: how an organisation receives reports, communicates with finders and publishes advisories. ISO/IEC 30111 covers the internal handling: triage, analysis, fix development and release. RFC 9116 defines security.txt, the machine-readable file at /.well-known/security.txt that tells finders where to report.

In the EU the Cyber Resilience Act turns practice into obligation. Annex I Part II requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy (point 5), to provide a contact address for reports (point 6), to address and remediate vulnerabilities without delay and to publish information about fixed vulnerabilities. Article 14 adds reporting to authorities for actively exploited vulnerabilities through the single reporting platform: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days, applicable from 11 September 2026. NIS2 Article 12 asks member states to designate a CSIRT as coordinator for CVD and gives ENISA a European vulnerability database.

In Germany, sections 202a to 202c of the Criminal Code apply to unauthorised access and to tools for it. A disclosure policy does not change that law, but it tells researchers what the company tolerates, and the BSI acts as coordinator for reports to German organisations.

What it means in practice

For a manufacturer or operator, a working CVD process has a few concrete parts: a security.txt and a policy page that state scope, the promise not to pursue good-faith research within defined rules, expected response times and whether credit is given; a mailbox or form that reaches the product security team instead of sales; triage with severity rating; a fix, an advisory and a CVE identifier, either through a CNA or a coordinator such as CERT@VDE for industrial products; and notification of affected customers.

The failures we see are predictable: no contact at all, so reports arrive on LinkedIn; a legal letter as the first reply; the fix postponed to “the next product generation”; no CVE, so customers’ scanners never learn about the issue; and no link between the external process and the internal vulnerability management that the CRA also requires.

From the testing side: findings from a penetration test belong to the client. When a test uncovers a vulnerability in a third-party component, we report it to that vendor with the client’s consent and coordinate publication. Zyberum publishes its own security.txt, and our free generator produces one for your domain.

Common misunderstandings

Responsible disclosure is not a bug bounty; no payment is implied. The CRA’s 24-hour deadline concerns reports to authorities about actively exploited vulnerabilities, not every report a researcher sends. And a disclosure policy does not make unauthorised testing legal; it states what the company will and will not pursue.