5 ms·

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 y

by mk89 3mo ago

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.

john_strinlai 3mo ago
>all these infosec folks i am an infosec folk (:
- mk89 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago
        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 3mo ago
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 3mo ago
  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 3mo ago
    Unfortunately GitLab has no such useful features.
tptacek 3mo ago
Compliance != security. It's almost the natural enemy of security.
- mk89 3mo ago
  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 3mo ago
    Which compliance regime are you referring to that cares about CVE counts as a metric?
    - mk89 3mo ago
      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 3mo ago
        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.
        kasey_junk 3mo ago
        PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.

by mk89 3mo ago

john_strinlai 3mo ago

>all these infosec folks i am an infosec folk (:

mk89 3mo ago
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 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago

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 3mo ago
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 3mo ago
  Unfortunately GitLab has no such useful features.

tptacek 3mo ago

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

mk89 3mo ago
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 3mo ago
  Which compliance regime are you referring to that cares about CVE counts as a metric?
  - mk89 3mo ago
    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 3mo ago
      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.
      - kasey_junk 3mo ago
        PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.