Skip to content

Disclosure Timing

How long is "long enough" to respond to a vulnerability? As with so many questions that arise in the CVD process, there is no single right answer.

How long is long enough?

Is 45 days long enough? Is 90 days too short? Is 217 days unreasonable? Three years? The only answer we can give is "It depends."

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.

So rather than trying to solve an underspecified problem, let's have a look at some of the factors that tend to play into timing choices. This will give us an opportunity to see where some of the variability comes from.

Conference Schedules Often Drive Disclosure Timing

Conference schedules often drive researcher timelines. There is a rhythmic cycle to the vulnerability disclosure calendar. Black Hat and DEF CON happen in early August every year. Usenix Security is usually right after that. The RSA Conference is in the late winter or early spring. CanSecWest is in the spring. Smaller conferences are scattered in between. 

timeline
    Spring: RSA : CanSecWest : Black Hat Asia
    Summer: Black Hat USA : DEFCON : USENIX
    Autumn: Black Hat Middle East/Africa
    Winter: Black Hat Europe

Many of these conferences rely on presenters describing novel attack methods in varying degrees of detail. However, in order for researchers to analyze, develop, and demonstrate those techniques, vulnerabilities are often uncovered in extant products. That means that coordinating the disclosure of the vulnerabilities they've found is a common part of the conference preparation process for presenters. The CERT/CC often observes an increased rate of vulnerability reports a few months in advance of these conferences. Vendors would do well to be aware of these schedules and be prepared to respond quickly and appropriately to seemingly inflexible deadlines for disclosure.

Vendor Reputation and Willingness to Cooperate

Vendors that are perceived to treat vulnerability reporters poorly or that are perceived to be slow or unresponsive may find themselves being left to discover reports of vulnerabilities in their products at the same time as the public becomes aware of them. CVD is a social process, remember? And the game is played over and over, by players who share knowledge between rounds.

Declarative Disclosure Policies Reduce Uncertainty

Avoiding surprise is one of the principles of CVD. To that end, explicitly declared policies (from both researchers and vendors) are a good thing. Expected disclosure timing is an important question to ask whenever a report is received. Sometimes the reporter or coordinator acting on the reporter's behalf has a standing policy of X days with no exceptions. Other reporters may be more flexible. If in doubt, ask.

Diverting from the Plan

Plans are one thing, but reality sometimes disagrees with our assessment of it. Breaking a previous disclosure timeline agreement is sometimes necessary when events warrant. Below we cover a few reasons to release earlier or later than planned.

Reasons to release early

  • Evidence of active exploitation
  • Vendor fails to respond, is not acting in good faith, or denies the existence of a vulnerability
  • Vulnerability is known to be discovered by adversaries, so the race to defend vulnerable systems is more focused
  • All known users have been notified and patched (usually via private channels)

Reasons to hold back release

  • Vendor not ready with fix, but continuing to make progress and is acting in good faith
  • Vulnerabilities with severe impact, especially those affecting safety-critical or critical infrastructure
  • Cases where new information is found late in the process, for example that there are important but previously unrecognized dependencies that alter the impact of the vulnerability or patch deployability

In cases that divert from the planned disclosure date, it sometimes helps to seek the opinion of a neutral third party for advice on how to proceed. Finders, reporters, and vendors can each have valid yet conflicting perspectives on what the best course of action might be. Coordinator organizations are often able to help resolve conflicts by taking a neutral approach to the situation and advising one or more parties in light of their prior experience.

All Disclosure Agreements Are Contingent

When vendors, reporters, and/or coordinators negotiate and agree to a release timeline for a vulnerability, they may behave as if they've reached some state of détente with the world. But that's an illusion. True, they may have reached an agreement with each other, but it ignores another relevant role in the disclosure process: the adversary.

Adversaries do not care whether the vendor plans to release the patch in a month, whether they need more time to test it prior to release, whether the reporter wants to break the news at a conference event, whether the reporter hopes to get paid for the work, or any other reason that reporters and vendors may have for agreeing to the terms they came to.

Furthermore, because the vulnerability's existence is an observable fact in the world, anyone else who happens to notice it might also choose to disclose that knowledge on their own terms without being party to any existing embargo agreements.

Therefore it's important for vendors, reporters, and coordinators alike to recognize that all disclosure embargo agreements are necessarily contingent on circumstances beyond the control of the parties involved; and that those circumstances are not simply random events but may be controlled by actors who are indifferent to their concerns.

Releasing Partial Information Can Help Adversaries

When considering what information to release about a vulnerability, our advice is "Don't tease." Our experience shows that the mere knowledge of a vulnerability's existence in a feature of some product is sufficient for a skillful person to discover it for themselves. Rumor of a vulnerability draws attention from knowledgeable people with vulnerability finding skills—and there's no guarantee that all those people will have users' best interests in mind. Thus, teasing the existence of a vulnerability in a product can sometimes provide an adversarial advantage that increases risk to end users.