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/. > > > 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. > > 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. > > The work needed to push CVE data into SPDX and SBOM is not worth it > and it's better to put > the saved effort into fixing the actual CVEs. Fixing the CVEs is one thing. But depending on the use case, it is also important to be able to document this. > If management wants reports, generate > them from cve-check.bbclass output, but note that CVE database is a > moving target too. Adding information about open CVEs to the SBOM would be a moving target and therefore a bad idea. But that was probably not the intention here. Much more reasonable is to provide a static SBOM which provides information about: - Installed packages and versions - CVE related patches for the packages - Additional information from CVE_STATUS_* variables (These use cases were also the motivation for adding this additional information) 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. > > 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. Adrian > > Cheers, > > -Mikko > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62071): https://lists.yoctoproject.org/g/yocto/message/62071 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] -=-=-=-=-=-=-=-=-=-=-=-
