Hi Gary, sure, but it is specific to our use-case and to my experience. I understand some of this is subjective and I'm not looking to start a fight :)
I found the CycloneDX community to be much easier to engage with. There is a Slack, I asked a bunch of questions and got help immediately. For SPDX I only found ways to "join" which led me to some Member Enrollment thing....I didn't look further. Then the SPDX standard is pretty "old" and hasn't seen much movement while there have been two or three CycloneDX releases with improvements since I started looking at it beginning of 2023. The community for SPDX seems to be much smaller and it seemed much harder to influence the spec. With CycloneDX there is a repo where I can just open issues - https://github.com/CycloneDX/specification/ - https://github.com/CycloneDX/specification/issues/273 - https://github.com/CycloneDX/specification/issues/349 We need to generate SBOMs for Rust and CycloneDX has a list of tools they maintain themselves, amongst them a Rust SBOM generator. For SPDX I couldn't find any such thing. These are only the non-specification related reasons. I looked at both formats, they both seemed to (for a newcomer like I was) do more or less the same in the "core" so I picked the one that was easier in all regards for me. In addition CycloneDX supports more use-cases for the future. With the upcoming standardization of CycloneDX 1.6 by Ecma the argument of "but SPDX is standardized" should go away as well. We have since applied for and won (two times) money from the Sovereign Tech Fund to work on the Rust SBOM generator and more: https://www.sovereigntechfund.de/tech/rusty-sboms I really don't care too much about the format, I'd love it if one were to "win" and the other one were to go away. I can switch format if need be, the current situation is annoying. I hope it helps a bit, I can elaborate if needed. Cheers, Lars On Mon, Feb 19, 2024 at 4:11 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > Thanks for the feedback Lars. > > Can you share a bit more as to what guided you to choose CycloneDX over SPDX? > > TY, > Gary > > On Mon, Feb 19, 2024 at 2:48 PM Lars Francke <lars.fran...@gmail.com> wrote: > > > > As far as I know SPDX is not supported in DependencyTrack anymore but > > I might be wrong: > > - https://github.com/DependencyTrack/dependency-track/issues/1746 > > - https://github.com/spdx/cdx2spdx/issues/35#issuecomment-1743546743 > > - > > https://github.com/DependencyTrack/dependency-track/issues/1746#issuecomment-1942308273 > > > > I may be biased but I consider CycloneDX to be "winning" in terms of > > mind-share and development speed. > > And I'm only biased after initially evaluating both formats for our > > own use and settling on CycloneDX after said evaluation. > > > > On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > > > > > TY Arnout. > > > > > > I was able to auth in and see Apache Commons, very cool. > > > > > > I see a column that says "BOM Foramt" and lists "CycloneDX" for all > > > entries. > > > > > > Can the view deal with components that have BOTH CDX and SPDX like > > > Commons components do? > > > > > > Do you have any insight as to which format is winning or what other > > > formats we should consider supporting? > > > > > > What is the refresh rate? For example, I just pushed out (last night > > > GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view > > > still shows 1.25.0. > > > > > > Do I have to upload new BOMs for existing listings? > > > > > > If not, will the view for 1.25.0 currently on display be updated to > > > show the CVEs automatically? > > > > > > TY for your hard work! :-) > > > Gary > > > > > > On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <enge...@apache.org> wrote: > > > > > > > > Hello security-discuss, > > > > > > > > More and more Apache projects are producing SBOMs as part of their > > > > release > > > > process. Challenges producing and consuming SBOMs are definitely > > > > on-topic > > > > for this list, and ideally we can consolidate that knowledge on the > > > > wiki[0] > > > > > > > > If you're interested, we've set up a DependencyTrack[1] instance > > > > collecting > > > > SBOMs for various Apache projects at [2]. You can log in with your > > > > Apache > > > > id. Note that this is all experimental, we may drop all data at any > > > > time ;). > > > > > > > > If you know of any other projects to include, would like help setting up > > > > SBOM publishing for your project, contribute 'nightly' SBOM snapshots, > > > > or > > > > discuss other things SBOM, I'm all ears! > > > > > > > > > > > > Kind regards, > > > > > > > > Arnout > > > > > > > > [0]: > > > > https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM > > > > [1]: https://dependencytrack.org/ > > > > [2]: https://security-tools-ec2-va.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > > > For additional commands, e-mail: > > > security-discuss-h...@community.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > > For additional commands, e-mail: security-discuss-h...@community.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: security-discuss-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
