jf audit - Maven Multi-module not detected correctly

[marcandre-larochelle]

Describe the bug

I'm not sure if this is intentional or not, but the JSON output from 2.34.0 to 2.36.1 changed at some point and doesn't display the correct package_type anymore (and different structure).

Current behavior

Single component named "root" with "Generic" as the package type.

What it used to be:
Multiple components with their module name and "Maven" as their package type.

Reproduction steps

• Run a scan with JFrog CLI 2.36.0 on a multi-module maven project
• Run a scan with JFrog CLI 2.36.1 on a multi-module maven project
• Compare the outputs

Expected behavior

Either one of:

• Singular scan_id with the component_id matching the name of the root project and package_type maven.
  • Not sure how it should handle projects with mixed languages however.
• Multiple scan_id with each modules with package_type maven.

JFrog CLI version

2.36.1

Operating system type and version

Docker

JFrog Artifactory version

No response

JFrog Xray version

No response

[marcandre-larochelle]

Sorry for tagging, @sverdlov93, but I was wondering if you could take a look at this, I haven't heard back and it is preventing us from updating to the latest version, we just need to confirm whether it is intentional or a bug to take the appropriate measure (wait on a fix vs change our code ingesting the format),

Thanks in advance.

[marcandre-larochelle]

Updated the ticket with the exact version where it started to happen,

In version 2.36.1, due to this: jfrog/jfrog-cli-core#736, this was labeled as an "Improvement" (probably should've been labeled as a breaking change not a revision...).

It still doesn't recognize the multi-module maven project as a maven project, but instead as a "Generic", it also doesn't recognize the name of the project and instead shows "Root". Still true in version 2.42.1

[omerzi]

Hi @marcandre-larochelle-bell, we apologize for the inconvenience caused by this update and for the delayed response. We have changed how we build the graph to significantly improve performance. Now, the graph has an additional level of root and is of type “Generic” to accommodate multiple technologies.
All scanned modules can be found under the root node.
Also, I can suggest using the ‘simple-json’ format, which represents the audit table view in JSON format. It might be helpful for you.
We'll be more than willing to listen if you have any further questions or suggestions.

[marcandre-larochelle]

Hi @omerzi, it seems like it isn't just an additional json level, but rather that all vulnerabilities / licenses were also merged together (and cannot be found under the root node per module). It seems like the "package_type" has entirely disappeared from the json structure as well.

It is less convenient to know what are the vulnerabilities of one module as it was entirely flipped up-side down, now it is vulnerabilities -> components -> impact_paths -> component_id instead of just component_id, but I can deal with that knowing it was intended.

The simple-json format is definitely not what we are looking for, we do use and parse all the information found in the json format.

What I can suggest:

• Following a semantic versioning
  • At a minimum it should've been a minor version as it include breaking changes
  • It broke our tool and there was no way to know if it was intended or not based on the versioning
• Document the new format (and keep it updated when changes happen)
  • There used to be a structure of the previous Json format in the documentation, now it is just gone and it hasn't been updated with the new one. (see: jf audit - missing JSON format documentation #2016)

I've started looking into switching to the SARIF format as it is more standard to avoid this kind of issue in the future, however it is missing almost every fields the Json format counterpart has (you can take a look at #2063). Do you know if it is being worked on currently? This is something we are really looking forward to be using, but as is (with all the missing information), it is unusable. Note that while it is more standard, it uses property bags, it still make sense to have a minimum of documentation as well on which information is stored where.

Thanks in advance!

[attiasas]

Hello @marcandre-larochelle-bell,

We encourage you to try the outputs in both SARIF and simple-json formats from our latest released versions. We have made several enhancements, including bug fixes and the addition of more attributes to the results.

Additionally, please feel free to let us know if you encounter any issues or have specific feature requests. Your feedback is invaluable to us as we work to enhance our offerings and address user needs.