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
Add CycloneDX SBOM generation #122
Conversation
Added CycloneDX SBOM generation. CycloneDX is a OWASP Bill of Materials standard purpose-built for cybersecurity use cases. It exceeds the minimum requirements necessary to comply with EO 14028.
Hello @stevespringett ,
|
Adding an sbom to our maven artifacts would be quite beneficial. They provide insight into software supply chains and can be used, among other things, to help locate vulnerabilities in downstream applications (see https://cyclonedx.org/use-cases/). We are going to begin using them in my day job as part of our cybersecurity requirements and having commons projects produce these as well would be great. As far as the example with commons-vfs goes, it seems like something might be wonky with the plugin on that project. For example, the plugin keeps generating and then replacing the generated sbom:
If you run it with commons-text, you'll see the |
I've tested with commons-lang and commons-collections, both of which are single module projects. I just tested with commons-vfs and it appears to work as expected. Commons VFS is a multi-module project. As a result, every module will have a dedicated bom in each modules target directory. If the commons project uses the Maven release plugin, then you can expect the CycloneDX BOMs to be attached as part of the release process and published to Maven Central. For example: This is really the ultimate goal: For every commons project to start publishing boms to Central upon release. As @darkma773r pointed out, SBOMs are used primarily for Cybersecurity use cases - but license and other use cases are possible. Tools exist that allow consumers to analyze SBOMs to identity potential risk. |
This feels like a buggy plugin ATM that duplicates the information already in the POM, so I would wait until we, as Apache, can either keep using just POMs or standardize on one format. Also MD5 and SHA1 are broken so it is ironic that they are included in a file used for security. |
A pom is not a bill of material but does contain a lot of the same information. It's not possible to standardize on poms for bill of material use cases. |
This seems like an important discussion that needs to happen on the dev mailing list. I'm going to send an email with the details there shortly. @stevespringett, if you are not already subscribed to the |
Here is the email thread: https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx |
Scratch that. Discussion has moved here: https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy |
Well if you ask for my opinion, I would say this need to be changed at least. First the pluginManagement part is OK, but don't change the build/plugins part. At least make a new profile for it, as we don't always wanna generate this sbom. |
Added CycloneDX SBOM generation. CycloneDX is a OWASP Bill of Materials standard purpose-built for cybersecurity use cases. It exceeds the minimum requirements necessary to comply with EO 14028.