mirror of
https://git.busybox.net/buildroot
synced 2025-12-20 01:10:56 +08:00
9415529923
The CycloneDX specification for vulnerabilities defines four analysis
states ([1]) for cases where a vulnerability does not affect a component:
* resolved
* resolved_with_pedigree
* not_affected
* false_positive
Currently, the metadatas present in Buildroot does not allow an accurate
mapping of ignored CVEs to the appropriate CycloneDX vulnerability
categories. As a result, all ignored CVEs are currently marked as
'in_triage' by default.
This default analysis was established during the introduction of the
'generate-cyclonedx' script. The reasoning at the time was that SBOM
consumers might want to re-evaluate ignored vulnerabilities, as the
Buildroot infrastructure could not reliably determine their actual
state.
This patch adds support for automatically marking vulnerabilities as
'resolved_with_pedigree' when a Buildroot patch includes a 'CVE:''
tag in its header referencing the CVE identifier.
The 'CVE:' tag appears alongside the already required 'Upstream:', if
the patch address a security vulnerability and may be repeated if a
patch addresses multiple vulnerabilities.
If a vulnerability is addressed by multiple patches, each patch will need to
reference the vulnerability identifier.
For details on how CycloneDX handles 'resolved_with_pedigree', see
[1][2].
As an example, the CVE-2025-3198 from the binutils package will result
in the following pedigree for the binutils component:
```
{
"type": "unofficial",
"diff": {
"text": {
"content": "..."
}
},
"resolves": [
{
"type": "security",
"name": "CVE-2025-3198"
}
]
},
```
The `resolves` property is an array of issue the pedigree resolves. If
multiple are addressed by the same patch, then multiple identifier will be
present in this array.
In the listed vulnerabilities the entry for the CVE-2025-3198 looks like
this:
```
{
"id": "CVE-2025-3198",
"analysis": {
"state": "resolved_with_pedigree",
"detail": "The CVE 'CVE-2025-3198' has been marked as ignored by Buildroot"
},
"affects": [
{
"ref": "binutils"
}
]
}
```
[1] https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis_state
[2] https://cyclonedx.org/docs/1.6/json/#components_items_pedigree_patches_items_resolves
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This directory contains various useful scripts and tools for working
with Buildroot. You need not add this directory in your PATH to use
any of those tools, but you may do so if you want.
brmake
a script that can be run instead of make, that prepends the date in
front of each line, redirects all of the build output to a file
("'br.log' in the current directory), and just outputs the Buildroot
messages (those lines starting with >>>) on stdout.
Do not run this script for interactive configuration (e.g. menuconfig)
or on an unconfigured directory. The output is redirected so you will see
nothing.
check-package
a script that checks the coding style across the buildroot tree. It
checks package's Config.in and .mk files, runs shellcheck for all shell
scripts, flake8 for python files, checks for typos, etc.
It checks the .checkpackageignore file if errors should be ignored and
errors if there's a file listed that doesn't produce an error.
docker-run
a script that runs a command (like make check-package) inside the
buildroot CI docker container; pass no command to get an interactive
shell.
genrandconfig
a script that generates a random configuration, used by the autobuilders
(http://autobuild.buildroot.org). It selects a random toolchain from
support/config-fragments/autobuild and randomly selects packages to build.
get-developers
a script to return the list of people interested in a specific part
of Buildroot, so they can be Cc:ed on a mail. Accepts a patch as
input, a package name or and architecture name.
scancpan
a script to create a Buildroot package by scanning a CPAN module
description.
scanpypi
a script to create a Buildroot package by scanning a PyPI package
description.
size-stats-compare
a script to compare the rootfs size between two different Buildroot
configurations. This can be used to identify the size impact of
a specific option, of a set of specific options, or of an update
to a newer Buildroot version...
test-pkg
a script that tests a specific package against a set of various
toolchains, with the goal to detect toolchain-related dependencies
(wchar, threads...)