CVE Triage

From Yocto Project
Revision as of 16:22, 19 April 2023 by RossBurton (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Rough notes on the CVE triage process, to be expanded:

Weekly CVE reports to go yocto-security@lists.yoctoproject.org and openembedded-core@lists.openembedded.org.

Trends available at https://autobuilder.yocto.io/pub/non-release/patchmetrics/, also links to the latest report eg https://autobuilder.yocto.io/pub/non-release/patchmetrics/cve-status-master.txt.

The reports list the found CPE identifiers and links to the NIST page.


Triage Process

For each CVE, read the summary and description.

Is this even relevant? Some CVEs are false-positives, eg may be specific to Windows. If the CVE is inappropriate add to CVE_CHECK_IGNORE. For example CVE-2008-1033 only applies to the CUPS that is part of macOS, so the cups recipe has:

# Issue only applies to MacOS
CVE_CHECK_IGNORE += "CVE-2008-1033"

Look at the references. Follow any links to bugs or commits. Has this CVE been fixed upstream? Has that fix made it into a release?

If the CVE has been released then the CPE information (the list of vulnerable releases) may need updating: email cpe_dictionary@nist.gov explaining what release has the fix and why, and they'll update the page. If in your research you have better references (such as the commit which fixed the issue) then submit an Update References request to https://cveform.mitre.org.

If it hasn't been released then can the fix be backported easily? Best to grab the git repo and cherry-pick the commit to the release tag to avoid fuzz. Add the patch to the recipe with your Signed-off-by, a CVE: tag, and Upstream-Status: Backport.