Yarn Berry analyzer does not report vulnerability score

[marcelstoer]

Describe the bug
The Yarn Berry analyzer does not report vulnerability scores.
Hence, you cannot automatically fail executions based on CVSS evaluation (failBuildOnCVSS parameter).

This in turn makes vulnerabilities in Yarn Berry projects effectively go unnoticed!

Version of dependency-check used
12.2.2

To Reproduce
See the reproducer (for both Yarn versions) at https://github.com/marcelstoer/odc-yarn-berry-reproducer

Expected behavior
Running ODC with failBuildOnCVSS=7 should fail for any NPM package that has vulnerabilities with CVSS scores >=7.

Preliminary analysis
AFAIU the issue is in the YarnAuditAnalyzer.java analyzePackageWithYarnBerry() → parseAdvisoryJsons() sequence.
There is no CVSS score ever extracted or set on the Advisory object.
With Yarn Classic we hit the npm audit API directly and get back full advisory data (including numeric CVSS scores).

1. yarn npm audit --json emits a text "Severity": "Moderate" field.
2. parseAdvisoryJsons() copies that string into advisory.setSeverity(severity). No CVSS number is parsed or stored.
3. The resulting Advisory has no numeric score → dependency-check reports it as "Unscored" with severity label "moderate".
4. -DfailBuildOnCVSS=7 compares against a numeric score that doesn't exist.

Running yarn npm audit --all --recursive --no-deprecations --json gives me this (stripped):

{
  "value": "uuid",
  "children": {
    "ID": 1119441,
    "Issue": "uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided",
    "URL": "https://github.com/advisories/GHSA-w5hq-g745-h8pq",
    "Severity": "moderate",
    "Vulnerable Versions": "<11.1.1",
    "Tree Versions": [
      "3.3.2"
    ],
    "Dependents": [
      "@ti8m/workbench-widget-loader@workspace:."
    ]
  }
}

Tagging @segovia as the original contributor of the Berry analyzer.

[chadlwilson]

I'm not sure this is an accurate characterisation? Unscored severities are translated to proxy CVSS scores before comparison in all of the plugins/integrations etc (alas with copy and pasted code, it seems).

That issue is a Moderate via the API. That gets normalized to MEDIUM. MEDIUM is treated as 6.9 and your rule there is to fail at CVSS 7 (the lowest end of HIGH).

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/utils/SeverityUtil.java

Lines 58 to 83 in 7099469

	/**
	* Estimates the CVSS V2 Score based on a given severity. The implementation
	* will default to 3.9 if no recognized "severity" level is given (critical,
	* high, low).
	*
	* @param severity the severity text (e.g. "medium")
	* @return a score from 0 to 10
	*/
	public static Double estimateCvssV2(String severity) {
	switch (severity == null ? "none" : severity.toLowerCase()) {
	case "critical":
	case "high":
	return HIGH;
	case "moderate":
	case "medium":
	return MEDIUM;
	case "info":
	case "none":
	case "informational":
	return NONE;
	case "low":
	case "unknown":
	default:
	return LOW;
	}
	}

e.g for Maven

DependencyCheck/maven/src/main/java/org/owasp/dependencycheck/maven/BaseDependencyCheckMojo.java

