On Tue, Oct 22, 2024 at 7:05 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> > Just as an FYI in case it's not know already: I'm sure this is not the > only initiative but at OWASP/CycloneDX we're working on a project for > distribution of SBOMs: > https://github.com/CycloneDX/transparency-exchange-api > > Lars, > > I love the logo of that project :). But does it mean that you are all high > on eucalyptus while working on it :) ? > This is a plushy opportunity if I've ever seen one ;-) Gary > > J. > > > On Tue, Oct 22, 2024 at 12:58 PM Arnout Engelen <enge...@apache.org> > wrote: > > > On Tue, Oct 22, 2024 at 11:09 AM Piotr P. Karwasz > > <piotr.karw...@gmail.com> wrote: > > > On Mon, 21 Oct 2024 at 15:34, Arnout Engelen <enge...@apache.org> > wrote: > > > > During a recent discussion elsewhere we figured it might be nice to > > collect > > > > the SBOMs currently published by Apache projects in a single place to > > > > facilitate experimentation. I've put those at > > > > https://github.com/apache/security-site/tree/sboms/sboms for now. > > > > > > What kind of SBOMs should we upload to the repo and how should we > > > structure the folders? > > > > > > In Log4j (and probably other library Java projects), we have two kinds > > > of SBOMs, depending on the CycloneDX Maven Plugin goal we use[1]: > > > > > > * "normal" source SBOMs: these are generated for each binary component > > > (e.g. `log4j-api` or `log4j-core`) and list all the dependencies of > > > those components. > > > * "aggregate" SBOMs: these are basically a composition of all the > > > "normal" source SBOMs that are released together. The "dependencies" > > > of the main component in the aggregate SBOM are the different Maven > > > modules of a multi-module Maven build. > > > > > > I think that the second kind is what we want, since they give all the > > > information in one place. Each PMC could structure its folders > > > according to the structure adopted on `downloads.apache.org`. E.g. for > > > Logging services I could upload the SBOMs as: > > > > > > * logging/log4j/2.24.1/apache-log4j-2.24.1-cyclonedx.xml > > > * logging/log4j-scala/13.1.0/apache-log4j-scala-13.1.0-cyclonedx.xml > > > * etc. > > > > > > What do you think? > > > > I think the primary use case for SBOMs is "I have this artifact and > > want to know things about it". From that perspective the per-artifact > > SBOMs seem more meaningful than aggregated ones. > > > > For released artifacts, I don't think you should have to upload them > > to the repo at all: the 'source of truth' is your upload to Maven > > Central (and/or in the future to dist.apache.org), we can then pull > > them to the convenience sbom collection from there. It might be > > interesting to publish 'snapshot' SBOMs directly to the repo, though? > > Or perhaps we should get those from > > https://repository.apache.org/content/groups/snapshots . > > > > -- > > Arnout Engelen > > ASF Security Response > > Apache Pekko PMC member, ASF Member > > NixOS Committer > > Independent Open Source consultant > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > security-discuss-unsubscr...@community.apache.org > > For additional commands, e-mail: > > security-discuss-h...@community.apache.org > > > > >
