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

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

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.com@lists.openembedded.org> wrote:
> > The patch from Andrej tries to solves a real issue: The CVE checker
> > distinguishes between two types of patches. Ignored (= not applicable)
> > and patched. Patching is only supported by adding a real patch file to
> > the SRC_URI. However, there are other ways a patch can be implemented.
> > For example, a recipe that uses the git fetcher would update the git
> > hash to a commit that contains a fix instead of applying a patch file
> > to the recipe.
> > 
> > But I fully agree that the comment (originally suggested by me when
> > Andrej and I were discussing the solution) is bad. Maybe it should read
> > as follows:
> > 
> > Normally, a CVE is treated as patched when a patch with the name of the
> > CVE is applied. CVE_CHECK_PATCHED allows to extend the list of patched
> > CVEs without adding a patch file to SRC_URI.
> > 
> > Regarding the SBOM: It is important for customers that the CVEs of a
> > product with SBOM can be correctly identified as repaired or as
> > ignored. However, I'm not sure if the SBOM part is properly addressed
> > by the patch. The create-spdx.bbclass uses the function
> > oe.cve_check.get_patched_cves(d) which should probably handle the new
> > variable as well. We will check that and come up with a V2.
> 
> So I’d suggest we deprecate CVE_CHECK_IGNORE and add a new, more flexible, variable instead.

Flexible but usefull and with clear definitions and checks which make
sure that only those definitions are used.

> How about a CVE_STATUS, which doesn’t have a direct value but has flags for each CVE:
> 
> # We moved to a git SHA that incorporates the fix
> CVE_STATUS[CVE-1234–0001] = “Patched”
> 
> # We disabled frobnicate
> CVE_STATUS[CVE-1234-0002] = “Patched”
> 
> # This is Windows-specific
> CVE_STATUS[CVE-1234-0003” = “Not Applicable”
> 
> I’m not sure of the exact list of values the flags should accept beyond “patched” and “not applicable”. There probably does need to be a “reviewed and don’t consider this a problem” which feels like ‘ignored’ but I’m not a fan of that precise word.

Sounds ok as long as the output reports as easy to read as now.

> 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.

Debian has a bit more complex state for each CVE (and also non-CVE
security issues) which relates to package and distro versions.
I did not find clear definition of the states but at least
https://security-tracker.debian.org/tracker/data/json has the raw data
available.

Ubuntu seems to follow Debian a bit but then also adds more complex
states in the (at least) public database at
https://ubuntu.com/security/cves?q=CVE-2023-26117&package=&priority=&version=&status=

I think the data coming from CVE checker needs to serve the needs of the
distro maintainers so that their life is easier. SPDX and SBOM are
supposed to help but I'm afraid that they don't unless they actually
help with the maintenance and start to solve the problems there.

I'm used to the CVE checker ignore list (previously whitelist) and know
how to use it. Wether the data comes per CVE or as lists for each of the
state as variables is a small detail, as long as the generated report is
readable.

Cheers,

-Mikko