I reviewed the RFC. It looks good to me. I had one minor comment on the 2/3 of
patch.
Reviewed-by: Mark Hatle <[email protected]>
On 5/31/24 9:06 AM, Marta Rybczynska wrote:
Hello,
We have been working on the standalone version of the cve-check that can run
over an SBOM (SPDX+VEX-like information) since April. This is the moment for the
RFC. This way we can verify use cases, discuss what is needed to add and do
testing early! (and the curious people can start running it too)
The tooling consists of a patchset over OE-core:
https://lists.openembedded.org/g/openembedded-core/message/200074
<https://lists.openembedded.org/g/openembedded-core/message/200074>
https://lists.openembedded.org/g/openembedded-core/message/200075
<https://lists.openembedded.org/g/openembedded-core/message/200075>
and a modification heeded for the CVE backend (the Kernel CNA uses "linux" and
not "linux_kernel")
https://lists.openembedded.org/g/openembedded-core/message/200076
<https://lists.openembedded.org/g/openembedded-core/message/200076>
The standalone tool RFC is here:
https://gitlab.com/syslinbit/public/yocto-vex-check
<https://gitlab.com/syslinbit/public/yocto-vex-check> This repo will migrate to
the YP infra, likely in a form of multiple ones (we also have autobuilder
changes, and will likely split binary data to a separate repository).
The yocto-vex-check supports two databases today: NVD and CVE.
How to use the tool (from the README)
This tool allows to check SBOMs for vulnerabilities. You can take SBOM/VEX of a
Yocto Project build and generate a fresh vulnerability status. It uses the SPDX
archive as the list of packages to check, with the additional information from
the VEX class.
WARNING: this tool is under active development, file formats and options do
change regularly.
Functionalities:
- reads YP SPDX 2.2 files and YP cve-check JSON files
- converts SPDX/cve-check JSON to VEX (close to OpenVEX)
- performs a check for vulnerabilities taking the VEX and using the specified
database
- uses output of the "vex" class of OpenEmbedded-core
How to use:
1. Download the database to use:
- for NVD, use cve-update-nvd2-native.py
- for the CVE database, get the CVEv5 git repository: either the upsteam one
at https://github.com/CVEProject/cvelistV5
<https://github.com/CVEProject/cvelistV5> or the one with OE-related fixes at
https://github.com/mrybczyn/cvelistV5-overrides
<https://github.com/mrybczyn/cvelistV5-overrides> (recommended)
2. Enable the vex class in your YP-based distribution build by adding to your
local.conf:
INHERIT += "vex"
3. Build your image as usual and note the location of the CVE JSON file (in the
output of the build)
4. (Recommended for production builds) archive the CVE JSON file and the SPDX
archive
5. Use the tool as described below at any moment to generate a fresh
vulnerability status
6. (Optional) You can convert the output to text or CSV format using
scripts/cve-report.py
Descrition of tools:
The high-level wrapper performs the whole process of a given database. The usage
is as follows:
./wrap-yocto-vex-check.py -i <cve-check-JSON-file> -o <output_dir> -t
<temporary_dir> -b <build directory like tmp-glibc> -db <database path> -db-type
<database type>
where:
-i <cve-check-JSON-file> is the CVE JSON file as given in the output of the
build
-o <output_dir> is the output directory for the updated CVE file
-t <temporary_dir> is a temporary directory used during the scan
-b <build directory like tmp-glibc> is the build directory that contains the
SPDX archive
-db <database path> is the path to the database file (NVD) or downloaded git
repository (CVE)
-db-type <database type> is the database type: NVD or CVE
Lower-level tools:
- cve-update-nvd2-native.py - allows to download the NVD database
- yocto-vex-check.py - step-by-step conversions; imports SPDX archive, allows to
convert SPDX+CVE JSON to VEX, runs the vulnerability check on the given database
Limitations:
- today the SPDX generation in YP works for images and SDK, not for the world
build
- the MITRE (CVE) database contains a number of difficult-to-parse entries;
especially before 2024.
We know there are some bugs (one related to the linux_kernel), the fix is in
progress.
Questions/comments/use-cases welcome!
Our questions for further steps:
1. We started with the assumption of SPDX as the package list to scan and the
CVE JSON data as the supplementary data needed for the scan. However, SPDX
archive isn't generated for world builds. We can 1) add the only remaining
information to the VEX (CVE-JSON) which is the CPE list and allow to use the VEX
file as source and 2) add the remaining archives to SPDX.
At the end we will likely want both, also because SPDX2.2 requires the complete
build, and that is long in case of world.
2. The tool currently supports either one backend (CVE, NVD), or the other.
Results are different. We can merge results by post-processing or add a list of
databases to use. In both cases, there is a difficulty to decide on priority of
conflicting scan results.
3. We'd like to have unit tests using binary data (static NVD database,
specially choosen CVE entries etc). It makes sense to keep them in a separate
repository because of the size.
4. It turned out to be complicated to find locate variables needed to pass to
the tool directly from bitbake. CVE check and SPDX are running at different
phases, and there would be a need for changes in task ordering and possibly some
inheritance. This is complicated and bug prone, so the question is: what about
using the tool separately from the build? We can generate configuration files as
the list of options increases
What do you think?
Regards,
Marta and Samantha
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200279):
https://lists.openembedded.org/g/openembedded-core/message/200279
Mute This Topic: https://lists.openembedded.org/mt/106408578/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
