Coordinated Disclosure

We have successfully coordinated and published thousands of security vulnerabilities in the last three decades. There are different possibilities how we may become aware of a security vulnerability: Either we find a public disclosure, somebody sends a vulnerability submission to us, or our research team identifies one in a tested product.

If we think that a weakness is not yet known to the vendor, we try to contact them as quickly as possible to prepare a coordinated vulnerability disclosure. VulDB is not a bug bounty service nor do we guide researchers in vulnerability disclosures. We contact vendors on a voluntary basis to give them a chance to react properly. This might be a response with their own risk assessment or the quick release of a fixed version of the affected component.

⚠️ Note: This article explains how we approach a coordinated disclosure during the moderation process of new vulnerability entries. Please take a look at our Bug Bounty Program if you are interested in submitting a weakness which affects our service.

Contacting Vendors

During our unpaid involvement in the vulnerability community we handle hundreds of vulnerabilities per day which makes it very important for us to streamline our free efforts. First we try to find the official source of an affected software. Then we try to find a mail address to contact the product maintainer to inform them about the potential issues. Ideally, this is a security-related address channeling vulnerability reports. If no such dedicated address is available, we will use a more generic address if available.

If no mail address is shared and proprietary contact possibilities via web form, issue tracking, chat systems, or phone remain, we will not pursue the coordinated disclosure any further. Our resources are too limited to handle this part of our voluntary work hindered by workflows of other parties.

It is not possible for us to participate in vendor bug bounties, respect vulnerability disclosure limitations, or dragging review timelines. The timeline for the coordinated vulnerability disclosure is very tight when it comes to vulnerabilities that are public already. In such cases the CNA Operational Rule 4.2.1.2.3 expect an assignment and disclosure of a CVE to happen within 72 hours to inform users about risks. Attackers might already be using exploits and compromise environments based on shared attack details.

Thus, we always have to balance the needs of the different entities to support vendors to provide solutions as quickly as possible, to help affected users to mitigate risks, and to prevent attackers from exploiting available windows of opportunities.

All approaches to contact vendors are documented and stored in our Private Vulnerability Tracking System (PVTS), which makes it possible for us to log coordinated disclosures and vendor responses properly.

No Proper Responses

Unfortunately, in more than 90% of the cases we do never receive a response by a contacted vendor. Therefore, in most cases investing time and effort only delays the vulnerability disclosure which prevents potential victims to know about the risks and mitigate them as early as possible. This is not what we shall aim for.

If we have contacted a vendor multiple times over a long period of time and have never received a proper response, we assume that they are not interested in a coordinated vulnerability disclosure. In this case we might suspend further contact approaches to optimize our responsible vulnerability disclosures. If vendors are not willing to prepare countermeasures in time, we shall help potential victims to know the risks they are exposed to and let them evaluate alternative mitigation possibilities.

We might document this unfortunate situation in our disclosures to inform customers about vendors which might not take security of their products serious.

Uppdaterad: 18/10/2024 förbi VulDB Documentation Team