[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).