The last couple of CVEs I was forced to address were in docker images based on alpine or debian, in which the some library version on the system was hit with a High or Critical level CVE. But in reality the ability to exploit the vulnerability required being able to execute a particular program on the running system. The levels of exploit required to even get to being able to exploit this vulnerability in the context I was required to mitigate it meant that in reality, your systems have already been compromised even before this can be exploited.
CVE numbers have exploded while their quality has declined partly due to things like company and project bug bounties, where individuals get bonuses internally for submitting CVEs that get an ID. There's a virtual army of people doing nothing but looking for subtle ways to exploit key tools just to be able to earn a bonus. Some bigger projects, like the linux kernel, dispute some CVEs (e.g. CVE-2023-23005) because they are b.s., but smaller projects don't have the luxury.
Follow the links to the actual issue description and check if it makes sense in your context. While the current aggregators are not perfect, there will always be edge cases where you care about some issues more/less than someone else. The whole idea of having a single number has limitations.
CVE numbers have exploded while their quality has declined partly due to things like company and project bug bounties, where individuals get bonuses internally for submitting CVEs that get an ID. There's a virtual army of people doing nothing but looking for subtle ways to exploit key tools just to be able to earn a bonus. Some bigger projects, like the linux kernel, dispute some CVEs (e.g. CVE-2023-23005) because they are b.s., but smaller projects don't have the luxury.
See the curl maintainer's take on this: https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerab...