Re: Node.js EOL CVEs: CVE-2025-23087, CVE-2025-23088, CVE-2025-23089

[Pete Allor <pallor () redhat com>]

Florian,
The question is about who is scoring and a level of their knowledge and
understanding.   Assuming that each is using CVSS v3.1 then the question is
does the scoring entity look at how the component is built and used or are
they scoring for every eventuality and device across all time (and in turn
introducing 'temporal' scoring into that 'base' score).   We often see that
broad interpretation and the creeping in of temporal scoring to "elevate"
the CVSS.

It is why I would advocate for a CVSS review (as we do at Red Hat) and then
assign a 'Severity Rating' as that now involves how the component is used
within our software which changes HOW a customer/downstream/user should
actually view that CVE.

So I will state that the way some aggregators of CVEs assign CVSS is the
problem.   Consider that overreach and then the reliance by regulators
and/or internal audit make a broad rule and everyone is bringing down the
house.

So the issue of identifying the 'component' becomes truly important (CPE
does not cover OSS and hence the new drive to incorporate PURL to better
identify CVEs and essentially get to your fork construct.

Pete

On Mon, Jan 27, 2025 at 1:34 AM Florian Weimer <fweimer () redhat com> wrote:

> * Pete Allor:
>
> > I do agree with Greg K-H that open source projects should become CNAs.
> > But do want to note that missing elements of the CVE when submitting
> > allows CISA-ADP to 'vulnrich' your data.  Here is where
> > misinterpretation and/or lack of understanding by CISA confuses
> > downstream users and once you gain that 'critical' stigma in the
> > system, you have to be persistent to get that changed.
> >
> > Is that a problem?  I think so and so do a number of PSIRTs so now we
> > have to contend with CISA-ADP and NVD to adjust their scores when the
> > CNA is 'the authoritative source' within the CVE Program.
>
> The larger problem is that component scoring tends to be higher than
> whole-system scoring.  If a security component fails in its security
> function, it certainly deserves an impact rating that reflects that it's
> totally broken due to the vulnerability.  But if this component is
> integrated into a larger system, impact is often lower and might even be
> insignificant due to the way the component is used.
>
> The current system does not really reflect that.  One way to deal with
> it could be to treat everything as a fork, but not to decouple from
> upstream changes, but to make it clear that the upstream impact ratings
> do not apply.
>
> Thanks,
> Florian