Vulnerability disclosure policies


For the last ten years or so, organisations have been trying to put in place operational policies to avoid vulnerability reports « in the wild » or other kinds of « full disclosure », whose methods leave much to be desired in terms of honesty and responsibility.

When it comes to accountability, the concept of « responsible disclosure » has all too often been the subject of endless discussion. On the one hand, vendors/publishers protest because they consider disclosing vulnerability without providing patches irresponsible. On the other, security researchers retort that what’s really irresponsible is the failure to correct vulnerabilities as quickly as possible.

This bickering between parties takes place at a crucial time when the system in question is at the mercy of attackers.

In an effort to be more efficient and do away with these sterile debates, many organisations have abandoned the concept of « responsible disclosure » in favour of « Coordinated Vulnerability Disclosure » (CVD). This approach stimulates cooperation between various cybersecurity players who share a common goal: making the Internet safer.

CVD is a process that aims to reduce risks and ultimately mitigate the potential damage caused by a vulnerability in an information system. This process consists of gathering information from security researchers, organising the sharing of this information between those involved, then disclosing the existence of vulnerabilities (related to software and/or material aspects), along with mitigation measures, to the various stakeholders, including the general public (especially when it comes to open source environments). CVD significantly increases the chances of success of any vulnerability response process. Contributions often consist of vulnerability reports written by researchers.

Vulnerability disclosure practices no longer apply only to web applications. The Internet of Things and the constellation of SCADA systems, connected health devices, surveillance cameras, connected cars, etc. have become so dependent upon software and the Internet that they are increasing the exposure perimeter and, as a result, will inevitably be exposed to new attacks. In this context, CVD can be a major ally in bringing together as many cyberspace players as possible and stimulating the exchange of knowledge to offer better security and privacy protection guarantees, right from the design stage of a product or solution. By encouraging cooperation, CVD also makes it possible to fight more effectively against the black market and « zeroday » vulnerability reselling.


Data disclosure process tools


a) txt: a promising RFC.

To facilitate the disclosure of one or more vulnerabilities on a website, the security researcher EdOverflow, inspired by the role of the famous robots.txt, suggested that, from August 2017, every website should include a security.txt file. This file, created by the website publisher, presents the procedure to follow for more effective and secure vulnerability disclosure.


b) Bug Bounty

As part of the agile development of their own products, more and more suppliers are choosing to be proactive by cooperating with computer security researchers:

– by drawing upon internal resources and expertise;

– by subcontracting directly with external researchers; or

– by using a platform connecting vulnerability researchers with solution publishers. The latter option pays researchers by the result depending on the number and type of vulnerabilities discovered, and allows different repair packages and options to be chosen, such as programme management or patch management, for organisations lacking sufficient internal resources to provide the necessary solutions.

The first European Bug Bounty platform, BountyFactory, created by YesWeHack, along with its community and service ecosystem, enables organisations and computer security researchers to cooperate better, thus greatly facilitating the establishment of a policy to encourage Coordinated Vulnerability Disclosure.


c) Non-profit cooperation with CERTs

What should you do if a product does not offer Bug Bounty or security.txt? Some products (software or physical items) do not have their own Bug Bounty programme. This makes it more difficult for security researchers to report vulnerabilities to the publishing company.

Platforms such as allow for secure or anonymous vulnerability disclosure by removing several obstacles: no login necessary, anonymisation of reports via the Tor network (.onion), proof of submission thanks to blockchain timestamping and automatic encryption of the report content using the public PGP key of the chosen CERT.


In a word: Let’s cooperate!




Stay tuned in real time
Subscribe to
the newsletter
By providing your email address you agree to receive the Incyber newsletter and you have read our privacy policy. You can unsubscribe at any time by clicking on the unsubscribe link in all our emails.
Stay tuned in real time
Subscribe to
the newsletter
By providing your email address you agree to receive the Incyber newsletter and you have read our privacy policy. You can unsubscribe at any time by clicking on the unsubscribe link in all our emails.