> 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.
I think eventually and in theory - yes. And one of my favourite sayings "In theory, practice is the same as theory, but in practice, it's not" :) . I am not sure if we reached that point yet that theory == practice :). I will definitely be keeping an eye on it from the Python/Airflow/CDXGen point of view. Every time I produce new SBOM "snapshot" I do a quick comparison to see what changed - since the time I generated it last time (and every time I did it so far, I see new/corrected things with newer cdxgen, and I even asked the cdxgen author (and got it done) to introduce a few fixes. J. On Tue, Oct 22, 2024 at 1:22 PM Arnout Engelen <enge...@apache.org> wrote: > 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 > >
