What would be the biggest downside if we just stopped considering severity low or medium security bugs CVE worthy?

[bagder@mastodon.social]

@jacques we don't use CVSS, never did...

[frummidge@meow.social]

@bagder normalization of deviance, mostly, but it's probably nothing that the industry hasn't encouraged before

[jacques@mastodon.chester.id.au]

@bagder well now I just feel silly for assuming!

[bagder@mastodon.social]

@jacques some background: https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/

[richardoc@infosec.exchange]

@bagder I'd prefer to know what issues exist, even if it's a bit noisier (on the blue team side)
Trying not to normalise the deviance of not fixing issues at my workplace

[kpcyrd@chaos.social]

@bagder We would need to refer to bugs as "the buffer overflow that's in src/foo/bar.c line 1067 in version 4.5.6, and line 1058 in version 4.5.7" again.

Arch Linux wouldn't care, but it would make the life of Debian maintainers more difficult.

[bagder@mastodon.social]

@kpcyrd countless projects basically do this already, I don't think the world would fall over. It would be fewer CVEs to care about.

[rrdot@infosec.exchange]

@kpcyrd @bagder this. If it doesn't matter that we have a common identifier to discuss security relevant bugs, then drop it. Otherwise keep em coming.

[rrdot@infosec.exchange]

@kpcyrd @bagder another note is even if a security relevant bug has low or medium significance to the security model of curl, it might still have significance to the security model of systems that use curl. Obviously it's user be ware, but it's harder to make those decisions when you can't easily distinguish between security bugs and other bugs.

[jeroen@secluded.ch]

@bagder Keep an ID, any ID.

I see them as globally unique identifiers that are used in "did you fix this thing" context. As naming things is hard and we will run out of catchy names and logos...

The severity indicates "fix now" or "fix tomorrow" or "next release". Thus the combo Id, severity, mitigatio & fix is important.

Curl could use CURL-SEC-2026-05-ABC and it would be fine too.

I just deployed a modprobe.d line for rds_tcp but no ID yet

/cc @adulau (for soliciting his opinions )
J

[kpcyrd@chaos.social]

@bagder Anybody can request a CVE, not just upstream. It's less about project policy, if a real, medium-severity vulnerability doesn't have a CVE assigned, that basically just means nobody was bothered enough to request one.

[airtower@woem.men]

@bagder@mastodon.social I've seen security bugs considered lower severity because they affect only uncommon use cases, even if they're serious in those cases. Not assigning CVEs would make those harder to find.

Though, to my great annoyance, I recently found CVEs considered low priority (severity or otherwise) often aren't properly annotated in NVD anyway, which makes them rather useless for automated checks. But that's a problem of the database.

[securitym0nkey@infosec.exchange]

@bagder counter question what would be the downsides if we don't? Many organizations already have a hard time dealing with the vulnerability reports. They are drowning already in insignificant CVEs. And the situation isn't getting better. As a result important vulnerabilities aren't addressed as quickly as they could.

But on the other hand it's already questionable what's considered low, medium and high. Official scoring often does not match what an organization would do for themselves.

Whatever you do, for some people it will be negative. You have to balance the equation to be net positive. A really hard one to solve. Maybe even impossible to solve.