4 ms·

Giving the vendor (60 days) to fix it is reasonable.

riskable 11y ago
The "reasonableness" behind the length of time before public disclosure of vulnerabilities is not based on how long the vendor will take to fix it. It is based on the likelihood that someone else will discover the vulnerability (if not already!) and exploit it. We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long. That "before long" part is really just an assumption based on the best-case scenario: No one else has discovered the vulnerability yet. Even if the vendor has no fix available disclosure is still of the utmost importance because it gives the public at large a fighting chance at remediating the problem; whether the vendor is ready or not! Example: If a critical vulnerability is discovered in Nginx and the developers can't put out a release any time soon I can always switch to Apache or some other web server. How "entrenched" or "locked in" you are with a product is neither here nor there. That's your own damned fault if you can't swap it out with something else. Especially if you knew you were locked in ahead of time and have yet to do anything about it.
- Animats 11y ago
  "We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long." Today, we have to operate under the assumption that if a good guy has discovered a vulnerability, a bad guy is probably already exploiting it.
sarciszewski 11y ago
In general, yes. Sometimes longer is reasonable, sometimes shorter is reasonable.
- sneak 11y ago
  This is all speculation and not based on any real data. Full, immediate, public disclosure is also reasonable.
  - fweespeech 11y ago
    The problem with full, immediate disclosure is its pretty easy to build an exploit for a known CVE. Switching Nginx out in your infrastructure (for instance) isn't a simple trick at scale when you have a heavily customized install. (e.g. OpenResty with routing code)

The "reasonableness" behind the length of time before public disclosure of vulnerabilities is not based on how long the vendor will take to fix it. It is based on the likelihood that someone else will discover the vulnerability (if not already!) and exploit it. We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long. That "before long" part is really just an assumption based on the best-case scenario: No one else has discovered the vulnerability yet. Even if the vendor has no fix available disclosure is still of the utmost importance because it gives the public at large a fighting chance at remediating the problem; whether the vendor is ready or not! Example: If a critical vulnerability is discovered in Nginx and the developers can't put out a release any time soon I can always switch to Apache or some other web server. How "entrenched" or "locked in" you are with a product is neither here nor there. That's your own damned fault if you can't swap it out with something else. Especially if you knew you were locked in ahead of time and have yet to do anything about it.

Animats 11y ago
"We must operate under the assumption that if "a good guy" has discovered a vulnerability in a product then "a bad guy" will also find it before long." Today, we have to operate under the assumption that if a good guy has discovered a vulnerability, a bad guy is probably already exploiting it.

sarciszewski 11y ago

In general, yes. Sometimes longer is reasonable, sometimes shorter is reasonable.

sneak 11y ago
This is all speculation and not based on any real data. Full, immediate, public disclosure is also reasonable.
- fweespeech 11y ago
  The problem with full, immediate disclosure is its pretty easy to build an exploit for a known CVE. Switching Nginx out in your infrastructure (for instance) isn't a simple trick at scale when you have a heavily customized install. (e.g. OpenResty with routing code)