1
0
mirror of https://git.yoctoproject.org/poky synced 2026-05-08 05:09:24 +00:00

ref-manual: document CVE_STATUS and CVE_CHECK_STATUSMAP

Deprecate CVE_CHECK_IGNORE with CVE_STATUS

(From yocto-docs rev: 8b8054977f31e2d6090521a0102f066b6d563733)

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Andrej Valek
2023-07-20 09:31:30 +02:00
committed by Richard Purdie
parent db7217335a
commit e100e3e0b3
4 changed files with 42 additions and 14 deletions
+1 -2
View File
@@ -1253,8 +1253,7 @@ In the following example, ``lz4`` is a makefile-based package::
S = "${WORKDIR}/git"
# Fixed in r118, which is larger than the current version.
CVE_CHECK_IGNORE += "CVE-2014-4715"
CVE_STATUS[CVE-2014-4715] = "fixed-version: Fixed in r118, which is larger than the current version"
EXTRA_OEMAKE = "PREFIX=${prefix} CC='${CC}' CFLAGS='${CFLAGS}' DESTDIR=${D} LIBDIR=${libdir} INCLUDEDIR=${includedir} BUILD_STATIC=no"
+9 -4
View File
@@ -130,7 +130,8 @@ Fixing vulnerabilities in recipes
=================================
If a CVE security issue impacts a software component, it can be fixed by updating to a newer
version of the software component or by applying a patch. For Poky and OE-Core master branches, updating
version of the software component, by applying a patch or by marking it as patched via
:term:`CVE_STATUS` variable flag. For Poky and OE-Core master branches, updating
to a newer software component release with fixes is the best option, but patches can be applied
if releases are not yet available.
@@ -158,7 +159,8 @@ CVE checker will then capture this information and change the CVE status to ``Pa
in the generated reports.
If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
version or other reasons, the CVE can be marked as ``Ignored`` using the :term:`CVE_CHECK_IGNORE` variable.
version or other reasons, the CVE can be marked as ``Ignored`` by using
the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``.
As mentioned previously, if data in the CVE database is wrong, it is recommend to fix those
issues in the CVE database directly.
@@ -175,6 +177,8 @@ is found in the name of the file, the corresponding CVE is considered as patched
Don't forget that if multiple CVE IDs are found in the filename, only the last
one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch
file. The found CVE IDs are also considered as patched.
Additionally ``CVE_STATUS`` variable flags are parsed for reasons mapped to ``Patched``
and these are also considered as patched.
Then, the code looks up all the CVE IDs in the NIST database for all the
products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
@@ -182,8 +186,9 @@ products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
- If the package name (:term:`PN`) is part of
:term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``.
- If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
set as ``Ignored``.
- If the CVE ID has status ``CVE_STATUS[<CVE ID>] = "ignored"`` or if it's set to
any reason which is mapped to status ``Ignored`` via ``CVE_CHECK_STATUSMAP``,
it is set as ``Ignored``.
- If the CVE ID is part of the patched CVE for the recipe, it is
already considered as ``Patched``.