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

CycloneDx without maven plugin #157

Open
bhuvi11 opened this issue Nov 10, 2021 · 6 comments
Open

CycloneDx without maven plugin #157

bhuvi11 opened this issue Nov 10, 2021 · 6 comments
Labels
question Further information is requested

Comments

@bhuvi11
Copy link

bhuvi11 commented Nov 10, 2021

Hello Team,

How can i use cyclonedx to get the SBOM without adding to as part of POM.xml ?

@stevespringett
Copy link
Member

Any Maven plugin can be called without adding it to the pom using the syntax mvn plugin:goal -Dproperty=value

@stevespringett stevespringett added the question Further information is requested label Nov 10, 2021
@bhuvi11
Copy link
Author

bhuvi11 commented Nov 11, 2021

Hello @stevespringett ,

Thanks for your reply,
Do we have a CLI for cyclonedx that i can use to generate bom for all languages?
Currently i see a different implementation of cyclonedx for each language.
Does the current cyclonedx CLI generated bom? i see it analyses but does it create

My use case :
I need to generate bom for each application in CICD pipeline specific to the language using cyclonedx.
Is there an option as such?

@stevespringett
Copy link
Member

Yes, a CycloneDX CLI exists, however, its more of a utility.

All-in-one tools simply do not work well. OWASP tried that back in 2012/2013 and the results were not good. Each build system has a slightly different lifecycle and dependency resolution mechanism. In order to get accurate inventory and dependency graphs, SBOM creation needs to be part of that lifecycle. With a standalone tool that supported all languages, you'd have to replicate the dependency resolution algorithms for every ecosystem but in many cases still would not be able to produce an accurate inventory. Even native tools such as mvn dependency:tree provide inaccurate results by design.

For Java apps, I would highly recommend inclusion of CycloneDX Maven plugin in a corporate pom. If your org doesn't have one, now is the time to do it. A single change would provide automatic SBOM capabilities across all Java apps.

For all others, I would simply rely on build metadata to determine what language(s) are used and invoke the correct CycloneDX build plugin. Jenkins has the concept of libraries which are reusable blocks of code that you can inject into a pipeline. Libraries contain logic and that logic could branch to include the various CycloneDX implementations. Once the library is built up, its a simple matter of including it as a build step - simple. I think SAP has a Jenkins library for CycloneDX somewhere on GitHub you may want to look for. Other build servers have similar concepts. Try to find a way to reuse the logic in a way that will 1) produce accurate inventory, and 2) allow you to scale the creation of SBOMs across all your builds.

@bhuvi11
Copy link
Author

bhuvi11 commented Nov 11, 2021

Hello @stevespringett ,

Thanks a lot for this detailed explanation.

@sschuberth
Copy link
Contributor

Do we have a CLI for cyclonedx that i can use to generate bom for all languages?

FYI @bhuvi11, the ORT analyzer in combination with the reporter aims to do that, besides other things.

Each build system has a slightly different lifecycle and dependency resolution mechanism. In order to get accurate inventory and dependency graphs, SBOM creation needs to be part of that lifecycle. With a standalone tool that supported all languages, you'd have to replicate the dependency resolution algorithms for every ecosystem

FYI @stevespringett, luckily, you do not need to replicate the dependency resolution algorithms, and it's a strong design goal of ORT not to do so, both for correctness and to not reinvent the wheel. Instead, we programmatically call the dependency resolution of the respective build system (which might be quite challenging to do depending on the build system).

Even native tools such as mvn dependency:tree provide inaccurate results by design.

I'd be curious what exactly you're referring to here. Can you elaborate @stevespringett?

@stevespringett
Copy link
Member

I'd be curious what exactly you're referring to here. Can you elaborate?

CycloneDX/cyclonedx-maven-plugin#116

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants