I will reply here to multiple issues raised in this thread. On Tue, Jan 2, 2024 at 10:46 PM Adrian Freihofer <adrian.freiho...@gmail.com> wrote: > > On Tue, 2024-01-02 at 09:24 +0200, Mikko Rapeli wrote: > > Hi, > > > > On Sat, Dec 23, 2023 at 02:47:36AM -0800, fabian.hanke via > > lists.yoctoproject.org wrote: > > > Hello Yocto community, > > > > > > we must provide a SBOM for our Yocto based product which will then > > > be used for (internal) CVE scanning by the security department. > > > Generating the base document in cycloneDX format is fairly easy > > > (thanks to the nature of Yocto). > > Our experts have also opted for CycloneDX. Is your CycloneDX generator > publicly available? > > > > Note that SBOM is mostly used for documenting SW components and their > > licenses. > > Obvious but needs to be made clear. > > I don't think that's true. > A SBOM should probably also list the CVE patches and provide > information about fixed CVEs. > I'm not sure about SPDX, but CycloneDX also addresses this use case: > https://cyclonedx.org/capabilities/vex/. >
SPDX3 addresses this in a similar way as CycloneDX does. There's also the VEX way (like in OpenVEX) that is similar to both. The additional information that can/should be added is the "human" processing, for example stating that in *this configuration* the issues does not apply because XYZ. We have that partially in CVE_STATUS_* > > > > > > But we do not know how to include information about CVE patches for > > > each package in the document. Not providing these, will cause a lot > > > of “false” feedback on CVEs for specific versions which are already > > > patched (but version number did not change). > Yes, that's a real issue. > > > This problem was also mentioned a few days ago in the presentation > > > from David Reyna: https://youtu.be/PegU1G1bA80?t=1127. I like the > > > proposed solution of adding a vendor specific string to the package > > > version. But I'm still wondering: How would the CVE scanner vendor > > > know which CVEs are included in a yocto specific version and which > > > are not? > If the SBOM contains the information from CVE_STATUS_* variables and > the CVE scanner has access to the NIST database it should theoretically > work. As mentioned, the CVE information changes over time. The current SBOM specs allow to include it, but then this will require a periodic refresh. Personally I like more the approach of static SBOM plus a VEX-style file with the CVE sitation assessment for a given date. This allows also a possibility to have information WHO actually did that assessment. > > > > If the intention is to know CVE paching and analysis status of a > > product, then I'd use > > the yocto upstream tooling for this, cve-check.bbclass. SBOM and SPDX > > are tempting but not actually > > useful for CVE patching and analysis work, except when they show that > > a lot of old open source > > SW components are embedded into various binaries. > This works well from a developer's point of view, but not from an end > customer's or penetration tester's point of view. Many companies sell > products with a pre-installed Yocto-based firmware, but do not provide > the layers and bitbake with the firmware. It is likely that they will be in obligation to deliver that data in a few years' time frame. > > Such a SBOM would enable a user or a pen-tester to use a tool which > generates a CVE report from the SBOM and the current data from e.g. the > NIST database. This tool can run at any time and could be a generic > SBOM tool which is independent from Yocto. The NIST DB is dynamic, but > publicly available. The SBOM is static and provided with each firmware > release. > This kind of a work has been discussed already. If someone has funding available to make it happen, I will be interested to know about it. > > > > AFAIK, and I'd be happy to be proven wrong, SPDX and SBOM don't help > > matching SW component names > > and version strings so that comparison against CVE database > > information works. Only license names > > are standardized. > > I'm not sure what the current status is. But even if it's not > completely solved today, that doesn't mean it can't or shouldn't be > solved. The specifications are also open source. > The way to indicate that a given modified version has a fix for an issue is not toally solved today. Or, more precisely, it has multiple possible solutions. The discussion in this thread is in fact related to what we have in sessions about SRTools. Would you be willing to join? Kind regards, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62089): https://lists.yoctoproject.org/g/yocto/message/62089 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
