Skip to content

The CERT Guide to CVD in a Nutshell

Software-based products and services have vulnerabilities—conditions or behaviors that allow the violation of an explicit or implicit security policy. This should come as no surprise to those familiar with software. What many find surprising nowadays is just how many products and services should be considered software based. The devices we depend on to communicate and coordinate our lives, transport us from place to place, and keep us healthy have in recent years become more and more connected both to each other and to the world at large. As a result, society has developed an increasing dependence on software-based products and services along with a commensurate need to address the vulnerabilities that inevitably accompany them.

Adversaries take advantage of vulnerabilities to achieve goals at odds with the developers, deployers, users, and other stakeholders of the systems we depend on. Notifying the public that a problem exists without offering a specific course of action to remediate it can result in giving an adversary the advantage while the remediation gap persists. Yet there is no optimal formula for minimizing the potential for harm to be done short of avoiding the introduction of vulnerabilities in the first place. In short, vulnerability disclosure appears to be a wicked problem.

Coordinated Vulnerability Disclosure (CVD) is a process for reducing adversary advantage while an information security vulnerability is being mitigated. CVD is a process, not an event. Releasing a patch or publishing a document are important events within the process, but do not define it.

The Core Questions of Coordinated Vulnerability Disclosure

CVD participants can be thought of as repeatedly asking these questions:

  1. What actions should I take in response to this knowledge?
  2. Who else needs to know what, and when?

The CVD process continues until the answers to these questions are nothing, and nobody.

CVD should not be confused with Vulnerability Management (VM). VM encompasses the process downstream of CVD, once the vulnerability has been disclosed and deployers must take action to respond.

What's on this Page?

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.

Understanding CVD

While we provide more practical guidance in the How To section, this section provides a more abstract understanding of Coordinated Vulnerability Disclosure (CVD). This section is intended for those who want to understand the principles, roles, and phases of CVD.

---
title: CVD Overview
---
flowchart LR
Principles -->|guide| Roles
Roles -->|perform| Phases
Principles -->|support| Phases

Principles of Coordinated Vulnerability Disclosure

Over the years, the CERT/CC has identified a number of principles that guide our efforts in coordinating vulnerability disclosures and which seem to be present in many successful CVD programs. These principles include the following:

  • Reduce Harm

    At its core, harm reduction with respect to vulnerable software is about balancing the ability for system defenders to take action while avoiding an increase in attacker advantage.

  • Presume Benevolence

    In terms of the CVD process, we have found that it is usually best to assume that any individual who has taken the time and effort to reach out to a vendor or a coordinator to report an issue is likely benevolent and sincerely wishes to reduce the risk posed by the vulnerability.

  • Avoid Surprise

    As with most situations in which multiple parties are engaged in a potentially stressful and contentious negotiation, surprise tends to increase the risk of a negative outcome.

  • Incentivize Desired Behavior

    Not everyone shares the same values, concerns, perspectives, or even ethical foundations, so it's not reasonable to expect everyone to play by your rules. Keeping that in mind, we've found that it's usually better to reward good behavior than try to punish bad behavior.

  • Ethical Considerations

    Various computing-related professional societies have established their own codes of ethics. Each of these has some application to CVD.

  • Process Improvement

    In reviewing their experience in the CVD process, participants should capture ideas that worked well and note failures. This feedback can be used to improve both the Software Development Lifecycle and the CVD process itself.

  • CVD is a Wicked Problem

    The term wicked problem is used to describe a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize.

Roles in Coordinated Vulnerability Disclosure

Certain roles are critical to the Coordinated Vulnerability Disclosure process, as described in the following sections:

  • Finder (Discoverer) -- the individual or organization that identifies the vulnerability
  • Reporter -- the individual or organization that notifies the vendor of the vulnerability
  • Vendor -- the individual or organization that created or maintains the product that is vulnerable
  • Deployer -- the individual or organization that must deploy a patch or take other remediation action
  • Coordinator -- an individual or organization that facilitates the coordinated response process
  • Other Roles -- other roles that may be involved in the CVD process

