Matt, I am a member of a few other open source Java libs and I am interested in what you come up with to follow your lead and add SBOM to them as well. The more pervasive we can make it the better for the whole Java ecosystem overall!
Melloware @melloware on GitHub > On Jul 17, 2022, at 12:16 PM, Matt Juntunen <matt.a.juntu...@gmail.com> wrote: > > Sounds good. I've moved the discussion to the > security-disc...@community.apache.org mailist list [1]. > > Regards, > Matt J > > [1] https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy > >> On Sun, Jul 17, 2022 at 11:11 AM Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> On Sun, Jul 17, 2022 at 11:00 AM sebb <seb...@gmail.com> wrote: >>> >>> On Sun, 17 Jul 2022 at 15:45, Matt Juntunen <matt.a.juntu...@gmail.com> >>> wrote: >>>> >>>> Hello all, >>>> >>>> Steve Springett recently created a PR [1] for commons-parent that >>>> introduces the generation of software bill of materials (SBOM) >>>> artifacts into the build process. First of all, thank you, Steve. >>>> Secondly, I believe this is an important topic that should be >>>> addressed by our community. SBOMs contain metadata that can be used in >>>> application security contexts and software supply chain analysis. They >>>> seem to be becoming increasingly important as the software industry >>>> places a greater emphasis on cybersecurity. I have a small amount of >>>> experience with these types of files from my day job. My team will >>>> soon begin generating them for all of our projects in order to allow >>>> automated tools to better track CVEs and report to our customers on >>>> the security of our applications. The questions I believe we need to >>>> answer as a community are: >>>> >>>> 1. Do we want to include SBOMs in our Maven build artifacts? >>>> 2. If so, what format do we want to use? >>>> >>>> In regard to the first question, I believe that we would need a good >>>> reason to *not* include these (or similar) artifacts. It's a simple >>>> service we can provide to help our users maintain good cybersecurity >>>> practices. As the provider of a number of hugely popular open-source >>>> libraries, I would love to see us take the lead on ensuring the >>>> security of the Java ecosystem. >>>> >>>> For question two, there are a few SBOM standards out there, notably >>>> SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I >>>> am not well versed in the exact differences between the formats, but >>>> CycloneDX seems to have better Java support and a large number of >>>> useful tools, such as the Maven plugin used in Steve's PR. >>>> >>>> If we can agree on answers to the two questions above, then we can >>>> move forward and start discussing details. Thank you all for your >>>> time. >>> >>> SBOMs presumably apply to all ASF software, so it seems to me it would >>> be sensible to address this at ASF level. >>> It would be silly for each project to generate the data differently, >>> even if only slightly. >>> Once a format is settled upon, I would expect it to be implemented via >>> the Apache POM, rather than by every Maven Java project. >>> >>> I think the mailing list for this is probably >>> security-disc...@community.apache.org: >>> https://lists.apache.org/list.html?security-disc...@community.apache.org >> >> I agree with Sebb. >> >> Note that the CycloneDX plugin does not work correctly for >> multi-module Maven projects. See the PR for my results. >> >> Gary >> >>> >>>> Regards, >>>> Matt J >>>> >>>> [1] https://github.com/apache/commons-parent/pull/122 >>>> [2] https://spdx.dev/ >>>> [3] https://cyclonedx.org/ >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
