[john_strinlai]

>Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...]

a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now.

(edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inform your decision making)

[mk89]

Oh no, you're in for a surprise.

"Especially now" all these infosec folks "need to get CVEs fixed because compliance/SOC2, etc" and they will be even more up your a*!

Something has to change with how compliance works. It is so outdated and crazy.

[tptacek]

Compliance != security. It's almost the natural enemy of security.

[mk89]

This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...

[tptacek]

Which compliance regime are you referring to that cares about CVE counts as a metric?

[mk89]

Not as a metric, but it basically becomes one, like with Fedramp.

You need to fix also moderate/low CVEs within a certain time frame.

So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.

It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".

[tptacek]

I don't do FedRAMP and will have to take your word for that, but none of SOC2, 27001, or HIPAA/HITRUST care about CVE counts.

[1718627440]

But that's not a wrong approach. First you want to as many vulnerabilities as you can, than you want to fix as many as you can. If you rate the developing department for that, that's another story.

[john_strinlai]

>all these infosec folks

i am an infosec folk (:

[mk89]

Well you're a bit different then...

In my experience it is becoming basically ridiculous that we disallow compliance based on a number of cve, their level, etc. It's just a checkbox, but it has nothing to do with security.

[mk89]

Not sure about the downvote.

I'd like to know how a "critical CVE running in your software for 29 days" is acceptable from a security standpoint. With nowadays tooling, these AI agents can take you down in no time if they target you.

Compliance the way is done today is basically outdated, but everyone has to follow these rules to sell software basically.

[tialaramex]

So lets take some recent examples from the sprawling systems my team looks after

1. There's a "critical" severity security issue because we have an obsolete version of some Perl library on a machine that's exposed to outsiders (ie has a public HTTPS website)

1a. The perl library isn't used by any of the software running on that machine, it's presumably either left over from software we no longer use or it was installed to run somebody's one-shot Perl script, possibly years ago, maybe even for a prior incarnation of that system, with the present one installing that library because it's just easier than figuring out which libraries are still needed...

1b Severity CRITICAL. Actual threat: ZERO

2. .NET 8 is obsolete, machines with the .NET 8 CLR are flagged as insecure.

2a. .NET 10 isn't obsolete, that's still supported, in many cases the exact same code, re-compiled with a 10.x version not 8.x was shipped by Microsoft. Is that true for all the cases we care about? Nobody knows, nobody is even interested in working out. Flagged instances will be turned off if they're not fixed so "just" fix it. Busy work.

2b. Severity HIGH. Actual threat: Unknown, possibly negligible?

As with Mythos these "AI agents" which can "take you down in no time" can't do the impossible, this isn't a Hollywood movie, mumbling about AI and critical severity CVE doesn't turn that Perl library nobody was using into an actual threat.

[mk89]

If the code is unreachable is obviously not a threat, Mythos or not. Can you do this analysis for all your 200+ services, libs etc?

This is the main issue about compliance nowadays. In a fedramp scenario you would very likely have to prove that it's unreachable, and you might even risk compliance over it.

From an attacker perspective they don't know the lib version you're using, but bruteforcing / finding patterns faster than a hacker can? That's what I believe AI can do. This is why for me CVEs are a useless metric, the number and/or criticality. It's a simple security control but they are giving it so much importance. Then you "forget" to secure access to your mcp server and this leaks company info, but hey, zero CVEs, soc2 compliance check check check.

I think it's a good practice to fix as many CVEs as possible, to have a clean/updated codebase, but I am of the opinion that if someone wants, with the tools they have nowadays, they will find a way in. Of course, using a lib that has obvious security issues for input validation, for example, should be a no-go. However, we're reaching a point of ridicule (like you said above, a critical CVE but unreachable).

[jamesfinlayson]

Yep, at work my team's vulnerability dashboard constantly shows hundreds of critical and high vulnerabilities. Fortunately/unfortunately, 99% of these issues are for Javascript dependencies in websites that are not server-side rendered... so we look bad, even though we have no exposure to most of these vulnerabilities.

[jiggawatts]

Just yesterday I made myself a NuGet package analyzer tool -- okay fine, I vibe coded it -- that has convenient buttons for filtering out client-side packages, test projects, and dev-time tooling like Aspire.NET.

[jamesfinlayson]

Unfortunately GitLab has no such useful features.

[physicsguy]

It's alright, just get ISO27001 and list them as risks!