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

jf audit - Maven Multi-module not detected correctly #2019

Open
marcandre-larochelle-bell opened this issue Jun 6, 2023 · 5 comments
Open
Labels
bug Something isn't working

Comments

@marcandre-larochelle-bell
Copy link

marcandre-larochelle-bell commented Jun 6, 2023

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.
image

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

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-bell marcandre-larochelle-bell added the bug Something isn't working label Jun 6, 2023
@marcandre-larochelle-bell marcandre-larochelle-bell changed the title Maven Multi-module not detected correctly jf audit - Maven Multi-module not detected correctly Jun 6, 2023
@marcandre-larochelle-bell
Copy link
Author

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-bell
Copy link
Author

marcandre-larochelle-bell commented Jul 6, 2023

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
Copy link
Member

omerzi commented Jul 9, 2023

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-bell
Copy link
Author

marcandre-larochelle-bell commented Jul 11, 2023

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)

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants