[g_p]

My answer is probably a bit cynical, but I believe it's accurate. The average when it comes to security and patching is pretty low, so on average, a hosting company probably doesn't find out about it, or patch it.

The majority of companies I've seen operations at didn't have people trawling the web looking for these kinds of issues. In theory you can sign up to get CVE notifications, and hopefully the software vendor will put a message on a mailing list. Whether anyone subscribed to that list is another question, and whether anyone reacts to it is another matter.

The challenge for most orgs I've seen would be even determining what tools (and versions) they need to keep on top of updates for. In a case like Salt however, I imagine short of being on their list (if they have one), most people's best hope is that one of their team sits on hacker news all day, and monitors relevant security resources, and knows salt is used.

Even big CAs don't get it right - the Salt attack was used against one of the certificate transparency servers. Clearly there's a gap between the theory and practice here.

[tatersolid]

Clearly we need some form of industry-standard notification mechanism, akin to security.txt for notifications.

Perhaps a well-formatted RSS feed at example.com/.well-known/security.rss ?

Email just doesn’t work in 2020 for anything mission-critical.

[g_p]

Yes, that would probably work. This would then need to tie in with versioning support on the client side, so that people can "listen" for particular versions of dependencies.

As a user it would also need to support team or shared accounts, so that a whole team can get alerted to any issues in components of their stack.

Then need to get everyone to support yet another standard(!), and companies need to hunt through their existing stack and identify all the critical components - I imagine lots of people will forget their dependency on things like OpenSSL/OpenSSH and ensuring they track bulletins for their relevant version.