>"Where do I find SBOM and VEX for Apache Project XYZ version A.B.C".
@Jared, Gotcha - so it's mainly a storage and discovery issue, I think I misunderstood the "linking" in this context. Yea in that case, probably not, but once that's done, we'd be happy to write a collector to start pulling in that metadata :). On Wed, Sep 6, 2023 at 7:31 PM Philippe Ombredanne <pombreda...@nexb.com> wrote: > Hi Jared! > This is an awesome idea. > > On Wed, Sep 6, 2023 at 1:42 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. > > I would warmly welcome something or anything that is a little bit more > structured that what we have today and as a client of this Apache data > I would love to help you there! If anything, the tools I publish may > be of some help. > > FWIW, I maintain tools that also collect data from Apache so I have > been suffering first hand from the difficulty to collect data from > Apache projects. > - PurlDB fetches project data and eventually indexes all the Apache > source and binaries. This is not for the faint of heart as you can see > here in [1] > - License and dependencies are further scanned in ScanCode toolkit [6] > and ScanCode.io [5]. This is pretty involved and messy and even though > the Apache community is generally thoroughly vetting code origin and > license, there be dragons for instance hidden in some published > uberjars. > > Since I have a vested interest in the outcome of your initiative, may > I suggest using a simple convention rather than or in addition to > links in DOAP? > For instance, simply releasing an SBOM side-by-side with a released > file would go a very long way. > Here > https://archive.apache.org/dist/httpd/binaries/win32/apache_1_3_6_win32.exe > could have a SBOM file published side-byside at > apache_1_3_6_win32.exe.cdx , the same way there a GPG detached > signature with a .asc extension at apache_1_3_6_win32.exe.asc. > > This would make the discovery a lesser issue. And the same would apply > to VEX documents (say either CSAF, CDX or OpenVEX or all of them). > You could still publish links in DOAP of course. > > Also wrt. VEX, another/complementary approach could be to publish > structured security advisories that downstream users can use to craft > their own VEX. > I co-maintain VulnerableCode that fetches the published > vulnerabilities from the few Apache projects that provide such data. > This is barely structured data and for instance I doubt anyone ever > tried to parse the Tomcat advisories before we did. See httpd [2], > kafka [3] and tomcat [4]. Some structure would help everyone and is > made ever more important because of the crappy CVEs that get published > without collaboration with the upstream projects. The Apache projects > are best qualified and should provide the ground truth on their own > bugs IMHO. > > [1] > https://github.com/nexB/purldb/blob/main/minecode/visitors/apache.py#L23 > [2] > https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/apache_httpd.py > [3] > https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/apache_kafka.py > [4] > https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/apache_tomcat.py > [5] https://github.com/nexB/scancode.io/ > [6] https://github.com/nexB/scancode-toolkit/ > > -- > Cordially > Philippe Ombredanne > > +1 650 799 0949 <(650)%20799-0949> | pombreda...@nexb.com > AboutCode - Open source for open source - https://www.aboutcode.org > VulnerableCode - the open code and open data vulnerability database - > https://github.com/nexb/vulnerablecode > ScanCode - scan your code, for origin/license/vulnerabilities, report > SBOMs - https://github.com/nexB/scancode-toolkit > https://github.com/nexB/scancode.io > package-url - the mostly universal SBOM identifier for packages - > https://github.com/package-url > DejaCode - What's in your code?! - http://www.dejacode.com > nexB Inc. - http://www.nexb.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > >
