The Maven dependencies graph is different from other package managers

[kennylam91]

With the release of V3, I see that sbom-tool can generate correct relationships between packages.
But somehow the relationship graph of Maven is different from others.
For example here is a npm project graph:

But for maven, it always has another maven root package besides sbom root package.

This causes issues when we want to get all direct dependencies, for example.

Do you think we should do something about this?

[JoseRenan]

Hey @kennylam91, thanks for reporting this! Would you mind sharing your pom.xml? I'm trying to replicate the problem with Component Detection (which is the package we use for detecting components) but it doesn't seem to have the same problem 🤔 I'm running with this project: https://github.com/quarkusio/quarkus-quickstarts/tree/main/getting-started and the getting-started@1.0.0-SNAPSHOT seems to be the root of the graph when running there

[kennylam91]

Hi @JoseRenan , thanks for looking into this issue.
Here is the pom.xml and the sbom file generated by ms-sbom@3.0.1 manifest.spdx.json

<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.acme</groupId>
  <artifactId>getting-started</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <properties>
    <compiler-plugin.version>3.12.1</compiler-plugin.version>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
    <quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
    <quarkus.platform.version>3.8.2</quarkus.platform.version>
    <skipITs>true</skipITs>
    <surefire-plugin.version>3.2.5</surefire-plugin.version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>${quarkus.platform.artifact-id}</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-arc</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-resteasy-reactive</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-junit5</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>rest-assured</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>quarkus-maven-plugin</artifactId>
        <version>${quarkus.platform.version}</version>
        <extensions>true</extensions>
        <executions>
          <execution>
            <goals>
              <goal>build</goal>
              <goal>generate-code</goal>
              <goal>generate-code-tests</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${compiler-plugin.version}</version>
        <configuration>
          <compilerArgs>
            <arg>-parameters</arg>
          </compilerArgs>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>${surefire-plugin.version}</version>
        <configuration>
          <systemPropertyVariables>
            <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
            <maven.home>${maven.home}</maven.home>
          </systemPropertyVariables>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>${surefire-plugin.version}</version>
        <executions>
          <execution>
            <goals>
              <goal>integration-test</goal>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <systemPropertyVariables>
            <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path>
            <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
            <maven.home>${maven.home}</maven.home>
          </systemPropertyVariables>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <profiles>
    <profile>
      <id>native</id>
      <activation>
        <property>
          <name>native</name>
        </property>
      </activation>
      <properties>
        <skipITs>false</skipITs>
        <quarkus.package.type>native</quarkus.package.type>
      </properties>
    </profile>
  </profiles>
</project>

[kennylam91]

So the additional package getting-started here might represent the maven module. The project quarkus-simple can contain multiple modules.

[JoseRenan]

Yes, sorry the delay with this, but you're right! We get this graph from component-detection and checking here, they consider the pom file itself as a package that the project depends on, trying on a project with multiple modules, it behaves as you mention, we get a root project e multiple pom modules as direct dependencies to this root, and each one having its own direct dependencies. Also tried with Nuget packages for .NET and it seems to work similarly as with maven.

Also, was able to replicate the same behavior with npm 🤔 but I couldn't replicate it with a pip project though, and my theory is that's because the way pip and pip detection works, considering the requirements.txt file, which only defines the dependencies and not the package itself like the other examples (Maven, Nuget, NPM)

[JoseRenan]

Just to better explain the findings:

When we run CD, we get a dependency graph like this:

"dependencyGraphs": {
    "C:\\teste\\piptest\\requirements.txt": {
      "graph": {
        "click 8.1.8 - pip": [
          "colorama 0.4.6 - pip"
        ],
        "flask 3.1.0 - pip": [
          "blinker 1.9.0 - pip",
          "click 8.1.8 - pip",
          "itsdangerous 2.2.0 - pip",
          "jinja2 3.1.5 - pip",
          "werkzeug 3.1.3 - pip"
        ],
        "blinker 1.9.0 - pip": null,
        "jinja2 3.1.5 - pip": [
          "markupsafe 3.0.2 - pip"
        ],
        "werkzeug 3.1.3 - pip": [
          "markupsafe 3.0.2 - pip"
        ],
        "colorama 0.4.6 - pip": null,
        "markupsafe 3.0.2 - pip": null,
        "flask-mysql 1.6.0 - pip": [
          "flask 3.1.0 - pip",
          "pymysql 1.1.1 - pip"
        ],
        "pymysql 1.1.1 - pip": null,
        "itsdangerous 2.2.0 - pip": null
      },
      "explicitlyReferencedComponentIds": [
        "flask 3.1.0 - pip",
        "flask-mysql 1.6.0 - pip"
      ],
      "developmentDependencies": [],
      "dependencies": []
    }
  }

We get each of those dependency graphs and create a depends_on relationship from the SPDX_RootPackage to it. The thing is that for Maven (and others) projects, I found that the package described by the pom file itself is also included on this dependency graph as the root, I think that doesn't happen on python since the requirements.txt doesn't describe a package, only its dependencies, but I'm not sure if this is expected for CD and I'm investigating if #833 can be related to this 🤔

The same happens when you create a project with multiple modules, component detection will create for each one a dependency graph inside dependencyGraphs and that will also reflect on the SBOM.

[kennylam91]

Hi @JoseRenan , thanks for your attempts and explainations. If this is the way how component detections work, then I think we can't do anything but adapt how we consume the sbom results.