diff options
| author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2022-12-02 16:26:23 +0100 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2022-12-07 15:04:17 +0000 |
| commit | 3ec705d3203766a9a437ef7c7837f820c0800ead (patch) | |
| tree | c93f35434f26671f2be93d43c567734d904740b8 | |
| parent | 2c96490a293a3bdb1a71222b58537dccfc5c5d4c (diff) | |
| download | poky-3ec705d3203766a9a437ef7c7837f820c0800ead.tar.gz | |
Expand cve-check class documentation
Using backported content from the master branch
(From yocto-docs rev: cfd9848fae96a2b047df22d1a8bd4821c3d71cbf)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| -rw-r--r-- | documentation/ref-manual/classes.rst | 52 |
1 files changed, 50 insertions, 2 deletions
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index a2d743d568..03995e996d 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst | |||
| @@ -430,13 +430,61 @@ discussion on these cross-compilation tools. | |||
| 430 | ===================== | 430 | ===================== |
| 431 | 431 | ||
| 432 | The :ref:`cve-check <ref-classes-cve-check>` class looks for known CVEs (Common Vulnerabilities | 432 | The :ref:`cve-check <ref-classes-cve-check>` class looks for known CVEs (Common Vulnerabilities |
| 433 | and Exposures) while building an image. This class is meant to be | 433 | and Exposures) while building with BitBake. This class is meant to be |
| 434 | inherited globally from a configuration file:: | 434 | inherited globally from a configuration file:: |
| 435 | 435 | ||
| 436 | INHERIT += "cve-check" | 436 | INHERIT += "cve-check" |
| 437 | 437 | ||
| 438 | To filter out obsolete CVE database entries which are known not to impact software from Poky and OE-Core, | ||
| 439 | add following line to the build configuration file:: | ||
| 440 | |||
| 441 | include cve-extra-exclusions.inc | ||
| 442 | |||
| 438 | You can also look for vulnerabilities in specific packages by passing | 443 | You can also look for vulnerabilities in specific packages by passing |
| 439 | ``-c cve_check`` to BitBake. You will find details in the | 444 | ``-c cve_check`` to BitBake. |
| 445 | |||
| 446 | After building the software with Bitbake, CVE check output reports are available in ``tmp/deploy/cve`` | ||
| 447 | and image specific summaries in ``tmp/deploy/images/*.cve`` or ``tmp/deploy/images/*.json`` files. | ||
| 448 | |||
| 449 | When building, the CVE checker will emit build time warnings for any detected | ||
| 450 | issues which are in the state ``Unpatched``, meaning that CVE issue seems to affect the software component | ||
| 451 | and version being compiled and no patches to address the issue are applied. Other states | ||
| 452 | for detected CVE issues are: ``Patched`` meaning that a patch to address the issue is already | ||
| 453 | applied, and ``Ignored`` meaning that the issue can be ignored. | ||
| 454 | |||
| 455 | The ``Patched`` state of a CVE issue is detected from patch files with the format | ||
| 456 | ``CVE-ID.patch``, e.g. ``CVE-2019-20633.patch``, in the :term:`SRC_URI` and using | ||
| 457 | CVE metadata of format ``CVE: CVE-ID`` in the commit message of the patch file. | ||
| 458 | |||
| 459 | If the recipe lists the ``CVE-ID`` in :term:`CVE_CHECK_IGNORE` variable, then the CVE state is reported | ||
| 460 | as ``Ignored``. Multiple CVEs can be listed separated by spaces. Example:: | ||
| 461 | |||
| 462 | CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511" | ||
| 463 | |||
| 464 | If CVE check reports that a recipe contains false positives or false negatives, these may be | ||
| 465 | fixed in recipes by adjusting the CVE product name using :term:`CVE_PRODUCT` and :term:`CVE_VERSION` variables. | ||
| 466 | :term:`CVE_PRODUCT` defaults to the plain recipe name :term:`BPN` which can be adjusted to one or more CVE | ||
| 467 | database vendor and product pairs using the syntax:: | ||
| 468 | |||
| 469 | CVE_PRODUCT = "flex_project:flex" | ||
| 470 | |||
| 471 | where ``flex_project`` is the CVE database vendor name and ``flex`` is the product name. Similarly | ||
| 472 | if the default recipe version :term:`PV` does not match the version numbers of the software component | ||
| 473 | in upstream releases or the CVE database, then the :term:`CVE_VERSION` variable can be used to set the | ||
| 474 | CVE database compatible version number, for example:: | ||
| 475 | |||
| 476 | CVE_VERSION = "2.39" | ||
| 477 | |||
| 478 | Any bugs or missing or incomplete information in the CVE database entries should be fixed in the CVE database | ||
| 479 | via the `NVD feedback form <https://nvd.nist.gov/info/contact-form>`__. | ||
| 480 | |||
| 481 | Users should note that security is a process, not a product, and thus also CVE checking, analyzing results, | ||
| 482 | patching and updating the software should be done as a regular process. The data and assumptions | ||
| 483 | required for CVE checker to reliably detect issues are frequently broken in various ways. | ||
| 484 | These can only be detected by reviewing the details of the issues and iterating over the generated reports, | ||
| 485 | and following what happens in other Linux distributions and in the greater open source community. | ||
| 486 | |||
| 487 | You will find some more details in the | ||
| 440 | ":ref:`dev-manual/common-tasks:checking for vulnerabilities`" | 488 | ":ref:`dev-manual/common-tasks:checking for vulnerabilities`" |
| 441 | section in the Development Tasks Manual. | 489 | section in the Development Tasks Manual. |
| 442 | 490 | ||