Participants Can Play Multiple Roles

It is possible and often the case that individuals and organizations play multiple roles. For example, a cloud service provider might act as both vendor and deployer, while a researcher might act as both finder and reporter. A vendor may also be both a deployer and a coordinator. In fact, the CERT/CC has played all five roles over time, although not usually simultaneously.

Relationships Between Roles

Although a more detailed description of the CVD process is provided in Phases of CVD, a simple sketch of the relationships between these roles is shown in the figure below.

---
title: Coordination Relationships in CVD
---
flowchart TB
    subgraph C[Coordination]
        direction LR
        subgraph A[Often<br/>Same<br/>Entity]
            reporter([Reporter])
            finder([Finder])
        end
        vendor([Vendor])
        subgraph D[Sometimes<br/>Included]
            coordinator([Coordinator])
            deployer([Deployer])
        end
    end
    public([Public])

    finder <--> reporter
    reporter <--> vendor
    vendor <-.-> coordinator
    reporter <-.-> coordinator
    vendor <-.-> deployer
    coordinator <-.-> deployer
    reporter <-.-> deployer
    C -->|publish| public

Phases of Coordinated Vulnerability Disclosure

Below, we adapt a version of the ISO/IEC 30111:2019 Information technology—Security techniques—Vulnerability handling processes with more phases to better describe what we have seen at the CERT/CC

  • Discovery

    A researcher (not necessarily an academic one) discovers a vulnerability by using one of numerous tools and processes.

  • Reporting

    A researcher submits a vulnerability report to a software or product vendor, or a third-party coordinator if necessary.

  • Validation and Prioritization

    The analyst validates the report to ensure accuracy before action can be taken and prioritizes reports relative to others.

  • Remediation

    A remediation plan (ideally a software patch, but could also be other mechanisms) is developed and tested.

  • Public Awareness

    The vulnerability and its remediation plan is disclosed to the public.

  • Deployment

    The remediation is applied to deployed systems.

Vulnerability Handling Process Models

There have been a number of proposed models of the CVD process that have slightly varying phases. Some of the most notable include:

Who Does What?

Extending the diagram from the Roles in CVD page, we can see how the roles interact in the CVD process.

---
title: CVD Role Relationships
---
flowchart TB
    subgraph C[Coordination]
        direction LR
    subgraph A[Often Same Entity]
        Reporter([Reporter])
        Finder([Finder])
    end
    Vendor([Vendor])
    subgraph B[Sometimes Included]
        Coordinator([Coordinator])
        Deployer([Deployer])
    end

    end

    Finder -->|shares vul<br/>info with| Reporter
    Reporter -->|reports<br/>vul to| Vendor
    Reporter -.->|provides vul<br/>info to| Deployer
    Reporter -.->|reports<br/>vul to| Coordinator

    Vendor -->|coordinates<br/>with| Reporter
    Vendor -.->|coordinates<br/>with| Coordinator
    Vendor -->|provides vul info<br/>and/or patch to| Deployer

    Coordinator -.->|coordinates<br/>with| Vendor
    Coordinator -.->|coordinates<br/>with| Reporter
    Coordinator -.->|provides vul<br/>info to| Deployer

    Deployer -->|provides</br>feedback to| Vendor

    C -->|publish| Public([Public])

A mapping of CVD phases to CVD roles is provided in the following table.

Role →
Phases ↓		 Finder Reporter Vendor Coordinator Deployer
Discovery Finds Vulnerabilities - - - -
Reporting Prepares report Reports vuls to vendor(s) and/or coordinator(s) Receives reports Receives reports -
Validation - - Validates reports received Validates reports received -
Prioritization - - Prioritizes reports for response Prioritizes reports for response Prioritizes fixes for deployment
Remediation - Confirms fix Prepares patches, develops advice, workarounds Coordinates multiparty response, develops advice, workarounds -
Public Awareness Publishes advisory Publishes advisory Publishes advisory Publishes advisory Receives advisory
Deployment - - - - Deploys fix or mitigation

