Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Perale via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Cc: Thomas Perale <thomas.perale@mind.be>,
	Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Subject: [Buildroot] [RFC PATCH 01/14] docs/manual: add vulnerability status and justification
Date: Wed, 24 Jun 2026 16:06:32 +0200	[thread overview]
Message-ID: <20260624140645.185318-2-thomas.perale@mind.be> (raw)
In-Reply-To: <20260624140645.185318-1-thomas.perale@mind.be>

In Buildroot, we can put the ignore CVEs entries in different
categories:

- Vulnerability fixed by a patch.
- Vulnerability ignored because the internal tooling detect it as a
  false positive
- Vulnerability ignored because the database is wrong or not up-to-date.
- Vulnerability ignored because it doesn't apply to Buildroot
  (platform/hardware specific, ...).
- Vulnerability ignored because Buildroot is using an upstream fixed
  version (based on a hash for instance) while the CPE metadata
  reference the latest known version.

Since the introduction of `_IGNORE_CVES` the justification for the
vulnerability were added as a comment on top of the ignored
vulnerability. With the introduction of the rule for the `CVE:` trailer
it's now possible to distinguish the vulnerabilities that are patched
from the one that are not-applicable for another unknown reason.

This commit add documentation to introduce two new variables:

- `<pkg>_<vuln-id>_STATUS`
- `<pkg>_<vuln-id>_DETAIL`

This allows to have machine readable variables that are exposed and
contains the reasons why a vulnerability is set as ignored instead of
storing this knowledge in a comment on top of the `_IGNORE_CVES` entry.

The `<pkg>_<vuln-id>_STATUS` syntax is based on OpenVex statuses syntax
[1][2]. This varialbe only needs to be used if a patch on the Buildroot
tree isn't present.

The `<pkg>_<vuln-id>_DETAIL` is a free text field that allows to add
more information to justify the status.

[1] https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-labels
[2] https://github.com/openvex/ospec/blob/main/OPENVEX-SPEC.md#status-justifications

Signed-off-by: Thomas Perale <thomas.perale@mind.be>
---
 docs/manual/adding-packages-generic.adoc | 35 ++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/docs/manual/adding-packages-generic.adoc b/docs/manual/adding-packages-generic.adoc
index e7547460fd..47b28adf4b 100644
--- a/docs/manual/adding-packages-generic.adoc
+++ b/docs/manual/adding-packages-generic.adoc
@@ -520,6 +520,41 @@ LIBFOO_IGNORE_CVES += CVE-2020-12345
 LIBFOO_IGNORE_CVES += CVE-2020-54321
 ----
 
+* +LIBFOO_<VULN-ID>_STATUS+ informs about the impact of the vulnerability
+  +<VULN-ID>+. This variable needs to be set only if the referenced +<VULN-ID>+
+  is not fixed by a patch present in the Buildroot tree. It support different
+  labels based on
+  https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-labels[OpenVex
+  statuses] and
+  https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-justifications[justification]:
+  ** +fixed+: referenced by the package Makefile already includes the fix but
+     no new version has been issued by the upstream project. This typically
+     happens when the version is using an +hash+ and the CPE reference the
+     latest known version.
+  ** +not-affected-component-not-present+: the vulnerability is incorrect and
+     should reference another package. Or the package is not part of the final
+     image.
+  ** +not-affected-vulnerable-code-not-present+: the code affected by the
+     vulnerability is not included in the final image. Could be a not supported
+     architecture, flags that are disabled by the package configuration,
+     busybox commands not built, dependencies not supported, ...
+  ** +not-affected-vulnerable-code-not-in-execute-path+: the vulnerable code is
+     present in the generated image but cannot be reached because of the
+     system's runtime configuration.
+  ** +not-affected-vulnerable-code-cannot-be-controlled-by-adversary+: the
+     vulnerable code may be executed, but an attacker cannot control the inputs
+     required to trigger the vulnerability.
+* +LIBFOO_<VULN-ID>_DETAIL+ is an optional free text entry that add
+  additional information on the reason a +STATUS+ has been set for a
+  +<VULN-ID>+.
++
+----
+LIBFOO_IGNORE_CVES += CVE-2020-54321
+
+LIBFOO_CVE-2020-54321_STATUS = not-affected-vulnerable-code-not-present
+LIBFOO_CVE-2020-54321_DETAIL = Only when built with libbaz, which Buildroot doesn't support
+----
+
 * [[cpe-id]] +LIBFOO_CPE_ID_*+ variables is a set of variables that allows the
   package to define its https://nvd.nist.gov/products/cpe[CPE
   identifier]. The available variables are:
-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2026-06-24 14:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 14:06 [Buildroot] [RFC PATCH 00/14] Add exportable vulnerability informations Thomas Perale via buildroot
2026-06-24 14:06 ` Thomas Perale via buildroot [this message]
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 02/14] utils/checkpackagelib/lib_mk.py: check _STATUS value is supported Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 03/14] package/pkg-utils: show-info expose vuln details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 04/14] utils/generate-cyclonedx: support vulnerability details Thomas Perale via buildroot
2026-06-25 18:01   ` Fiona Klute via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 05/14] package/sox: add vulnerabilities details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 06/14] package/php: add vulnerability details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 07/14] package/mupdf: add vulnerabilities details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 08/14] package/python-pip: add detail to vulnerability Thomas Perale via buildroot
2026-06-25 17:57   ` Fiona Klute via buildroot
2026-06-26  7:25     ` Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 09/14] package/luajit: add details to vulnerabilities Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 10/14] package/libuci: add vulnerability details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 11/14] package/glibc: " Thomas Perale via buildroot
2026-06-24 14:45   ` Romain Naour via buildroot
2026-06-24 15:06     ` Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 12/14] package/freeradius-server: add vulnerabilities details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 13/14] package/flex: add vulnerability details Thomas Perale via buildroot
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 14/14] package/clamav: " Thomas Perale via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260624140645.185318-2-thomas.perale@mind.be \
    --to=buildroot@buildroot.org \
    --cc=ricardo.martincoski@datacom.com.br \
    --cc=thomas.perale@mind.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox