Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs

["Valek, Andrej" <andrej.valek@siemens.com>]

Hello Richard,

Could you please take a look on the latest revision a make a decision there?
There are still bunch of unclear statements. So please make a final design and
we will try to implement it.

Thank you,
Andrej

On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Fri, May 19, 2023 at 03:11:57PM +0200, Marta Rybczynska wrote:
> > I'm missing a status to cover the situation when the NVD (or any other
> > database) has an incorrect entry. We have quite many of those. This might
> > be a temporary situation, but not always.
> > 
> > SPDX (the 3.0 draft) has some other possible reasons
> > https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md
> > What looks like interesting ideas are:
> > * "Can't fix" / "Will not fix"
> > * "Not applicable" (SPDX language: Ineffective) when the code is not used
> > * "Invalid match" (this is our NVD mismatch case)
> > * "Mitigated" measures taken so that it cannot be exploited
> > * "Workarounded"
> 
> To me the SPDX details don't seem very usable when actually maintaining
> a linux distro for a long time. Anyone from major Linux distro
> stable/security teams participating in the work?
> 
> So I'd rather compare to Debian security tracker CVE status data and ask
> what our LTS and master branch maintainers and those in the community
> who maintain yocto based SW stacks need. Do the maintainers want to read
> SPDX output, for example? What common statuses do the maintainers want to
> encode for each CVE?
> 
> Debian security tracker https://security-team.debian.org/security_tracker.html
> shows states:
> 
>  * vulnerable: binary package with specified version in their distro
>    version is vulnerable to the issue
> 
>  * fixed: binary package in their distro version has fixed the issue
> 
>  * undetermined: it is not yet clear if the issue affects Debian and
>    their version of the packages
> 
> And "vulnerable" has sub states:
> 
>  * ignored: the issue does not impact Debian packages
> 
>  * postponed: no security patch updates will be provided, e.g. such a
>    minor issue that update will happen for example via normal package
>    version updates to next stable version
> 
> There are a lot of additional "standards" and sub states when looking at
> CVE data in the tracker (info not public, no upstream fix available, not
> supported configuration etc), but those major high level states are enough.
> And then there are security relevant bugs without CVEs.
> 
> I've been happy with "Unpatched", "Patched" and "Ignored" states for
> each CVE detected by cve-check.bbclass. There could be a few more sub
> stated to "Ignored" and the "Patched" state should better reflect reality,
> which this patch set helps. But I'm happy with that.
> 
> I'm not so happy with the SPDX states names and meanings.
> 
> Cheers,
> 
> -Mikko