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

Parsing gradle dependencies from the output of ./gradlew dependencies task #1553

Closed
ajmalab opened this issue Feb 8, 2023 · 6 comments
Closed
Labels
enhancement New feature or request external-data Data for cataloging that does not exist in packaging metadata (--with tools candidate)

Comments

@ajmalab
Copy link

ajmalab commented Feb 8, 2023

What would you like to be added: Parse the output of the ./gradlew dependencies task to construct the sBOM

Why is this needed: Currently, the .jar artifact has to be built for Syft to be able to read the dependencies and output an sBOM. Scanning it from the output of the dependencies task would make it more efficient as we could avoid the build step.

Additional context:

@ajmalab ajmalab added the enhancement New feature or request label Feb 8, 2023
@ajmalab ajmalab changed the title Parsing gradle dependencies from the out put of ./gradlew dependencies task Parsing gradle dependencies from the output of ./gradlew dependencies task Feb 8, 2023
@kzantow kzantow added this to OSS Feb 9, 2023
@tgerla
Copy link
Contributor

tgerla commented Feb 23, 2023

Hi @ajmalab, thanks for the feature request. Are you looking for Syft to invoke gradlew itself and parse the output?

We do have another issue that needs to get completed before this work could start: #1562

Alternatively, if you want to generate an SBOM yourself from the gradlew dependencies and put it in the directory that Syft scans, Syft will see it and include the contents in the resulting output.

@tgerla tgerla moved this to Awaiting Response in OSS Feb 23, 2023
@ajmalab
Copy link
Author

ajmalab commented Mar 21, 2023

Hey, apologies for the late reply, didn't get notified about the comment.

Yes, Syft invoking gradlew to run the dependencies task would be ideal. Currently, you'd have to build the jars manually using gradlew any way for Syft to parse any dependencies.

The linked issue #1562 seems relevant, however it makes no mention of Gradle.

@tgerla
Copy link
Contributor

tgerla commented Mar 21, 2023

No problem! Yes, #1562 isn't specific to Gradle. We are using it to generally track feature requests where Syft must reach out to an external service. Thanks for the additional context!

@tgerla tgerla removed the status in OSS Mar 21, 2023
@tgerla tgerla added the external-data Data for cataloging that does not exist in packaging metadata (--with tools candidate) label Jun 22, 2023
@tgerla
Copy link
Contributor

tgerla commented Jun 22, 2023

Hi @ajmalab, an update here: based on Syft's design and architecture it probably will never directly execute third party tools like gradlew. But, if as part of your build step, you could run "gradlew dependencies" and store the output in a place where Syft can find it, we could add a cataloger to Syft that recognizes that output an include the results in the SBOM. Do you think this would work for your use case? We would be happy to discuss it.

@tgerla tgerla moved this to Awaiting Response in OSS Jun 22, 2023
@ajmalab
Copy link
Author

ajmalab commented Jul 14, 2023

Hi! I see, that's understandable. The approach you've described is feasible too. I think this way you'd be able top populate the dependencies block of the sbom too for Gradle projects!

@spiffcs
Copy link
Contributor

spiffcs commented Jul 19, 2023

Closing this as not planned for right now given @tgerla's above comment - users can front run their SBOM generation with dependency commands so that syft does not need to shell out and run individual package manager commands

@spiffcs spiffcs closed this as not planned Won't fix, can't repro, duplicate, stale Jul 19, 2023
@github-project-automation github-project-automation bot moved this from Awaiting Response to Done in OSS Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request external-data Data for cataloging that does not exist in packaging metadata (--with tools candidate)
Projects
Archived in project
Development

No branches or pull requests

3 participants