How to Coordinate Vulnerability Disclosures

This section provides guidance for folks who are actively engaged in Coordinated Vulnerability Disclosure (CVD) and are looking for advice on how to handle specific situations. We have organized it roughly in the order that you might encounter these problems, although we're not strictly adhering to the Phases we've outlined in the Understanding CVD section.

How to Use This Section

Each page is intended to be a standalone resource, allowing you to directly access the advice you need. This means that some of the advice may be repeated across pages, but we try to cross-reference where possible.

The navigation on the left side of the page is organized by topic, consistent with the structure of this page. Where necessary, navigation within each page is also provided in the right-hand column. You can use the navigation buttons at the bottom of the page to move through the advice in sequence.

CVD Recipe Cards

Like a recipe card, each item includes an ingredients list that describes

  • the roles affected
  • the phases in which the problem is likely to arise
  • the problem itself

In this edition of the Guide, we have organized our problem solving advice into a set of recipe cards.

The recipe portion of each card provides a set of instructions for resolving the problem. These aren't necessarily step-by-step instructions, but rather a set of guidelines to help you navigate the problem.

Preparation for Coordinating Vulnerability Disclosure

Whether you're a security researcher, a vendor, or a coordinator, there are a few things you can do to prepare for a CVD process. This section provides some general advice on how to get ready for a CVD process, and how to make sure you're in a good position to handle any issues that might arise.

  • Disclosure Choices

    There are several options for how to disclose a vulnerability. Each of these disclosure options have advantages and disadvantages.

  • Why Coordinate?

    The public and especially users of vulnerable products deserve to be informed about issues with those products and how the vendor handles those issues. At the same time, disclosing such information without review and mitigation only opens the public up to exploitation. The ideal scenario occurs when everyone coordinates and cooperates to protect the public.

  • Avoid Unnecessary Risk

    Looking for vulnerabilities in software and hardware is a critical part of the security ecosystem. However, it is important to do so in a way that minimizes the potential for harm to others.

  • Choosing a Disclosure Policy

    A well-defined policy makes it clear what other participants in the CVD process can expect when they engage with you and establishes good relationships between finders, reporters, vendors, coordinators, and other stakeholders." end="

  • Communication Topology

    The complexity of coordination problems increases rapidly as more parties are involved in the coordination effort. As a result, multiparty coordination using point-to-point communications do not scale well.

Initiating a Coordinated Vulnerability Disclosure Case

Sometimes, the hardest part of CVD is getting started. You might know about a vulnerability, but not know how to reach the vendor. Or you might be having trouble getting the vendor to respond. This section provides some advice on how to get the ball rolling.

  • Providing Useful Reports

    Reporting a vulnerability requires that the vulnerability is well-documented. This typically means providing high-quality and actionable information to the vendor or coordinator.

  • Finding Vendor Contacts

    Making initial contact with a vendor can sometimes be more difficult than it should be.

  • Unresponsive Vendor

    Sometimes, even when you can find contact informaiont for the vendor, not all vendors have established processes for receiving vulnerability reports.

  • Reduce Reporting Friction

    As a vendor, it is important to not treat reporters with suspicion or hostility. It's likely they have important information about your product, and they want to share it with you.

Coordinating Vulnerability Disclosure

Participating in a CVD process can be challenging. This section provides some advice on how to handle common issues that might arise during the coordination process.

  • Reasons to Engage a Coordinator

    Reporter experience, capacity, and the number or nature of vendors involved can all play a role in determining whether a coordinator is needed. In addition, disputes between reporters and vendors, or the potential for major infrastructure impacts, can also necessitate the involvement of a coordinator.

  • Validation

    Not all reports are actionable. Some reports may under-specify the problem, making it difficult or impossible to reproduce. Some may contain irrelevant details. Some will be well written and concise, but many will not. Some reports could describe problems that are already known or for which a fix is already in the pipeline.

  • Prioritization

    Even for the reports a vendor accepts as valid (in scope, credible, and valid), it is likely that the development team does not have time to address every report at the moment it arrives. Thus, if a report is found to be valid, the next question is how to allocate resources to the report.

  • Multiparty CVD

    Many products today are not developed by a single organization. Instead, they are assembled from components sourced from other organizations. Vulnerabilities in these components can have far-reaching impacts and require coordination among multiple parties to resolve.

  • Response Pacing and Synchronization

    Problems can arise when the multiple parties involved in CVD function at different operational tempos. Different organizations have different priorities and development schedules, which can lead to some parties wanting to move faster than others.

  • Somebody Stops Replying

    Sometimes one of the parties involved in a CVD effort will stop responding. Often, this is simply a reflection of priorities and attention shifting elsewhere rather than intentional behavior. It's usually best to give the benefit of the doubt and keep trying to reestablish contact if one of the CVD participants goes unresponsive.

Embargoes in Coordinated Vulnerability Disclosure

Embargoes are a common tool in the CVD process, but they can be tricky to manage. This section provides some advice on how to handle embargoes effectively, even when things don't go as planned.

  • Maintaining Pre-Disclosure Secrecy

    The more parties involved in a case, and the longer the embargo period lasts, the more likely a leak becomes.

  • Disclosure Timing

    Complicated vulnerabilities usually take longer to fix. Larger cases involving more parties, more products, or more complex supply chains also tend to take longer to resolve, even if the vulnerabilities themselves are relatively simple.

  • Independent Discovery

    If one person can find a vulnerability, somebody else can, too. When multiple parties independently discover the same vulnerability, it can complicate the CVD process.

  • Intentional or Accidental Leaks

    You might find information you thought was shared in confidence showing up in some non-confidential location. It might be a simple misunderstanding, mismatched expectations, or in rare cases, a malicious act.

  • Active Exploitation

    If evidence comes to light that a vulnerability is being exploited in the wild, that is usually a strong indication to accelerate the disclosure timeline.

Complications in Coordinated Vulnerability Disclosure

Other complications can arise during the CVD process. This section provides some advice on how to handle these issues effectively. A summary of the advice in this section, along with a number of other scenarios can be found in Troubleshooting CVD.

  • Relationships that Go Sideways

    When relationships go sideways in a CVD process, it can be a real problem. The process can stall, or worse, the vulnerability can be disclosed in a way that is harmful to users.

  • Hype, Marketing, and Unwanted Attention

    Is a branded vulnerability more dangerous than one without? Not in any technical sense, no. Instead, what it does is draw additional attention—which can lead to vendors being forced to adjust the priority of the vulnerability cases they're working on and allocate resources toward addressing whatever vulnerability is getting the hype.

  • Troubleshooting Coordinated Vulnerability Disclosure

    We have compiled a list of common problems that can arise during the Coordinated Vulnerability Disclosure (CVD) process. Each problem identified is accompanied by a description intended to help the reader diagnose the problem.

  • What To Do When Things Go Wrong

    While we can't tell you what to do in every possible combination of contingencies that may arise in the CVD process, we can suggest a few guidelines to help you navigate the complexity.

Ongoing Coordination Operations

Participating in a CVD process over time requires a set of tools and practices in order to be successful. In this section, we outline a few tools of the trade, and consider common operational security and personnel management issues.

Process Improvement is Key Principle of CVD

See also Process Improvement for more about how to improve your CVD process over time.

CVD Reference Information

We have assembled a few resources to help you dig deeper into Coordinated Vulnerability Disclosure (CVD) and related topics. These resources include templates, standards, and other materials that can help you understand and implement CVD in your organization.