[FP]: [email protected]

[kajh]

Package URl

pkg:maven/com.itextpdf/[email protected]

CPE

cpe:2.3:a:itextpdf:itext:5.5.13.3:*:*:*:*:*:*:*)

CVE

CVE-2022-24196, CVE-2022-24197

ODC Integration

{"label"=>"Maven Plugin"}

ODC Version

9.2.0

Description

Sonatype OSS does not report any vulnerabilities for itextpdf 5.5.13.3, please see https://ossindex.sonatype.org/component/pkg:maven/com.itextpdf/[email protected]

Please also see #3762 and #6721

[github-actions]

Maven Coordinates

<dependency>
   <groupId>com.itextpdf</groupId>
   <artifactId>itextpdf</artifactId>
   <version>5.5.13.3</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #6722
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.itextpdf/itextpdf@.*$</packageUrl>
   <cpe>cpe:/a:itextpdf:itext</cpe>
</suppress>

Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/9447400589

[github-actions]

Maven Coordinates

<dependency>
   <groupId>com.itextpdf</groupId>
   <artifactId>itextpdf</artifactId>
   <version>5.5.13.3</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #6722
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.itextpdf/itextpdf@.*$</packageUrl>
   <cpe>cpe:/a:itextpdf:itext</cpe>
</suppress>

Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/9447443791

[aikebah]

We're not in a position to judge whether iText 5 is also affected by the reported flaws or not. If you can find proof that iText 5 was checked for safety to these flaws and found to be not-affected you should share your results with the NVD so that they can update the affected software range for iText appropriately to start on a later version.

NVD listed vulnerabilities are reported for all the sub-libraries of the project by design.

Besides these notes I'd like to verify that you're aware that iText 5 is essentially seen as 'outdated software' and should be upgraded even for existing projects to iText 7 or later as per their own README - https://github.com/itext/itextpdf

(as they changed maven coordinates/reprganised the project layout) the upgrades beyond iText5 will not surface to you if you search for the latest version of your library)

The up-to-date github repository for iText libraries is https://github.com/itext/itext-java

[kajh]

Thanks for your comments on both the FP issues I reported. I based my reports on Sonatype not reporting any findings for there dependencies, ref https://ossindex.sonatype.org/component/pkg:maven/com.itextpdf/[email protected].

I understand this is not enough in this case.

[aikebah]

We use multiple sources, OSSINDEX is one of them.

OSSINDEX has its vulnerabilities linked in the database to the exact maven coordinates (though in past there have been occurrences of wrong attribution in their database (too many versions flagged vulnerable) the chances of such a flag being an FP are low for CVEs that in the report have an (OSSINDEX) suffix after the CVE number)

NVD is another source, which uses their proprietary 'Common Platform Enumeration' as the coordinates to link a CVE to. Those are typically 'a project released/versioned as a whole' and may consist of multiple individual libraries, which means any library from that project will be linked to the CPE coordinates and therefor by design flagged by DependencyCheck as being subject to the known vulnerabilities (across all its libraries) for the version of the project.

Due to processing delays in their processes sometimes NVD is first to have a CVE listed with allocated CPE coordinates, sometimes OSSINDEX, so there is still value in using both as sources for OWASP DependencyCheck.

Lack of further updates on iText5 (while they did recently publish an update for BouncyCastle) appears to suggest that OSSINDEX is correct in not listing iText5 for the iText7 CVEs, but without further proof that it has been checked for those and found not vulnerable you would likely have a hard time convincing NVD to list iText 5 as not vulnerable to those CVEs which were originally assessed as 'anything before 7.1.x with the fix is vulnerable'.

[kajh]

Thank you for your explanations!