Responsible Disclosure

Software contains bugs that can be talked into doing things nobody intended. Such bugs are called security vulnerabilities, because they can, for example, be used to read out someone else’s data. Whoever finds such a vulnerability has two options. They can make it public immediately, or they can first report it to the company that makes the program. The second path is called responsible disclosure. The finder reports the vulnerability confidentially, waits for a fix, and only publishes the details afterward.

The race against the flaw

As soon as a vulnerability becomes publicly known, everyone knows about it. Including criminals, who use it to empty accounts or encrypt company networks. Programming a fix and distributing it to millions of devices, on the other hand, takes weeks. During that time, all users would be defenseless. Responsible disclosure delays publication so that the fix is ready first.

Nevertheless, publication is still part of the process, for two reasons. Users need to know how serious an update is, otherwise they won’t install it. And vendors who never have to fear anything public resulting from a report tend, by experience, to fix things more slowly. That’s why finders set a deadline, often 90 days. After that, they report whether a fix exists or not.

This should be distinguished from two extremes. In full disclosure, the finder goes public directly, without warning. In non-disclosure, they sell their knowledge to intelligence agencies or criminals, and the vulnerability remains open. Responsible disclosure is the middle path that security research and industry have agreed upon.

From discovery to a number in the registry

It starts with a report to the vendor. Larger companies have a dedicated contact address for this, often also a file called security.txt on their website. The report describes exactly how the flaw can be triggered. Without these instructions, the vendor often cannot reproduce the vulnerability.

Then the deadline begins. The vendor reviews the report, develops a fix, and distributes it as an update, known in technical jargon as a patch. In parallel, the vulnerability receives a globally unique identifier from the CVE registry, such as CVE-2024-3094. Later, everyone refers to the same flaw using this number, without having to describe it laboriously.

Only at the end comes publication, usually simultaneously by vendor and finder. The legal side is important here. Whoever searches for a vulnerability technically accesses someone else’s system, which can be a criminal offense. That’s why many companies publish a safe harbor pledge: they promise not to report good-faith finders to the authorities. Some even pay rewards, so-called bug bounties, which range from a few hundred to several hundred thousand euros depending on severity.

When security vulnerabilities make the news

Every major security update on a phone or laptop is usually the result of such a process. The accompanying notes often list the names of the finders and the CVE numbers. Even spectacular cases like the Java vulnerability Log4Shell in 2021 followed this process, albeit under heavy time pressure.

With AI systems, this topic is currently being renegotiated. There, it’s not just about classic programming errors, but also about ways to talk a language model into giving unauthorized responses. Providers like OpenAI or Anthropic therefore run their own reporting programs for such vulnerabilities. The point of contention is how much can be publicly described without providing a manual for abuse.

For investors and observers, how a company handles reports is a quality indicator. Companies that threaten finders with lawyers lose trust within the security community. A common misconception is also that many CVE reports are a sign of poor software. Often they mean the opposite, namely that someone is systematically searching and disclosing the results.