We conduct security research and regularly report vulnerabilities to manufacturers and operators. Today, however, we do not wish to discuss individual findings, but rather to focus on what happens after a vulnerability is discovered: the responsible handling of a discovered vulnerability.
Reporting these vulnerabilities is less a rigid procedure and more a professional relationship between equals. It works when researchers and companies communicate clearly with one another. And it fails when one side breaks that trust. This article outlines the different disclosure models available, which one we choose, and why.
We explain how, in our view, both sides should communicate and what guidelines can be followed on the path from identifying a vulnerability to reporting it as a report.
What disclosure models are available
As soon as a vulnerability is found, the key question arises: who finds out what, and when? This broadly leads to three approaches.
🔵 Coordinated Disclosure
- Also known as ‘Responsible Disclosure’
- The discoverer and the manufacturer coordinate their actions
- The manufacturer is given time to develop a fix
- Disclosure only takes place afterwards, by mutual agreement
- Standard practice in professional research
🟠 Full disclosure
- Vulnerability is made fully public immediately
- No lead time for the manufacturer
- Puts pressure on the manufacturer
- Puts users at risk without a fix in place
- Legitimate only as a last resort
Non-disclosure:
The vulnerability is not reported at all, but is concealed, hoarded or sold. In our view, this is the opposite of responsible behaviour.
Why we disclose in a coordinated manner
For us, coordinated disclosure is the default approach. Our aim is to highlight and rectify issues, not to contribute to insecurity. As long as a vulnerability is public but unpatched, this primarily helps those we are working against.
Full disclosure may nevertheless become necessary. If a manufacturer fails to act for a long period of time and users remain at constant risk as a result, it is a legitimate tool for building pressure and warning those affected. However, it is never the starting point for a report. It comes at the end of a chain, not at the beginning.
Can the manufacturer even respond?
Responsible disclosure does not begin with the report itself, but with the choice of research target. A sensible question to ask beforehand is: Who would receive a report, and would the manufacturer or operator even be able to do anything with it?
A white-label device from a manufacturer with no website, no contact details and no update mechanism leaves no one to inform and no way to obtain a fix. This raises an uncomfortable question: if a system does not even offer the possibility of delivering updates, and there is no one available who could close the vulnerability, should such a system be researched at all? There is no one-size-fits-all answer. Here, the benefit of warning about an insecure product must be weighed against the expected harm caused by disclosing a security vulnerability. This is a question that belongs at the start of the research process, not at the end, once a vulnerability has already been found.
Our guiding principle:
what we research is determined first and foremost by its social relevance. A vulnerability whose resolution protects many people carries greater weight than a discovery with no real benefit. A warning can provide protection, even if the vulnerability cannot be fixed.
From discovery to report: the practical process
Once the vulnerability has been identified, a process follows that can be broken down into five steps. Each of these has its own pitfalls.
Demonstrating the impact
A report is only of value if the manufacturer can reproduce the problem. The evidence must therefore be robust. At the same time, the principle applies: as much as is necessary, not a jot more. If, for example, a vulnerability allows access to another user’s data, you set up two test accounts of your own and use one to access the other’s data. This fully demonstrates the vulnerability without ever compromising real user data. It is precisely this line that separates reputable research from an approach that would be punished in court.
Finding the controller
Before you can report a vulnerability, you need a recipient. Ideally, this is a security.txt, a standardised file in accordance with RFC 9116, which is located in the path /.well-known/ and specifies the security contact and, often, a suitable key. If this does not exist, a designated security contact, a vulnerability disclosure programme or a bug bounty platform can help. If none of these are available, the only option is to use the general contact channel.
Report clearly and securely
A good report is one that the recipient can work with immediately, without having to ask for further details. This includes a clear, reproducible description of the issue, the affected versions or configurations, and a realistic assessment of the impact. Sensitive details should be transmitted via an encrypted channel, for example using the key from the security.txt. Just as important as the content is the tone: objective, clear and on an equal footing.
Set a deadline
A deadline – that is, the time between the report and its publication – balances two legitimate interests: the manufacturer needs time to produce a proper fix, whilst users need a foreseeable end to the threat. It is crucial that the deadline is communicated in advance and that both sides are aware of it.
Coordinate disclosure and ensure the vulnerability is referenceable
The end result is a jointly agreed publication date. A CVE number from the CVE programme makes the vulnerability uniquely identifiable, enabling security professionals worldwide to identify it and check their own systems. However, the process is only complete once the fix is in place.
Various standards have become established within the industry. Google Project Zero allows 90 days, followed by a 30-day grace period after the release of a patch. CERT/CC traditionally operates on a 45-day basis. The 90-day mark, in particular, has become the standard benchmark. International standards ISO/IEC 29147 and 30111 describe this exchange from the perspective of both sides and provide a useful framework.
If the manufacturer does not respond
If no reply is received, the initial reaction is often frustration. This is understandable, but premature. Silence does not mean indifference. Security inboxes are often overflowing, and recently in particular, a great deal of automated AI spam claiming to reveal fabricated security vulnerabilities has been ending up there, causing genuine reports to get lost in the mix. Perhaps the person in charge is on holiday and nobody is currently monitoring the inbox. Before assuming a refusal, it is worth being patient.
In practical terms, this means following up politely several times at intervals. Try other ways of getting in touch, such as a second email address, the general contact form or a named contact person. In any case, you should ask for a brief acknowledgement of receipt in your first report to ensure that it has been seen and is being dealt with.
If there is no response whatsoever via multiple channels over an extended period, we consider the researchers’ duty of care to have been fulfilled. In that case, the agreed deadline is first allowed to elapse. If this also passes without a response, the next step is to involve a mediator. This is an absolute exception.
Possible mediators include a national CERT, the BSI acting as an intermediary, or, in more serious cases, the CERT/CC. Such bodies accept reports, liaise with the manufacturer and manage the deadline. At this stage, we allow a grace period of 30 days for the manufacturer to respond so that further steps can be coordinated. This is because publication without a fix puts precisely those users we wish to protect at risk and, in our view, would constitute not a responsible but an irresponsible disclosure.
Only when, even with the help of a mediator, there is no willingness to engage in dialogue and users remain at risk in the long term does full disclosure become a last resort. It marks the end of a long, documented process, not the beginning.
Mint Secure GmbH
Do’s and Don’ts for Researchers
A summary of the important points.
✅ What researchers should do
- Conduct research in a test environment where possible
- Otherwise, take a minimally intrusive approach and provide only the necessary evidence
- Identify the controller and report the matter in encrypted form
- Communicate objectively and as equals
- Set a fair deadline and adhere to it
🚫 Researchers should avoid the following
- Extracting production data
- Disclosing everything immediately without warning
- Threatening or demanding something in return
- Spreading their presence in the system beyond what is necessary
When both sides are in the wrong
An escalation rarely arises from pure malice. More often than not, a report goes awry when researchers cross ethical or legal boundaries whilst, at the same time, communication breaks down on one of the two sides. In the worst-case scenario, this leads to a legal dispute that helps no one. It costs both sides time, money and trust, and it is precisely in these cases that the actual issue remains unresolved for the longest time.
Professional conduct is therefore not a one-way street. It is required on both sides of the table.
Receiving a report correctly
Let’s change perspective. How should a company react when it receives such a report?
The most important insight: a report is not an attack, but free quality assurance. Some researchers have sought it out deliberately, whilst others have stumbled upon the problem more by chance. In both cases, nobody forced them to report the security vulnerability. In our view, this should be recognised.
Clear policy
Publish a Vulnerability Disclosure Policy that specifies what research is permitted and how vulnerabilities should be reported.
Accessibility
Provide a security.txt and provide an encrypted channel for sensitive details.
Reliable turnaround time
Confirm and triage reports promptly, and agree on a realistic deadline together.
- Publish a Vulnerability Disclosure Policy that clearly states what form of security research is permitted and how vulnerabilities should be reported
- Provide a
security.txtso that researchers can find the right point of contact straight away - Offer an encrypted channel for sensitive details
- Acknowledge and triage reports promptly
- Agree on and adhere to a realistic deadline
- Resolve the issue and disclose it in a coordinated manner
- Identify the reporters, if they so wish
It is equally clear what not to do. Anyone who ignores a report, plays it down or immediately responds with legal action comes across, above all, as unprofessional. This creates the impression, to the outside world, of an organisation that does not have its own security under control and does not know how to deal with well-intentioned help. This impression lingers, often longer than the vulnerability itself.
Conclusion
At its core, responsible disclosure is not a checklist, but a professional relationship between equals. Deadlines, security.txt files and escalation procedures are merely the tools that structure this relationship. When communication works, both sides benefit – and ultimately, so do the users.
Are you conducting your own research and looking for partners for coordinated disclosure? Or have you noticed something that, given its social relevance, warrants further investigation?
Sources:
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt) ·
CVE Programme: Common Vulnerabilities and Exposures ·
BSI: Federal Office for Information Security
