Hi Richard, Thank you for acknowledgement on my proposal. Please consider my additional input for VEX standard.
There is total four main VEX standard status: - Fixed - Affected - Not Affected - Under Investigation Out for 4 standard we can adopt Fixed and Not affected status for CVE fixing. As these two statuses will never get changed for specific package and CVE. Regarding the CVE status of community and VEX standard, we can map like following: Existing Status | VEX adoption ------------------------------------------- Patched | Fixed Ignore | Not Affected Not required | Not Affected Remaining two statuses Affected and Under investigation would be changed with time as following: * Under Investigation: - When any new CVE is reported against any package then by default it would go with "under investigation" status - Until we make the final status like fixed/not affected/affected status after our final investigation on specific CVE. * Affected: - Regarding affected status it would be temporary status until we find the actual fix for the CVE. - Once we have a fix the CVE then status would be as fixed/not affected which we can input to our recipe. Thanks, Sanjay -----Original Message----- From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Richard Purdie Sent: Saturday, June 3, 2023 2:57 AM To: adrian.freiho...@gmail.com; Valek, Andrej <andrej.va...@siemens.com> Cc: rybczyn...@gmail.com; openembedded-core@lists.openembedded.org; mikko.rap...@linaro.org; Marko, Peter <peter.ma...@siemens.com>; Sanjaykumar kantibhai Chitroda -X (schitrod - E-INFO CHIPS INC at Cisco) <schit...@cisco.com> Subject: Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs On Fri, 2023-06-02 at 23:10 +0200, adrian.freiho...@gmail.com wrote: > I like the VEX proposal from Sanjay. > > - It is a standard that can be supported by many tools and requested > by customers. One use case I see is where a vendor sells a product > with an SBOM. The customer can then match the open vulnerabilities to > the current state of the NIST database using a standard tool based on SBOM. > Aligning the categories to a standard would be helpful for this. > (Yocto's CVE check is great for Yocto, but cannot be used > independently of Yocto.) > - A minimum number of categories is defined. All details can be added > to the REASON variable. I think you could map some of the status items I proposed to VEX statuses but I'm not convinced it makes sense to go directly to that. Anything we don't have a status for is effectively "under investigation", anything we don't list is fixed or not affected and if we know something is affected, a fix would likely follow very quickly. The data set doesn't really fit what we're able to do or the wrkflows we can follow, even if it is what some product customers would want to know. Part of the issue is we're not the actual product here. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182356): https://lists.openembedded.org/g/openembedded-core/message/182356 Mute This Topic: https://lists.openembedded.org/mt/99007092/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
