I think a suggestion could be to start with Java and encourage our communities to store SBOMs in the Maven repository like Commons has started doing. This might get us partway to at least one kind of solution. When a storage standard emerges, then we can shift to that.
Gary On Wed, Sep 6, 2023, 5:25 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > should be looking for a best-fit solution per technology stack. > > Sure. We could. > > But also we could look for a solution of when regulators come to the > Foundation and ask "are all your projects publishing SBOMs and VEX"? If so > - how? > If that question come to the Foundation from the regulators (say 2 years > from now), then there are two ways to provide answer: > > Answer 1) Feel free to go and check with all the 300 hundreds of projects > which technology stack they are using and check individually if they are > publishing SBOM or VAX > Answer 2) Yeah - look here, there is an inventory of SBOMS all our > projects have > > Of course it might be that I am anticipating all the regulations that are > in-progress wrongly, but I believe, sooner or later, the regulators. will > come and ask this question, I am not saying we have to do it or that we > have to do it now. I am just afraid we should be prepared for the world > where production of software gets quite a bit more regulated and > requirements from the regulators need to be fulfilled, This is just a > feeling I have after following all the discussions in public-affairs > discussions. > > Of course - we can also take the approach "let's wait and see and we will > react when we are asked". But similarly as preventing disease is far, far > cheaper than curing it after it happens, we might proactively start > thinking of it. > > J. > > > On Wed, Sep 6, 2023 at 11:07 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > >> 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 >> > > >> > >> > > >> > >> > > >> >> > > > >> > > >> > >> >
