This semi-concerns me in the sense that we could come up with a convention appropriate for the Java ecosystem, like publishing in a Maven repository only to have the perfect be the enemy of the good because we are looking for a one-size-fits-all solution. The fact that we use a Maven repository instead of something else tells me we should be looking for a best-fit solution per technology stack.
Gary On Wed, Sep 6, 2023, 4:38 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > IMO, The SBOM should be stored next to the jar (or whatever file you want > to track), for example: > > This is fine for the Java world (Maven)- but we have no similar standard > (yet) for Python / PyPI / Conda - even less for software that published > source code for compiled C/Rust/etc librarie and many other > languages/frameworks.. So I am talking about "language neutral", "ASF > standard" way of publishing it. Inevitably, all of the distribution > platforms (PyPI/Conda) will get it in a way specific to the platform but in > some cases (such us when you just publish sources for others to compile in > C/RUST/whatever) having a "language/platform" agnostic way that would be > "ASF common" **might** be quite a nice way to respond to some of the "is > the whole ASF following the security processes and publishes SBOMS" > question. > > J, > > > J, > > > On Wed, Sep 6, 2023 at 10:28 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > IMO, The SBOM should be stored next to the jar (or whatever file you want > > to track), for example: > > https://repo1.maven.org/maven2/org/apache/commons/commons-dbcp2/2.10.0/ > > > > Gary > > > > On Wed, Sep 6, 2023, 4:19 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > I think guac is a great tool but it solves a slightly different > problem. > > > > > > I think the problem I see that could be potentially solved by DOAP is: > > > > > > "Where do I find SBOM and VEX for Apache Project XYZ version A.B.C". > > > > > > I think Guac is cool - but (unless I misunderstood it) it solves > another > > > problem (somewhat next step): > > > > > > "Having SBOM and VEX already gathered for all the components, how do I > > get > > > actionable insights about it". > > > > > > J. > > > > > > > > > > > > > > > On Wed, Sep 6, 2023 at 3:24 PM Brandon Lum <l...@google.com.invalid> > > > wrote: > > > > > >> GUAC (https://github.com/guacsec/guac) is able to ingest both SBOMs > and > > >> VEX > > >> statements* and provides search and linking between them based on > > package > > >> names / hashes. Would this be something that could help solve the > > >> discoverability and linking issue? If it is helpful perhaps the GUAC > > >> community can help provide some helpful tooling for the use case. > > >> > > >> *: Currently supports CSAF, and there are open PRs for CDX and OpenVEX > > >> support. > > >> > > >> On Wed, Sep 6, 2023 at 7:23 AM Gary Gregory <garydgreg...@gmail.com> > > >> wrote: > > >> > > >> > FWIW: Apache Commons has been producing SBOMs using both CycloneDX > and > > >> > SPDX maven plugins until some kind of standard prevails. > > >> > > > >> > Gary > > >> > > > >> > On Wed, Sep 6, 2023 at 4:45 AM Jarek Potiuk <ja...@potiuk.com> > wrote: > > >> > > > > >> > > Hello board/security folks, > > >> > > > > >> > > [I have not added dev@community as this is a public list] - just > > >> wanted > > >> > to > > >> > > make sure not to mix private/public lists] > > >> > > > > >> > > TL;DR: I have an idea on how to strengthen DOAPs and make it all > but > > >> > > "mandatory" at some point in the future. This all by tying it with > > the > > >> > > SBOM/security needs coming from the CRA(p) - like regulations. > This > > >> is a > > >> > > mid/long term but might be worth thinking if this is a good idea > and > > >> > > setting the direction for the future. > > >> > > > > >> > > Context: > > >> > > > > >> > > Recently the discussion started on DOAPs and how many projects do > > not > > >> > have > > >> > > them. One of them was (not any more as of yesterday) Airflow, but > I > > >> think > > >> > > there are justified doubts raised about how valuable DOAPs are if > we > > >> have > > >> > > so many project listings. I think we have a good way to fix it in > > the > > >> > > mid/long term. And possibly we have a way to fix it in the > mid/long > > >> term. > > >> > > > > >> > > Problem: > > >> > > > > >> > > We have a small team in Airflow working (and in the next 2-3 > months > > we > > >> > plan > > >> > > to complete it) on producing a complete set of SBOMs (based on > > >> CycloneDX > > >> > > standard) for all th 90+ projects we publish. This is all going to > > be > > >> > > automated and I have working prototypes for it - but we want to > make > > >> it > > >> > > more complete - including publishing information for images we > have > > >> and > > >> > in > > >> > > the future make it possible to publish VEX information (which is > the > > >> next > > >> > > step after SBOMS). > > >> > > > > >> > > However, one of the problems I have is that currently - there is > no > > >> > > standard way to say "where to look for SBOMs" for each project. > DOAP > > >> > seems > > >> > > to be a perfect way to do so. It's both machine readable and > > viewable > > >> at > > >> > > the http://projects.apache.or > > >> > > > > >> > > Seems like a perfect vehicle for "link to SBOM/VEX". And might > > become > > >> a > > >> > > more "official" and "structured" way by the ASF to publish > security > > >> > > information that sooner or later will be required by CRA(p) kind > of > > >> > > regulations. > > >> > > > > >> > > Proposal: > > >> > > > > >> > > My idea is to add the "SBOM" link types of DOAPs and make a > timeline > > >> for > > >> > > them to be "mandatory" at some point in time and have the security > > >> team > > >> > of > > >> > > the ASF monitor that and expect them to be published (the > monitoring > > >> can > > >> > be > > >> > > easily automated). > > >> > > > > >> > > I think doing that this way has some good properties: > > >> > > > > >> > > a) provides value for the projects (currently there is no > 'standard' > > >> for > > >> > > SBOM/VEX links) > > >> > > b) will address a real need the ASF has (or will have in the > future) > > >> > > c) will provide a justification why PMC should spend their time > and > > >> > effort > > >> > > on it > > >> > > d) we will have a chance to define ASF standard on how we publish > > >> > SBOM/VEX > > >> > > that will be "programming-language-agnostic" and maybe we can > > >> contribute > > >> > in > > >> > > the future to create a "global" standard. > > >> > > > > >> > > > > >> > > J. > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: > > >> security-discuss-unsubscr...@community.apache.org > > >> > For additional commands, e-mail: > > >> > security-discuss-h...@community.apache.org > > >> > > > >> > > > >> > > > > > >
