On Tue, Oct 22, 2024 at 12:33 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > 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.
I much agree the tooling around SBOMs is still immature and we have a lot to learn collectively. That said, I do think SBOMs should be immutable 'in principle' (and definitely be tied to a particular version/artifact). If there's bugs in the SBOM, like with bugs in the code, we can fix those in the new version :). > 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). This is still cool 'in practice', of course - but I don't think we should _expect_ projects to go back and update SBOMs for already-released versions. > 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. Everything is still very much in flux (not just within Apache but generally), so I think all those different aspects will have to evolve in tandem - we can't really postpone figuring out how to build SBOMs until we have a final decision on how to distribute or use them - or vice-versa - as learnings from each of these will influence each other. Kind regards, Arnout > 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 > > > > > > > > -- 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
