Skip to content

Introduction

Imagine you've found a vulnerability in a product. What do you do with this knowledge?

Maybe nothing. There are many situations in which it's perfectly reasonable to decide to go on about your business and let somebody else deal with it.

The First Decision in Coordinated Vulnerability Disclosure

The first decision in Coordinated Vulnerability Disclosure is whether to start the process at all.

stateDiagram-v2
direction TB
found: I know about<br/>a vulnerability
state decide <<choice>>
[*] --> found
found --> decide: What to do?
coordinate: CVD
decide --> [*] : Do nothing
decide --> coordinate: Coordinate
  • You're busy.
  • You have more important things to do.
  • It's not your code, so it's not your problem.
  • Or maybe it is your code, but you wrote it a long time ago, and it will take a lot of effort to even try to fix it.
  • Maybe the product has already reached end-of-life.
  • Or perhaps fixing this bug will delay the launch of your new product that will supersede this version anyway.

There are plenty of good reasons that it might not be worth the hassle of fixing it or reporting it. Although this is what a mathematician would refer to as a degenerate case of the disclosure process in which no disclosure occurs, it's important to recognize that even starting the process of disclosure is a choice one must consider carefully.

Often, though, you will likely feel a need to take some action in response to this newfound knowledge of a vulnerability. If it's your product, you might immediately set off to understand the root cause of the problem and fix it. Once fixed, you probably will want to draw attention to the fix so your product's users can protect themselves. Or perhaps the product is other people's responsibility to fix, and you want to inform them of the existence of this vulnerability.

This is where the process of Coordinated Vulnerability Disclosure (CVD) begins.

Where to go from here

The remainder of this section provides some tutorials and guidance on how to get started with Coordinated Vulnerability Disclosure.

  • The CERT Guide to CVD in a Nutshell

    The CERT Guide to CVD in a Nutshell provides an overview of many of the topics covered later in this documentation, with links to more detailed information. We're providing it here as a preview of what's to come as you work through the remainder of the site.

  • Coordinated Vulnerability Disclosure is a Process, Not an Event

    Vendors typically remediate vulnerabilities by developing and releasing an update to the product, also known as a patch. However, often the vendor issuing an update is a step in the middle of a process that starts with discovery and moves towards remediation of the installed base of vulnerable systems.

  • CVD Terminology

    We need to agree on what we're talking about when we talk about CVD. In this section, we define the terms that are used throughout the remainder of this site.

  • Vulnerability Response Processes

    Although the coordination process can be complex at times, we can describe the general process in a few steps. The rest of this guide goes into more detail on each of these steps and what else might happen along the way.

  • Coordinating with the CERT/CC

    Coordinating with the CERT/CC isn't much different from coordinating directly with a vendor, but there are a few extra steps. This page will walk you through the process of coordinating with the CERT/CC, and what to expect when working with us.