From the point of view of public disclosure, the original topic, I think this is so situational that to cover it with a blanket "security industry" approach is just wrong.
Take for instance a small shareware utility, perhaps with a small error. Now this might sound unusual but I have actually seen a small shareware utility with a published security breach in the past. What are the odds of that shareware author keeping tabs on the security industry? Well, my guess would be well under 1%... Most indi coders are interested in their own development, not in hacking other peoples.
You just cannot compare indi software, or cover it with the same point of view or policy statement, to corporates like Microsoft who can employ people to watch the security industry and to specialise in securing their products.
It could be argued that it is the responsibility for software vendors to launch secure products, and that that responsibility is equally important for indi's as well as corporates.
That just isn't the case though. To ensure that every step you take whilst developing your software is utterly secure adds extra layers of work that slow up development, it's far easier to secure a product after completion than during development - although some particular aspects are easiest done as you go along.
Hypothetically speaking, if LFS had a glitch that could enable people to run an intake restriction of 0% yet report it as 5% to others - sure we'd all like to stop people from doing that, but if the exploit sat unnoticed for eight months is it better to release the intake feature and fix it later if it happens to get exploited, or release it two weeks later after vigorously testing every feature and scenario one can think that might brake it.
It is hard enough releasing bug free software, without having to worry about security, and outside of the corporates most software hacks come entirely from the "security industry" and not from 'the wild'.