I wrote a Discord bot to monitor for CVEs being mentioned in chat, and then it will fetch the details and post it back to chat.

It also has a feature to monitor for new KEV notifications and send them to a dedicated channel

Collab with me. Use it. Abuse it. What ever ya want!

https://github.com/mauvehed/kevvy

Apparently #CISA has rated #curl #vulnerability #CVE_2024_11053 as #CVSS v3 Base Score 9.1 "critical". This is wrong, and will lead to automation triggering unnecessary warnings and blocking use of perfectly fine systems until an update is installed (which can take months). https://nvd.nist.gov/vuln/detail/CVE-2024-11053

Edit: In case you wonder my credentials for judging this: I found this vulnerability.

Edit2: This appears to be originating from CISA: https://www.cve.org/Media/News/item/blog/2024/06/04/CISA-Added-as-CVE-Authorized-Data-Publisher

Edit3: The score has now been fixed. Commit: https://github.com/cisagov/vulnrichment/commit/91fadb2bf6b461638c8155978b9f20cf17e51fe3

#CVSS-Wert von 9,8: Dringender #Patchbedarf in #Mozilla #Firefox - kritische Zero Day #Schwachstelle wird aktiv ausgenutzt:
"Durch die Schwachstelle können Angreifer aus der Ferne Schadcode auf dem Zielsystem ausführen. Eine Nutzerinteraktion ist dafür nicht erforderlich."
https://www.golem.de/news/mozilla-warnt-kritische-zero-day-luecke-in-firefox-wird-aktiv-ausgenutzt-2410-189700.html

New blog post

The National Vulnerability Database (the NVD) appears to be in some sort of hiatus, no longer assigning CVSS information to CVEs. They’ve posted a note:

NIST is currently working to establish a consortium to address challenges in the NVD program and develop improved tools and methods. You will temporarily see delays in analysis efforts during this transition. We apologize for the inconvenience and ask for your patience as we work to improve the NVD program.

If you want to understand what’s happening, hackread says @joshbressers first drew attention to it, and Josh has a podcast on the episode. Me, I wonder if this has to do with the 12% budget reductions at NIST. Beyond the why, many people are quite concerned, because they’ve been using CVSS scores to reduce the amount of patching work they do, generally under a label like “risk management.” (I prefer to think of it as workload management when you’re letting someone else make “risk” decisions for you. And that’s fine. We do this outsourcing in all parts of life, work and personal.)

Full post:
https://shostack.org/blog/the-nvd-crisis/

#NVD #CVSS #patchmanagement
#riskmanagement

Kann eins irgendwo im Internet eine täglich aktuelle Liste aller #CVE mit deren #CVSS Werten bekommen?

Das #NVD bietet eine Liste aller CVEs an, aber die enthält keine CVS Scores.
Ich brauche beides.

Dann gibt es so Systeme wie #OpenVAS oder #OpenCVE, die diese Daten aggregieren, aber die haben keine APIs um an die Daten ranzukommen (oder ich bin zu blöd die zu finden)

Jemensch eine Idee?

Edit: Werde OpenCVE wohl selber hosten und davon dann die API angraben.

This is your regular reminder that CVSSv3 base scores are information-poor, and taken alone are not fit for the purpose of evaluating appropriate actions to take for a given security vulnerability.

I am hoping that CVSSv4 helps improve industry practices. It's badly needed.

#InfoSec #CVSS #CVE
https://csrc.nist.gov/csrc/media/Presentations/2023/update-on-cvss-4-0/jan-25-2023-ssca-dugal-rich.pdf

So #NVD #CVSS scoring is based on trusted source of:

Reddit

​

https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/ #CVE #vulnerability #vulnerabilities

Enterprise #AppSec is one big Milgram experiment:

- #InfoSec is the man with the heart condition
- Product management is the authority figure
- App devs are the subjects
- shocks are increasing levels of insecure code / higher #CVSS scores in unpatched dependencies

AppSec: "Ah! No! I can't take it anymore! I have a heart condition!"

Dev: *looks at product*

Product: "No no, he's fine. I'll accept responsibility. Risk: accepted."

Dev: *adds a poorly implemented graphql endpoint that essentially evals customer-provided code on the database infrastructure*

AppSec: "..."

Dev: "... I think he's dead."

Product: "No no, he's fine. Just keep going. See this CVSS score of 9.9? Neither do I. Let's ship it."

AppSec: *gurgles*

Did you know that following the advice of several security standards to remediate all vulnerabilities with a CVSS score of 7 or above would barely address half of those known to be exploited and almost 70% of that effort would be wasted on things that don't represent real risk right now?

Seem impossible to believe? Check our math in Prioritization to Prediction, Volume 1: https://lnkd.in/eyKzzX25

***
Coverage measures the completeness of remediation. Of all vulnerabilities that should be remediated, what percentage was correctly identified for remediation?

Efficiency measures the precision of remediation. Of all vulnerabilities identified for remediation, what percentage should have been remediated?

I don't know if this is a controversial opinion, but I will state it anyway:

I believe that the CVE system has some serious deficiencies. In particular, using the same system for both user-facing products and third-party libraries is problematic to the point of actually reducing overall security in the industry.

Let me give an example: Let's say you run a self-hosted piece of server-software written in Java. Let's call the product "Foo". You use something like Sonatype to monitor vulnerabilities in the software you use.

You happily run Foo for a few months and CVE-2023-0001 is reported on product Foo with a CVSS score of 9.9. In this case the system works great because you can now patch Foo as soon as possible, and in the meantime you can look at the remediation procedure documented in the CVE report to determine how much of a hurry you are in.

But that's unfortunately not what happens. What you are actually going to see is hundreds of vulnerabilities of varying severity reported not just on Foo as a product, but on every single third-party library that the product Foo happens to use.

Let's say that Foo generates SVG from a template and then uses a library to convert said SVG into images before sending them to the client (never mind that seems like a stupid solution, just go with it). And then a CVSS 10.0 appears because there is an RCE when passing specially crafted SVG data to the library.

Now you have Sonatype reporting that you have a severity 10 issue with the workaround static "upgrade this library". This information would be useful for the developer of Foo, but not for the user.

In fact, the developer may already have investigated this and downgraded the score since the library is never used to process untrusted input.

What this means is that as a user of some piece of software you will feel a lot of pressure internally to pursue CVE reports that are in fact not relevant, but since it shows up in your scan you have an obligation to do this, and check with the vendor to ask about the root cause of these results. This takes time and energy away from your real job: To keep your infrastructure secure.

I lay the blame for this happening squarely on the bad organisation of the CVE database, and I really wish there was a better way. Unfortunately right now it's all we have.

#CVSS scores are basically like NPS scores at this point, if it’s not a 10 it’s functionally a zero

#introduction Hello Mastodon. I'm https://about.me/vipergeek
Feels like Twitter back in 2009. Kinda nice. #cybersecurity #infosec #psirt #cvss