> For the real deal, would we publish SBOMs next to the JARs, for example in https://dist.apache.org/repos/dist/release/commons/io/binaries/ ? With files names that have a version or not?
I think it's a good idea, eventually when SBOM generation is "popular" in ASF and when tooling to produce SBOM will be tested and easy to apply by all our projects, I think we should likely propose a change to the release process to not only have packages, signatures and checksums but also (ideally signed) SBOMs. But there is one watchout before we do it (and how we do it) - and we have to learn it over time. Essentially our "release" repo is "write-once-only" (or so I think about it). Once we publish something as a package, signature, checksum file - should never change, The whole SBOM generation is relatively new, and the tools that generate it change, also SBOM standards will evolve. There is a big difference between .tar.gz source package and .sbom - because essentially, SBOM might not be treated (at least currently I think) as "immutable". Not because we will change sources for example, but because tools to generate SBOMS will be better over time. SBOMS contain a lot of information - for example information about licences. And some of that information is wrong today (due to imperfectness of the tools) - but this might (And will) change in the future. A good example - initial SBOMS generated by Airflow had like 50% of licence information for all Python dependencies, but when I generate them now - they are 100% and pretty correct. Other stuff in SBOMS (who are the authors, what's the organisation owning it etc.) - this all might change without changing the software that was used to generate the SBOM with (not even single package version changed - simply metadata and tooling used to produce SBOMS might change). For example - I have tooling that allows to regenerate and re-publish Airflow SBOMS for all historical versions - and publish them via our web page: https://airflow.apache.org/docs/apache-airflow/stable/security/sbom.html. And this and next week I am planning to regenerate and re-publish all of them with the latest version of cdxgen (that's the tool we use to generate our CycloneDX SBOMS). So before we propose where and how to store it, I think we need to decide how we approach the lifecycle of SBOMS, and then find the right place for them. J. On Tue, Oct 22, 2024 at 12:06 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi all, > > For the real deal, would we publish SBOMs next to the JARs, for example in > https://dist.apache.org/repos/dist/release/commons/io/binaries/ ? With > files names that have a version or not? > > Gary > > On Tue, Oct 22, 2024, 5:10 AM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Hi Arnout, > > > > 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. As > you > > > can see there's already a fair number of ASF projects publishing SBOMs, > > and > > > I'm sure I've missed some - LMK. > > > > Nice job! > > > > 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? > > > > Piotr > > > > [1] > > > https://github.com/CycloneDX/cyclonedx-maven-plugin?tab=readme-ov-file#goals > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > security-discuss-unsubscr...@community.apache.org > > For additional commands, e-mail: > > security-discuss-h...@community.apache.org > > > > >
