[dx87]

I think this goes hand-in-hand with people naming security vulnerabilities and trying to make it a big spectacle. Sometimes it is a legit serious vulnerability, like shellshock or heartbleed, but a lot are just novices trying to get their 15 minutes of fame. I remember a few years back there was a "vulnerability" named GRINCH, where the person who discovered it claimed it was a root priviledge escalation that worked on all versions of Red Hat and CentOS. They made a website and everything for it, and tried to hype it up before disclosing what it was. Turns out the "vulnerability" was members of the wheel group being able to use sudo to run commands as root.

[tptacek]

It's hard for me to think of a serious downside for named vulnerabilities. People who try to name sev:lo bugs get made fun of; it backfires.

[dx87]

It just causes extra annoyance at work. There have been a few times when some named vulnerability gets covered by a generic tech website, and the next day at work my inbox has 2-3 meeting invites from non-technical project managers to discuss what needs to be done to mitigate the vulnerability, regardless of its severity, and without even knowing if our organization is vulnerable to it.

[akerl_]

It seems like there may be value in writing up a template for vulnerability comms:

“Hi folks, a new vulnerability has been disclosed (CVE-####-####). We’ve assessed this vulnerability, and it doesn’t affect our infrastructure because [we don’t use the affected software|we don’t use the vulnerable configuration|the vulnerability is mitigated by other security controls].”

If the worst impact of naming vulnerabilities is that security-related technical staff have to politely decline a couple meeting invites, I’m going to consider the practice an overall win.

[tptacek]

It is, but also worth keeping in mind that vulnerability triage is just an annoying, resource-intensive process. Putting aside the "named vulnerability" thing, the most common prompt for a triage process is "new vulnerability discovered in a dependency"; that will happen several times a week in most significant products. Almost all of those vulnerabilities are marginal, and even the ones that aren't are usually not exposed in a typical use of the dependency. It's just an annoying problem.

[akerl_]

No disagreement on it being a chore. The template doesn’t cut down on the actual work of triaging these, it just (hopefully, in a healthy org) helps avoid the “3 meetings per CVE with non-technical managers” part, which does seem avoidable.

[TecoAndJix]

This is a large part of my job. If something pops in the news that mentions our tech/industry/posture (or I suspect it will get c-suite attention) I immediately do a write up just like that. Depending on the severity (or even media “buzz”) I will include screenshots of my investigation and CC the relevant architects/managers. Still, that sometimes leads to managers wanting a meeting to discuss the email further but it GREATLY reduces panic emails when something crosses their newsfeed. On this topic - I also run our vulnerability management program and have to stress that CVSS score is not the lone factor on how much we care. I get lots of emails from people in the company saying “hey, did you see this”? for some random no impact vulnerability but am MORE than happy to thank them for the vigilance and explain why it’s not an impact because I want them to care.