[FP]: CVE-2026-24051 for opentelemetry-semconv

[nicolaideffremo]

Package URl

pkg:maven/io.opentelemetry.semconv/opentelemetry-semconv@1.37.0

CPE

cpe:2.3:a:opentelemetry:opentelemetry:1.37.0:::::::*

CVE

CVE-2026-24051

ODC Integration

{"label" => "Maven Plugin"}

ODC Version

12.2.2

Description

No response

[github-actions]

Maven Coordinates

<dependency>
  <groupId>io.opentelemetry.semconv</groupId>
  <artifactId>opentelemetry-semconv</artifactId>
  <version>1.37.0</version>
</dependency>

Suppression rule:

<suppress base="true">
    <notes><![CDATA[
    FP per issue #8773
    ]]></notes>
    <packageUrl regex="true">^pkg:maven/io\.opentelemetry\.semconv/opentelemetry-semconv@.*$</packageUrl>
    <cpe regex="true">cpe:/a:opentelemetry:opentelemetry(:.*)?$</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/33155486023

[marcelstoer]

approved

[github-actions]

Suppress rule has been added to the generatedSuppressions branch.

[chadlwilson]

After thinking again, this suppression is probably Ok, specifically due to the nature of the semconv packages, but please note #8410 which this approval overrode. (I did intentionally approve one for the alpha artifacts recently)

It’s entirely possible that this creates false negatives if there were ever vulns in these packages since I think they are versioned with OT itself, which would make it a duplicate of #7139 and not something we can manage suppressions for at scale.

[marcelstoer]

this suppression is probably Ok

I had looked at #8744 (and #7139 from there) and came to the same conclusion before I approved it.

That being said, we could mitigate the risk for false negatives by additionally adding a <cve> element, couldn't we?

[github-actions]

Suppress already exists in generatedSuppressions branch. See issue #8773.

[chadlwilson]

That being said, we could mitigate the risk for false negatives by additionally adding a <cve> element, couldn't we?

Its.not sustainable to manage cve-by-cve suppressions, even less in a world of AI vuln discovery exponential explosion.

I followed Hans' lead and tell people we don't do it, except in very, very widely used cases (grpc comes to mind) since it would set a bad precedent if we start (or re-start) doing that. Almost every FP is one of three big problems

• target_sw CPE weakness
• ingesting terrible quality jar manifest data as vendor/product and treating it as high quality
• NVD as data source without purl metadata

We need people to contribute to fix bugs/weaknesses.(or even construct proper suppressions), not rely on maintainers spending even more time reviewing and managing suppressions on their behalf. If people spent as much time having their AIs just automate their own suppressions as raising issues here,.we'd all be better off, and they'd stop outsourcing review of their own LLM.spam to the open source community...

In my opinion, these weaknesses are required friction, and a false negative or two is not the end of the world.