On Sun, Sep 10, 2023 at 6:38 PM Hen <bay...@apache.org> wrote: > > So, I don't see a big reason for the ASF to require SBOMs currently. I like > that Commons and some others are experimenting, but I don't believe SBOMs > from us have much value. > > We are not a vendor the the US Government, so I don't foresee that their > procurement rules are going to affect us. They affect our users who sell to > the US government, and those users should be working out their own SBOMs > based on what actually goes into their products, and not pulling things > from us. I do foresee requests for attestations from us, which might mean > having SBOM-like materials to explain what was around for one of our > builds, but again that's more on the vendor than us. > > On the EU CRA side, I'm not convinced that that is going to require SBOMs > either. Or rather - the current liability direction make me feel that we > could end up saying "Here is our source, here is a convenience binary, you > can contact these recommended vendors to get an assured SBOM.". > > i.e. I don't think we should rush to making these mandatory. > > I think short term energy would be better spent on publishing security > advisories in a standard & findable format - which may relate to VEX or > maybe is its own thing.
Huge +1 to the above! Thanks, Roman. > > Hen > > On Wed, Sep 6, 2023 at 1:43 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > Hello security folks, > > > > <snip> > > > > > > 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
