CVE referencing Tomcat are not also referencing Tomcat-embed

[fmarot]

I'm in the process of switching from Dependency-check Dependency-track to analyse vulnerabilities on my dependencies.
I analyze a classic spring boot webapp depending upon org.apache.tomcat.embed:tomcat-embed-core. Dependency Check (who uses a kind of fuzzy logic) detects CVEs (such as CVE-2023-28709 or CVE-2023-41080).
Dependency-track does not detect those CVE.
I imagine (not totally sure) that those CVE are also affecting tomcat-embed-core and not only apache:tomcat, but it seems like they are not targeting this "by product" of the classic Tomcat.

What is or should be the correct process ? Should the Tomcat team declare those CVE as also affecting tomcat-embed-core ? Should the CVE people do the job by themselves ?

I've just found out that I'm not the only one having those questions: https://stackoverflow.com/questions/74886946/vulnerablities-for-tomcat-embed-core-in-owasp-dependencytrack but still looking for advice/guidance.

I've brought the subject to the Tomcat mailing-list where they tell me to report the problem to DependencyTrack project. I would think the problem is not with Dependency track but with the way CVEs are created, not flagging enough Tomcat components.

What do you think ?

Best regards

[fmarot]

up
(sorry but I'm lost on what is the theorical best way to handle this problem... I do not think SBOM can become thoroughly used if this kind of problem is not tackled)

[nscuro]

In an ideal world, the Tomcat project would report CPEs and / or Package URLs, as well as version ranges of all affected software artifacts to the vulnerability database. As it is today, it looks like they only report the product "Tomcat" to be vulnerable. Does this mean org.apache.tomcat:tomcat-jdbc is also affected? Or org.apache.tomcat:servlet-api? Not really.

This level of granularity is not only important so that systems like DT can reliably detect vulnerabilities, but also aids in reducing the noise: The log4shell CVE https://nvd.nist.gov/vuln/detail/CVE-2021-44228 was reported for "log4j", which completely ignores the fact that log4j is split into multiple modules (log4j-api, log4j-core, etc.), and only one of them was actually vulnerable. Applications supporting the log4j API were flagged as vulnerable even though they were not.

If a project is reporting a CVE, by that time it should know which parts of their ecosystem, product, or application are affected. It makes sense that they encode this information in their report. However, most of these projects are driven by volunteers, so demanding these things is probably not fair.

Interestingly, you'll find that databases like GitHub actually do list tomcat-embed-core as affected package, even though the NVD doesn't: GHSA-q3mw-pvr8-9ggc. I don't know whether this is done manually or by automated mapping.

From DT's perspective, currently the following options exist:

• Enabling additional vulnerability sources that do provide more accurate data (i.e. GitHub Advisories)
• Using a proprietary scanner, backed by a proprietary vulnerability database which has more accurate data (i.e. Snyk)
• Reporting the missing data points to the free scanning providers (i.e. Sonatype OSS Index; But requires you to know what's missing)
• Create internal vulnerabilities to compensate for missing data in public databases (again, requires you to know what's missing, so not that practical)

Additionally, DT could potentially:

• Consider supporting corrective hints, or hardcoded mappings, allowing for "if encountering component X, also look for vulnerabilities of component Y" kind of logic (increased risk of false positives)

The downside is that the farther away from the source of truth (here: the Tomcat project) we get, the more inaccurate and delayed the information becomes. It's all just compensation for reported CVEs not being granular enough.

There is work being done by the SBOM forum to improve the current situation of identifiers in the NVD. But it will take time to come to fruition.

[fmarot]

Thank you veeeeery much for this detailed answer and all the work 👍