4 ms·

There are legit security researchers out there, doing good work and finding real issues, but the vast, vast majority are … not that. If you open a security bug

• politelemon 3y ago
  I am concerned that if there is an increase in bogus CVEs, they will be taken less seriously over time and a lot of the good important work will be lost. What can we normal non security people do?
  • politelemon 3y ago
    I don't like where my thought process is going. A state sponsored team decides to creates hundreds of bogus CVEs that get through. People stop trusting CVEs and it becomes a dirty word. Legitimate CVEs now start getting ignored and there is no good mechanism to surface those properly to teams that need to know. People's systems are now more attacker friendly. Governments and corporations too. Or, some private company steps in and says they'll take on the burden of sifting through the bogus. But they are not incentivized in the same way... and might only pick and choose what they work on, or not work on, or ignore their own CVEs.
    • btown 3y ago
      Or, said state-sponsored team maneuvers itself to be that private company that offers to take on the burden! Even if it can't suppress a CVE entirely without tipping its hand, it could delay the announcement - thus giving its attack teams a heads-up on a security advisory! Decentralized multi-party peer review might be one way around this - ensuring that no single entity can function as gatekeeper. It's a lot of overhead, though, and there's way more time sensitivity than there is with academic peer review processes. And who adjudicates who is an independent subject matter expert on Postgres? It's a tough problem, made tougher by the fact that it's a "dark forest" environment where any potential advantage to any party will inevitably be leveraged.
  • lbhdc 3y ago
    It kind of feels like we are already there. Some form of curation of reports seems like it would be an achievable (partial) solution. It seems like it would be less than perfect, but perhaps better than the status quo.
    • TrueDuality 3y ago
      A lot of internal threat teams generate these kinds of reports, usually scoped on the organization(s) they support. Making these publicly available is a tricky proposition as a lot of companies sources are secret sauce kind of deals and they're most valuable when scoped explicitly on the software being used by the organization.
  • marcosdumay 3y ago
    Just stop treating CVEs as some kind of proof of problem with the software. They are a quite good communication channel. You just have to read them, instead of counting the data packages.
    • bityard 3y ago
      You'll have to convince the clipboard warriors who write/perform industry- and government-mandated "security audits" of that first. Good luck...
      • tru3_power 3y ago
        Haha and this is the real problem.
      • marcosdumay 3y ago
        Indeed, they are the problem. They are the problem everywhere, and if we somehow "fix" CVEs so it works the way they think it works, they will keep being the problem in a hundred other contexts. Maybe we should focus on some other place than "fixing" CVEs. But I have no idea how to fix IT charlatanism. But well, I have no idea how to "fix" CVEs either...
  • waihtis 3y ago
    CVEs don't work all that well in standalone as proof of exploitability. It's always good to supplement with things like whether exploit tooling for said CVE exists (proof that there's some actual weakness behind the CVE) - or use data feeds like EPSS which rely on actual verified exploits to create their exploit probability score.
  • ozim 3y ago
    They are already taken non seriously at all. Security theater industry somehow fares well still.
  • pixl97 3y ago
    > What can we normal non security people do? Hire security people that understand CVEs and if they apply to your environment or not. Unfortunately it's a complicated system and even with valid CVEs out there they don't always make sense for what your application does. I work in code security and implementation of this software in 'secure' environments and we always have customers complain that scanners find CVEs in our software. Then we have to send links to documentation explaining what the CVE means and that very particular implementation details are involved that make the CVE dangerous that are not met by our application. Then the clients want to do the 'well the app found it, you fix it' crap.
  • cyanydeez 3y ago
    I doubt malware providers might spend their time showing discord....
• paulryanrogers 3y ago
  Perhaps no CVE should be issued with independent verification?
  • paulryanrogers 3y ago
    ^without (sorry too late to correct)
• deleted 3y ago
  [deleted]
• Xylakant 3y ago
  > If you open a security bug bounty program, for example, you’ll mostly get either auto-generated garbage like this, or just super generic non-issues like exposing numeric ids to clients, using anything less than the strictest CSP headers, etc. No need for a bug-bounty program. I receive regular emails to any public address on our website, warning of clickjacking and capture of passwords (there’s no passwords nor sensitive data on our website), not using the strictest of all SPF/DMARC, …, all from “honest security researchers” and “expecting a bounty no less than 150USD”.
  • ozim 3y ago
    We pay for pentest reports from reputable providers in range of 1k for those kind of findings. Security theatre something something…
• anonymoushn 3y ago
  A fun side effect of this is that if you aren't a security researcher by trade and you report an actual security issue to a bug tracker, the first dozen responses will be arguing that it isn't a security issue rather than engaging with whether it is a bug, since this is the default response to reports that claim to be about security issues
• lampington 3y ago
  I picked up the term "beg bounty" from somewhere a while back. It's a very useful phrase to describe the low-effort run-some-crappy-scan-and-spam-security-at-domain junk that comes through.