pass cyclonedx-gradle-plugin\cli to input a ready file with "gradlew dependencies -q --console > dep.txt"

[2013kaa]

Hi If I understand correctly, when scanning projects with gradle, cyclonedx-gradle-plugin launches its task "gradlew dependencies -q --console" and then analyzes the dependencies. Is it possible to pass cyclonedx-gradle-plugin ( or cli) to input a ready file with "gradlew dependencies -q --console > dep.txt" ?

[2013kaa]

I think this would be a great idea for companies with a lot of development teams. Let me explain a little about my problem and how I arrived at it. All the SCA scanners I've looked at work either through a builder plugin (cyclonedx-gradle-plugin example) or as an audit of build files (build.gradle example). Moreover, the first option is more preferable, as it gives the most complete report. It's normal when you have the ci\cd templating standard and all commands use the same version of gradle and java. You run a separate job in the pipeline with cyclonedx-gradle-plugin and enjoy the resulting bom.json. But in my case this is not so)))) Different commands, different versions of gradle\java\npm\nodejs, there are not at all non-standard pipelines using werf. I tried to create a universal security_pipeline for this, but I realized that this is not a feasible task. But I can ask my favorite developers and devops to dump the results of "gradlew dependencies -q --console > dep.txt" as an artifact from the build stage and pass it as input to your application. After all, all collector plugins still run this task and analyze its result. It seems to me that this will save time, will keep bom.json reports redundant and will be a universal solution.

[ThomGeG]

I'm not entirely sure on what the perceived problem is that you're trying to solve, but it sounds like your build platform (Jenkins, TravisCI, etc.) is doing too much of the heavy lifting rather than your build automation tools (Maven, Gradle, etc.). It also sounds a lot like your problem is tied to whatever it is you're actually using your BOMs for.

Different commands, different versions of gradle\java\npm\nodejs, there are not at all non-standard pipelines using werf.

This seems to be the core of your problem? The fact that if you're a polyglot with multiple ecosystems (Maven, Gradle, SBT, Node, etc.) then there's no one-size-fits-all solution and you need to have all these different tools to generate BOMs as a result? If that's the case though I don't see how consuming a list of dependencies addresses anything, it would only complicate things even more as you'd be introducing yet another BOM format as an intermediary step.

Depending on your use case for the BOMs, Syft (or something similar) may suite your purposes better as they're a jack-of-all-trades-master-of-none. That approach doesn't work for me, as I need accurate information which Syft simply can't provide (so many JARs are lossful and don't contain the groupId in the manifest for it to extract).

The stack I work with is a mix of Maven, Gradle, SBT, and NPM projects. At present we're using CycloneDX's Maven & Gradle plugin for those projects and Syft for the SBT & NPM ones. The BOMs themselves are being used for my own analysis rather than compliance, which is focused on the Maven/Gradle projects. I therefore don't need the same accuracy for them (and the SBT plugin doesn't seem to be actively maintained anymore), so they're just using Syft as a fall-back.

I've got the Gradle plugin configured such that:

• The cyclonedx task depends on the publish tasks so the BOMs are always intrinsically built when publishing a build, and
• The BOM(s) are published as artefacts alongside the actual JAR and any others to our Nexus instance (which the Maven plugin actually does by default)

The important takeaway there being that I'm generating and publishing BOMs naturally using Gradle, not via custom steps in my build platform (Jenkins) that would only complicate things. Depending on your infrastructure and what you're actually using your BOMs for, you could do something similar and better leverage your build tools to avoid bloating your build platform with more esoteric logic.

[2013kaa]

@ThomGeG thanks for the answer)) you are right! There are a lot of nuances, but that's another story)) Tell me more, do I understand correctly that you add the SBOM formation stage to this Build? Or is it a separate job in ci?

[ThomGeG]

I got my words a little twisted there, what I'm specifically doing is making the assemble task depend on the cyclonedxBom task:

project.tasks.assemble.dependsOn project.tasks.cyclonedxBom

Then I've also configured it to publish the BOMs to our Nexus:

artifact(project.tasks.cyclonedxBom.destination.get().toString() + "/" + project.tasks.cyclonedxBom.outputName.get() + ".xml") {
    classifier "cyclonedx"
    extension "xml"
}
artifact(project.tasks.cyclonedxBom.destination.get().toString() + "/" + project.tasks.cyclonedxBom.outputName.get() + ".json") {
    classifier "cyclonedx"
    extension "json"
}

With that, anytime anybody does a build locally or via Jenkins the BOMs are being generated and published alongside the JARs/WARs without needing to think about it. There's no additional stage or distinct job that handles it, its just an implicit part of building and publishing the project as usual.

[skhokhlov]

Feel free to reopen the issue if you are still having problems

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.