Your take is the dangerous one. I don’t disagree that
> the vast majority of security vulnerabilities in software are not actively exploited
However I’d say your explanation that it’s
> because no one knows about them
is not necessarily the reason why.
If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)
> (I agree some lead time / attempt at coordinated disclosure is preferable here.)
Then I think we are in agreement overall. I took your initial comment to mean that as soon as you discover a vulnerability, you should make it public. If we agree that the process should always be to disclose it to the project, wait some amount of time, and only then make it public - then I think we are actually on the exact same page.
Now, for the specific amount of time: ideally, you'd wait until the project has a patch available, if they are collaborating and prioritizing things appropriately. However, if they are dragging their feet and/or not even acknowledging that a fix is needed, then I also agree that you should set a fixed time as a last ditch attempt to get them to fix it (say, "2 weeks from today"), and then make it public as a 0-day.
Indeed, we’re in agreement. Though I’d suggest a fixed disclosure timeframe at time of reporting. Maybe with an option to extend in cases where the fix is more complex than anticipated.
> the vast majority of security vulnerabilities in software are not actively exploited
However I’d say your explanation that it’s
> because no one knows about them
is not necessarily the reason why.
If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)