Re: [yocto] CVE Scanners and Package Version
Hi Marta > > The discussion in this thread is in fact related to what we have in > sessions > about SRTools. Would you be willing to join? > I remember that the meetings were announced via the mailing lists. But I can no longer find them and they are not listed on https://www.yoctoproject.org/community/get-involved/#virtual-meetings. How can I participate? Thank you. Best regards, Adrian > Kind regards, > Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62133): https://lists.yoctoproject.org/g/yocto/message/62133 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
I will reply here to multiple issues raised in this thread. On Tue, Jan 2, 2024 at 10:46 PM Adrian Freihofer 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
Hello and thank you for the feedback so far, > The cve-check tooling can check which issues are present and which are fixed > in some way so that information is there. I guess our security department wants a standardized format for all product teams and not use individual tooling for each team (which can be very diverse in a big corp). They would like to quickly be able to answer which products are affected in case of another "log4j incident". It's not about reporting, but rather having a standardized format which can be processed automatically to deal with the ever increasing number of CVEs. > 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. That is a good point. It also depends on the build configuration whether a component is affected or not. I brought this up as a concern to the security department. > Our experts have also opted for CycloneDX. Is your CycloneDX generator > publicly available? We are still implementing it internally, but started by adapting the following: https://github.com/bgnetworks/meta-dependencytrack > 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) I also looked into this. The cycloneDX format supports pedigree information for each component, which can be used to add patch objects and link them to fixed CVE numbers (see https://cyclonedx.org/guides/sbom/OWASP_CycloneDX-SBOM-Guide-en.pdf on page 48 ff for an example). But this seem to be a lot of effort to implement and the CVE scanner must support this and the naming+version ambiguity still remains. Best regards, Fabian Hanke Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -- Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62080): https://lists.yoctoproject.org/g/yocto/message/62080 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
Hi, On Tue, Jan 02, 2024 at 10:46:21PM +0100, 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/. That's good, but implementation is then missing. The CVE variables are not exported currently. I worked around this by exporting all the recipe CVE variables into buildhistory so also non-cve-check builds would export the data without any links to CVE database, though this was rejected here in upstream. > > > 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. Additionally something must make sure that the SW product names will match CVE database, possinly many to many mapping, and the same for SW component version numbers so that they can be compared against info in the CVE database. But just exporting the CVE variables into build output would be a good idea to start with. > > 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. A customer or pentester should have a look at source code, SRC_URI to see if certain patches have been applied. These should be available even if yocto build system is not. And then there are the binaries and actually exploiting the holes in there. > > 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. This is true. Patches welcome. > > > > 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
Re: [yocto] CVE Scanners and Package Version
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
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). Note that SBOM is mostly used for documenting SW components and their licenses. Obvious but needs to be made clear. > 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). 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 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. 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. If management wants reports, generate them from cve-check.bbclass output, but note that CVE database is a moving target too. 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. Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62063): https://lists.yoctoproject.org/g/yocto/message/62063 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
Hello, I don't know if it will help, in our company, we modified cve-check.bbclass so it is linked to our JIRA. At first build, it creates a ticket for every active CVE. We analyse CVEs on JIRA and close tickets that are not relevant for our product. At next builds, modified cve-check.bbclass checks for each CVE if there is a corresponding JIRA ticket, and whitelist CVE if status is closed. Best regards, Vincent Le dim. 24 déc. 2023 à 10:24, Richard Purdie < richard.pur...@linuxfoundation.org> a écrit : > On Sat, 2023-12-23 at 02:47 -0800, fabian.hanke via lists.yoctoproject.org > wrote: > > 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). > > 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). > > > https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html#vulnerability-check-at-build-time > > The cve-check tooling can check which issues are present and which are > fixed in some way so that information is there. > > > 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? > > The data could also be written into our SPDX SBoM information, offhand > I'm not sure if it is already or not. > > > I hope this is the correct place to start a discussion (if not please > > point me to the correct place): > > Does anyone else also have the same problem with false feedback from > > CVE scanners? How do you deal with it? > > The project has been focused around the cve-check tooling and SPDX SBoM > generation. If you want to use that data we'd suggest you extract it > from those sources as the proejct iself doesn't want to try and > generate multiple different output formats. > > Cheers, > > Richard > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62033): https://lists.yoctoproject.org/g/yocto/message/62033 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
On Sat, 2023-12-23 at 02:47 -0800, fabian.hanke via lists.yoctoproject.org wrote: > 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). > 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). https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html#vulnerability-check-at-build-time The cve-check tooling can check which issues are present and which are fixed in some way so that information is there. > 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? The data could also be written into our SPDX SBoM information, offhand I'm not sure if it is already or not. > I hope this is the correct place to start a discussion (if not please > point me to the correct place): > Does anyone else also have the same problem with false feedback from > CVE scanners? How do you deal with it? The project has been focused around the cve-check tooling and SPDX SBoM generation. If you want to use that data we'd suggest you extract it from those sources as the proejct iself doesn't want to try and generate multiple different output formats. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62032): https://lists.yoctoproject.org/g/yocto/message/62032 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] CVE Scanners and Package Version
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). 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). 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? I hope this is the correct place to start a discussion (if not please point me to the correct place): Does anyone else also have the same problem with false feedback from CVE scanners? How do you deal with it? Best regards, Fabian Hanke -- Bosch Rexroth AG Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62031): https://lists.yoctoproject.org/g/yocto/message/62031 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] -=-=-=-=-=-=-=-=-=-=-=-
