Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug(java): dependOn contains extra dependencies for pom.xml files with modules when using SBOM formats #7802

Open
DmitriyLewen opened this issue Oct 28, 2024 · 3 comments
Assignees
Milestone

Comments

@DmitriyLewen
Copy link
Contributor

Description

When we parse pom.xml files with modules - we mark modules as root dependencies.
e.g.:

➜ cat pom.xml
    <groupId>com.example</groupId>
    <artifactId>root</artifactId>
    <version>1.0.0</version>

    <modules>
        <module>module1</module>
        <module>module2</module>
    </modules>

</project>

➜ trivy -q fs ./pom.xml -f json --list-all-pkgs
...
          "ID": "com.example:module1:1.0.0",
          "Relationship": "root",
...
          "ID": "com.example:module2:2.0.0",
          "Relationship": "root",
...
          "ID": "com.example:root:1.0.0",
          "Relationship": "root",
...

This is not problem for Trivy formats.

But when we collect relationships for BOM Core - these root packages contain incorrect relationships:

    {
      "ref": "pkg:maven/com.example/[email protected]",
      "dependsOn": [
        "pkg:maven/com.example/[email protected]"
      ]
    },
    {
      "ref": "pkg:maven/com.example/[email protected]",
      "dependsOn": [
        "pkg:maven/com.example/[email protected]"
      ]
    },

Solutions

I see several solutions for this case:

  • we don't save modules in DependsOn array of root pom.xml file. We can save them and use the following logic - root->module->dependencies.
    Before marking root Package in BOM Core we will detect root pom from all root Packages.
    But i am not sure about this way.
  • add new Relationship module. We can't say that module is root package, but on other hands we can't say that module is dependency, so adding module relationship looks like a solution.
@knqyf263
Copy link
Collaborator

knqyf263 commented Oct 29, 2024

If I remember correctly, Cargo workspaces are similar to Maven modules, right? npm also has workspaces. I expected that we would need a new relationship, so I'm okay with adding a new relationship. However, considering other ecosystems, we would like to make the implementation as common as possible.

  1. Adding only module
    • Using module for Maven and other ecosystems
  2. Adding only workspace
    • Using workspace for Maven and other ecosystems
  3. Adding module and workspace
    • Using module for Maven and workspace for other ecosystems

Trivy is currently flattening all dependencies in Cargo workspaces, unlike Maven, so the new relationship type may not be necessary now, but it may be needed in the future and should be implemented with that in mind.

@DmitriyLewen
Copy link
Contributor Author

I think it's safe to say that maven modules and npm workspaces are the same thing across languages.
I don't want to create 2 fields for the same cases.
So I think it's better to create only workspace.

For users using only Java, this might be confusing, but we'll write in the documentation that we use workspace instead of modules to unify the names.
We can get feedback, and add modules if it raises too many questions.

For users who use Java and NPM (as example) - I think it'll be logical

@knqyf263
Copy link
Collaborator

Yes, I'd also vote for the option 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

3 participants
@knqyf263 @DmitriyLewen and others