That's why I was asking. I honestly couldn't think of any. > A company can be aware of a security flaw and in a state of fixing it, just not as fast as the rep

That's why I was asking. I honestly couldn't think of any. > A company can be aware of a security flaw and in a state of fixing it, just not as fast as the reporting party wants, for a variety of both good and bad reasons. Hence the commonly accepted 30-90 day window, which acts as an impetus for companies to prioritize fixing vulnerabilities they'd not like made public. Previous to this, they'd fix them a couple of years later during the next rewrite. This is also why there's typically an extension available if the company has demonstrated in good faith that they're working on a fix. > A company can be aware of a security flaw and not understand or agree with the reporter's assessment of the seriousness. All the better reason to disclose it after an acceptable period and make the company's customers aware. Either they agree with the company's position, or they can vote with their better-informed dollars. > A company can be aware of the flaw and be planning or fixing it too slowly, and for whatever reason unwilling to communicate intermediate status, nonetheless taking action. This is the same as no-action. It's not hard to keep the security researchers who reported a bug to you in the loop, outside of general corporate incompetence. > A third party's role would be exactly the same that the public has in this situation, namely to scare the company into taking the issue seriously and fixing it quickly. The benefit of going to a third party that could help, instead of the public, would be preventing larger scale damage than is already occurring. This is exactly what responsible disclosure does. During the 30-90 day window, only the company, the researcher, and any black hats who are aware of the issue are informed. > A well respected third party could help the company with the security problem understand that the issue is serious and could even offer services to fix the problem, in case the company isn't competent in security matters. Just one imaginary scenario, the third party could be a government organization or enforcement agency that is tasked with internet safety issues, and has the ability to revoke the offending business's right to operate if they fail to comply. This sounds like an attempt to impose another corruptible organization in the middle of something the market is currently solving quite well. When your company shows up on the 8pm local news, customers notice. If it's not a big deal, then it doesn't. If the result hurts your bottom line or you couldn't produce a fix by the window, then hire more staff into your security / bug fix teams or un@$%! the technical debt in your codebase that made delivering impossible. At best, it looks like CERT, whose power is essentially limited to naming and shaming. At worst, it looks like something like the Better Business Bureau (aka pay to certify). Furthermore, looking at the track record of regulatory capture, I have less than zero faith that any organization would ever revoke an offending business's right to operate over a security matter until there's legislation passed mandating a better security posture / consequences for the private sector. > I know some companies have been incompetent and malicious, I know that some companies have tried to silence vulnerability reports, but is that reason to assume they all are? Even if we did speculate that it was most companies, is that a good reason to always escalate to the maximum first, before there's evidence of a cover-up attempt? Yes. Because without a strong default posture, companies don't take security issues seriously. The 30-90 default provides this encouragement and moreover places the onus on an offending company to justify why they need longer than this. Furthermore, I don't feel like this is the "maximum first." That would be immediately releasing any vulnerabilities discovered. The currently accepted methodology is the result of two decades of experience in solving this problem (look up the history on Bugtraq etc) and seems to be more effective than anything else that's been attempted.