2015-12-14 | me > dotCMS | 8 SQL injection vulnerabilities
2015-12-14 | dotCMS > me | they were planning fixes in upcoming
release, estimated to beginning of 2016
2016-03-16 | dotCMS | dotCMS version 3.3.1 release (CVE-2016-4040
still not fixed)
2016-04-07 | me > dotCMS | what is the situation with reported vulnerabilities?
2016-04-07 | dotCMS > me | CVE-2016-4040 will be fixed in 3.5, which
is estimated to be out in mid-April
2016-04-19 | dotCMS | dotCMS version 3.5 release
2016-05-10 | dotCMS | dotCMS version 3.3.2 release
2016-10-31 | me | Full Disclosure on http://security.elarlang.eu
This timeline from first report to full disclosure was 10.5 months. Note that I did not go looking for a long timeline, this was the first item when I Googled "CVE disclosure timeline."
Maybe 24h? If you can't respond and mitigate within that time frame you aren't operating on internet time.
> From policy quote in sibling post: "[...] currently known in-the-wild security bugs under active exploit."
Nonsense. Every bug you discover could have been discovered by an attacker, and attackers are constantly scanning. If the bug is in release software you have to assume it's known and being exploited.
btw, for the downvoters - I know I speak the truth because I've worked dev in an internet-security company, and in security in a major cloud company. We can turn patches (or mitigations) out in hours and have them canaried and live in 24h. This is absolutely doable and should be expected. This months nonsense is when the company doesn't want to fix the bug.
What it takes is the institutional will to disable a feature you bill for until you secure it. When a $millions/day loss is on the table you find that obstacles evaporate. If a company tries to keep their vulnerabilities under wraps there wouldn't be this cost, and thus no will to fix it, in an ever-worsening spiral.