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 00/14] Add exportable vulnerability informations
Date: Wed, 24 Jun 2026 16:06:31 +0200 [thread overview]
Message-ID: <20260624140645.185318-1-thomas.perale@mind.be> (raw)
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 series add support to tag the remaining 'IGNORE_CVES' entry with a
set of information that can then be exported with 'show-info'.
This was discussed during the post-FOSDEM buildroot hackathon. The idea
of using OpenVex for the annotation format as in the future multiple
SBOM output format might be supported and OpenVex looked like a good
candidate for the base annotation without re-inventing our own format.
This RFC to discuss:
- The OpenVex annotation used and how we make them map to the Buildroot
cases (see the doc change). I also provided some example of ignored
entries and how I make them map to give more context. Not all the
entries are mapped yet.
- Should we consider another format ?
- How I translate this format to CycloneDX analysis.
Still TODO:
- The CycloneDX translation needs to change as it depends on
https://patchwork.ozlabs.org/project/buildroot/patch/20260624101340.80670-8-thomas.perale@mind.be/.
The current implementation is a rough draft that is used only for
testing
- The STATUS and DETAIL variables needs to be replicated for host
packages.
- Add a test case that run 'make show-info-all |
utils/generate-cyclonedx' and verify no "in_triage" analysis remains.
This depends on the two previous TODOs.
Thomas Perale (14):
docs/manual: add vulnerability status and justification
utils/checkpackagelib/lib_mk.py: check _STATUS value is supported
package/pkg-utils: show-info expose vuln details
utils/generate-cyclonedx: support vulnerability details
package/sox: add vulnerabilities details
package/php: add vulnerability details
package/mupdf: add vulnerabilities details
package/python-pip: add detail to vulnerability
package/luajit: add details to vulnerabilities
package/libuci: add vulnerability details
package/glibc: add vulnerability details
package/freeradius-server: add vulnerabilities details
package/flex: add vulnerability details
package/clamav: add vulnerability details
docs/manual/adding-packages-generic.adoc | 35 ++++++++
package/clamav/clamav.mk | 6 +-
package/flex/flex.mk | 7 +-
.../freeradius-server/freeradius-server.mk | 7 +-
package/glibc/glibc.mk | 32 ++++---
package/libuci/libuci.mk | 3 +-
package/luajit/luajit.mk | 15 ++--
package/mupdf/mupdf.mk | 10 +--
package/php/php.mk | 3 +-
package/pkg-utils.mk | 19 +++++
package/python-pip/python-pip.mk | 5 +-
package/sox/sox.mk | 41 ++++++---
utils/checkpackagelib/lib_mk.py | 22 +++++
utils/generate-cyclonedx | 83 +++++++++++++++----
14 files changed, 227 insertions(+), 61 deletions(-)
--
2.54.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next reply other threads:[~2026-06-24 14:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 14:06 Thomas Perale via buildroot [this message]
2026-06-24 14:06 ` [Buildroot] [RFC PATCH 01/14] docs/manual: add vulnerability status and justification Thomas Perale via buildroot
2026-08-20 20:47 ` Thomas Petazzoni via buildroot
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-08-20 20:54 ` Thomas Petazzoni 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-1-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.