FP are reported because of the <name> tag in pom.xml

Describe the bug It seems that under certain circumstances, the <name> tag in pom.xml is used to create CPEs, which might lead to false positives.

Our company projects share a common parent pom, which pre-configures the maven-jar-plugin as follows:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.2.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <addBuildEnvironmentEntries>true</addBuildEnvironmentEntries>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

After a lot of trial and error, I found out that my false positives are triggered by the presence of <addBuildEnvironmentEntries>true</addBuildEnvironmentEntries>.

To Reproduce

I attached a sample Maven project to demonstrate the issue. It "inherits" from this parent pom, and defines multiple modules.

module1 has a <name>Base module</name> tag. When I run mvn clean install && mvn dependency-check:check on the project, I get the following FP: module1-0.3.0-SNAPSHOT.jar (pkg:maven/org.example/module1@0.3.0-SNAPSHOT, cpe:2.3:a:abb:base_software:0.3.0:snapshot:*:*:*:*:*:*) : CVE-2020-8472, CVE-2020-8478. The "Base" word in the <name> tag was used to match abb:base_software. Note that the CPE version is the same as the project version (0.3.0-SNAPSHOT).
If I change module1's <name> to remove the "base" word to let the build continue, I get a similar FP on the next module, whose name contains "HttpClient": module2-0.3.0-SNAPSHOT.jar (pkg:maven/org.example/module2@0.3.0-SNAPSHOT, cpe:2.3:a:apache:httpclient:0.3.0:snapshot:*:*:*:*:*:*) : CVE-2020-13956. I can also workaround this FP by changing the <name> tag.

Those false positives disappear as soon as I comment <addBuildEnvironmentEntries>true</addBuildEnvironmentEntries> in parent-pom.xml. I'm sure sure why, because from what I can see on my sample project, it will only generate a simple MANIFEST.mf file containing something like this:

Manifest-Version: 1.0
Created-By: Maven Jar Plugin 3.2.0
Build-Jdk-Spec: 11
Build-Tool: Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f
 )
Build-Jdk: 11.0.10 (AdoptOpenJDK)
Build-Os: Windows 10 (10.0; amd64)

Additional context

If I remove META-INF/MANIFEST.MF manually dependency-check-modules.zip from ~/.m2/repository/org/example/module1/0.3.0-SNAPSHOT/module1-0.3.0-SNAPSHOT.jar, then the FP disappears.

The false positives also not reported when I use the aggregate goal instead of check.

Version of dependency-check used The problem occurs using version 6.0.2 of the maven plugin.

This is actually working as designed. Please see How dependency-check works. With ODC FP are unfortunately, somewhat expected. You can use a suppression file to reduce the FP in your environment (for instance, if you know your groupId is unique you could suppress all CPEs for your own custom developed modules).

I understand how ODC and suppressions work, what I don't understand is why the presence of MANIFEST.MF triggers the bug, this file does not contain any metadata that could make ODC think my module is apache-httclient.

With ODC FP are unfortunately, somewhat expected.

If the docs could explain in more details what a library developer should add to their manifest so that a strong evidence is provided that my library is not another one, that would be better.

At the moment for example, all it takes for is my module name to contain the word snakeyaml for it to be treated as the upstream, vulnerability affected snakeyaml dependency.

My manifest

Manifest-Version: 1.0
Created-By: Maven JAR Plugin 3.3.0
Build-Jdk-Spec: 11

The real snakeyaml

Manifest-Version: 1.0
Automatic-Module-Name: org.yaml.snakeyaml
Bnd-LastModified: 1664175128357
Build-Jdk-Spec: 1.8
Bundle-Description: YAML 1.1 parser and emitter for Java
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: SnakeYAML
Bundle-SymbolicName: org.yaml.snakeyaml
Bundle-Version: 1.33.0
Created-By: Apache Maven Bundle Plugin 5.1.8
Export-Package: org.yaml.snakeyaml;version="1.33",org.yaml.snakeyaml.c
 omments;version="1.33",org.yaml.snakeyaml.composer;version="1.33",org
 .yaml.snakeyaml.constructor;version="1.33",org.yaml.snakeyaml.emitter
 ;version="1.33",org.yaml.snakeyaml.env;version="1.33",org.yaml.snakey
 aml.error;version="1.33",org.yaml.snakeyaml.events;version="1.33",org
 .yaml.snakeyaml.extensions.compactnotation;version="1.33",org.yaml.sn
 akeyaml.introspector;version="1.33",org.yaml.snakeyaml.nodes;version=
 "1.33",org.yaml.snakeyaml.parser;version="1.33",org.yaml.snakeyaml.re
 ader;version="1.33",org.yaml.snakeyaml.representer;version="1.33",org
 .yaml.snakeyaml.resolver;version="1.33",org.yaml.snakeyaml.scanner;ve
 rsion="1.33",org.yaml.snakeyaml.serializer;version="1.33",org.yaml.sn
 akeyaml.tokens;version="1.33",org.yaml.snakeyaml.util;version="1.33"
Import-Package: org.yaml.snakeyaml;version="[1.33,2)",org.yaml.snakeya
 ml.comments;version="[1.33,2)",org.yaml.snakeyaml.composer;version="[
 1.33,2)",org.yaml.snakeyaml.emitter;version="[1.33,2)",org.yaml.snake
 yaml.error;version="[1.33,2)",org.yaml.snakeyaml.events;version="[1.3
 3,2)",org.yaml.snakeyaml.introspector;version="[1.33,2)",org.yaml.sna
 keyaml.nodes;version="[1.33,2)",org.yaml.snakeyaml.parser;version="[1
 .33,2)",org.yaml.snakeyaml.reader;version="[1.33,2)",org.yaml.snakeya
 ml.resolver;version="[1.33,2)",org.yaml.snakeyaml.scanner;version="[1
 .33,2)",org.yaml.snakeyaml.serializer;version="[1.33,2)",org.yaml.sna
 keyaml.tokens;version="[1.33,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Tool: Bnd-6.3.1.202206071316

Is the Automatic-Module-Name: org.yaml.snakeyaml important here?
Does the Bundle-Version: 1.33.0 also get parsed by ODC?
What about the Export-Package?

This is not explained in the docs, so I have to go look in the source code of ODC to figure that out on my own.

Adding a versionless blanket suppression for my module is deeply unsatisfactory, since it forces all downstream consumers of my module jar to do the same. My library is not vulnerable in this example, since I use snakeyaml 1.33, but is reported as being so, for all known past vulnerabilities of snakeyaml.

     CVE-2017-18640(7.5),
     CVE-2022-38752(6.5),
     CVE-2022-38751(6.5),
     CVE-2022-38750(5.5),
     CVE-2022-25857(7.5),
     CVE-2022-38749(6.5)

Painful.

jeremylong / DependencyCheck

FP are reported because of the <name> tag in pom.xml #3128