Lines 2918 to 2930 in 140b90a

	final double cvssV2 = v.getCvssV2() != null && v.getCvssV2().getCvssData() != null && v.getCvssV2().getCvssData().getBaseScore() != null ? v.getCvssV2().getCvssData().getBaseScore() : -1;
	final double cvssV3 = v.getCvssV3() != null && v.getCvssV3().getCvssData() != null && v.getCvssV3().getCvssData().getBaseScore() != null ? v.getCvssV3().getCvssData().getBaseScore() : -1;
	final double cvssV4 = v.getCvssV4() != null && v.getCvssV4().getCvssData() != null && v.getCvssV4().getCvssData().getBaseScore() != null ? v.getCvssV4().getCvssData().getBaseScore() : -1;
	final boolean useUnscored = cvssV2 == -1 && cvssV3 == -1 && cvssV4 == -1;
	final double unscoredCvss = (useUnscored && v.getUnscoredSeverity() != null) ? SeverityUtil.estimateCvssV2(v.getUnscoredSeverity()) : -1;
	if (failBuildOnAnyVulnerability
	|| cvssV2 >= failBuildOnCVSS
	|| cvssV3 >= failBuildOnCVSS
	|| cvssV4 >= failBuildOnCVSS
	|| unscoredCvss >= failBuildOnCVSS
	//safety net to fail on any if for some reason the above misses on 0
	|| failBuildOnCVSS <= 0.0

If it's not failing with failBuildOnCVSS=6 then there is a different problem...

[chadlwilson]

Perhaps the confusion is that CVE-2026-41907 is only CVSS 3.0=7.5 as scored by NVD. Somehow it cites CVSS 4.0 = 8.1 HIGH on the CNA data on NVD at https://nvd.nist.gov/vuln/detail/CVE-2026-41907 however I've no idea where they got this from. As far as I can tell from teh GHSA data, it was scored at CVSS4.0 = 6.3 since the start.

They have also got exploit maturity in the GitHub vector string at NVD, but to my knowledge GH don't even publish that data as a CNA - at least they don't allow you to set that in the string as a maintainer.

It's CVSS 4.0 = 6.3 on the GHSA now, hence Moderate via the API, so seems correct to me.

Bit of a side issue, but to my knowledge, ODC has no way of handling or dealing with multiple CVSS scores from different locations (and choosing between them) either.

[marcelstoer]

Thanks for the feedback. Again, I learned something (forgot about the unscored severity mapping).

We seem to look at this from different angles. Yes, there are inconsistent scores for this specific vulnerability. However, I am more concerned about the "light-weight" or limited process/enrichment that the Berry analyzer implements.

The ODC HTML report is significantly reduced for the Berry version.

Given the small dataset that yarn npm audit --json returns, could we extract the GHSA ID from "URL": "https://github.com/advisories/GHSA-w5hq-g745-h8pq", call https://api.github.com/advisories/GHSA-w5hq-g745-h8pq (a rate-limited API) and extract the CVE ID from

  "identifiers": [
    {
      "value": "GHSA-w5hq-g745-h8pq",
      "type": "GHSA"
    },
    {
      "value": "CVE-2026-41907",
      "type": "CVE"
    }

to add it to Advisory#cves. Also, we could extract cvss_severities.cvss_v3 and v4 from the GH API response.

[chadlwilson]

We seem to look at this from different angles. Yes, there are inconsistent scores for this specific vulnerability. However, I am more concerned about the "light-weight" or limited process/enrichment that the Berry analyzer implements.

Well not necessarily, because I was only looking at the angle you focused on in your Expected Behaviour - you reported a bug - to which I an explaining why it is behaving as expected and not omitting vulnerabilities as reported :-)

Hence, you cannot automatically fail executions based on CVSS evaluation (failBuildOnCVSS parameter).
This in turn makes vulnerabilities in Yarn Berry projects effectively go unnoticed!

So this bit is not correct. And worth noting that even if the CVSS 4.0 score did come from the GHSA API it'd still be moderate and still underneath your threshold.

So there's no bug reported here right now; but of course there are always opportunities for improvement. But now it sounds like you're really talking about #6540, or using the existing GHSA stuff in open-vulnerability-clients or something like that, which is a whole can of worm. Probably requires much cleaner decoupling of "identification of relevant packages" from "identification of vulnerabilities for those packages" and "de-duplication of vulnerabilities and/or packages" from what I have seen of the logic among analyzers :-(

[marcelstoer]

even if the CVSS 4.0 score did come from the GHSA API it'd still be moderate and still underneath your threshold.

That's right, GHSA is consistent here. I was, however, surprised to see that they also have a v3 score in the API JSON response which they don't show in the GUI. The API returns the original advisory of course. Anyway, that's OT...

Hence, you cannot automatically fail executions based on CVSS evaluation (failBuildOnCVSS parameter).
This in turn makes vulnerabilities in Yarn Berry projects effectively go unnoticed!

So this bit is not correct.

That's correct as well. Thanks to your hints and me spending more time analyzing this issue, I now understand that my initial conclusion was wrong.

So there's no bug reported here right now

Is it a bug that the results of the Yarn Classic analyzer are not consistent with the results of Yarn Berry analyzer? The reported score is different and the content in our report is different. Does it matter? I don't know.

However, since the NPM audit API used by Yarn Classic is planned to be removed around July 15th - as we learned - I wanted to verify once again that our Berry analyzer does what it should. I have no problem to close this issue if you think there's nothing to do for us ATM.

[chadlwilson]

Well it's deliberate that they use different mechanisms so they don't have to parse lockfiles, so I guess not a bug.

Easiest path forward might be to just PR to Yarn itself to extract and include additional metadata (even if only in the JSON and not output to the CLI) since it likely has it available to it anyway.

[chadlwilson]

Some of this also predates the migration of npm to use GHSA, so I imagine it was "lowest common denominator" in its internal impl.