Hi, On Wed, May 10, 2023 at 09:37:13AM +1200, Douglas Royds wrote: > On 9/05/23 9:32 pm, Mikko Rapeli wrote: > > On Tue, May 09, 2023 at 09:02:59AM +0000, Ross Burton wrote: > > > On 8 May 2023, at 09:57, Adrian Freihofer via > > > lists.openembedded.org<adrian.freihofer=gmail....@lists.openembedded.org> > > > wrote: > > > Is there any defined language that we can simply adopt? > > Since a lot of people talk about SPDX solving these issues would be nice > > to know how that is going to work. I can't parse > > https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k17-linking-to-a-code-fix-for-a-security-issue > > and figure out how to mark a CVE issue which has been ignored after > > analysis. > > > Perhaps this? > > https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k16-linking-to-a-vulnerability-disclosure-document > > To communicate that a package is not vulnerable to a specific > vulnerability it is recommended to reference a web page indicating > why given vulnerabilities are not applicable. > > |"externalRefs" : [ { "referenceCategory" : "SECURITY", > "referenceLocator" : > "https://example.com/product-x/security-info.html";, "referenceType" > : "advisory" } ] |
Thanks but IMO this does not encode the information that analysis has been done and the issue can safely be ignored, but I'm not an SPDX expert, and frankly I should not need to be. In recipes CVE_CHECK_IGNORE variable the ignore list is clear, obvious, and there is usually a comment or a commit message explaining why. And the reports generated by cve-check.bbclass for recipes and images show that the CVE issue can be ignored and maintainer should check the CVEs with "Unpatched" status instead. Would be nice for these tools to firstly support yocto upstream stable and LTS maintainers work in detecting and fixing CVE issues, and secondly support maintaining CVE security issue/patching status of older releases with complex layer configurations, when anyone has to use an old release due to BSP etc dependencies (fact of life which IMO should not be completely ignored). I have backported the cve-check.bbclass and other CVE management related patches to really old yocto releases and these frankly saved the product from being the usual embedded SW security nightmare to actually have only a few known minor known CVE patching issues when shipping to customers. Older versions of SPDX standard and open source license checks helped to identify embedded open source SW but did not really help in the yocto operating system/rootfs side CVE security patching. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181102): https://lists.openembedded.org/g/openembedded-core/message/181102 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
