Collect SBOM information and run checks after a build#338
Open
hnez wants to merge 13 commits intolinux-automation:whinlatterfrom
Open
Collect SBOM information and run checks after a build#338hnez wants to merge 13 commits intolinux-automation:whinlatterfrom
hnez wants to merge 13 commits intolinux-automation:whinlatterfrom
Conversation
hnez
force-pushed
the
sbom-cve-check
branch
17 times, most recently
from
08b7d9a to
392a862
Compare
hnez
force-pushed
the
sbom-cve-check
branch
4 times, most recently
from
187bb0d to
db6f174
Compare
hnez
force-pushed
the
sbom-cve-check
branch
5 times, most recently
from
d970939 to
1795662
Compare
Member
Author
|
I have finally finished triaging the open CVEs on the development branch and have marked the PR as ready for review. |
jluebbe
requested changes
Apr 1, 2026
hnez
force-pushed
the
sbom-cve-check
branch
2 times, most recently
from
87437bc to
efcefc3
Compare
Member
Author
|
Should we fix the open CVEs as part of this PR or just merge it as-is and fix them after the fact? |
Member
I would be fine to limit this PR to build the infrastructure and fix / mitigate the CVE-findings afterwards. |
The openembedded project maintains a list of Linux Kernel CVEs that are not actually relevant (because they have already been fixed) or were incorrectly assigned. Signed-off-by: Leonard Göhrs <[email protected]>
All of the information in this file is already contained in the SPDX file for the whole rootfs, but the `improve_kernel_cve_report.py` script in the openembedded-core source tree works better with the kernel-only file. Signed-off-by: Leonard Göhrs <[email protected]>
These generate a HTML file / textual summary of the known vulnerabilities found in a software bill of materials. Signed-off-by: Leonard Göhrs <[email protected]>
Signed-off-by: Leonard Göhrs <[email protected]>
…rt.py This script from openembedded-core uses the kernel version and list of compiled files from the SPDX file to filter out kernel CVEs that do not actually affect us. Signed-off-by: Leonard Göhrs <[email protected]>
Signed-off-by: Leonard Göhrs <[email protected]>
…ocess The cve_whatever script creates OpenVEX files for all open CVEs that then have to be filled with information about why the vulnerability does not affect the project, or needs to be removed. Signed-off-by: Leonard Göhrs <[email protected]>
…CVEs Signed-off-by: Leonard Göhrs <[email protected]>
We use backports to locally update recipes from other layers, i.e. to get fixes for vulnerabilities earlier or just because we want some feature in advance. And sometimes we need to be quicker than upstream layers and apply updates locally. To do so we also add the updates-* directories. Signed-off-by: Leonard Göhrs <[email protected]>
This solves a slew of open CVEs. According to openembedded core commit
af66dec1a0 ("vim: upgrade 9.2.0 -> 9.2.0110") the following:
CVE-2026-28417, CVE-2026-28418, CVE-2026-28419, CVE-2026-28420,
CVE-2026-28421 and CVE-2026-28422.
Signed-off-by: Leonard Göhrs <[email protected]>
This fixes CVE-2025-52881 and CVE-2025-52565 for us. Signed-off-by: Leonard Göhrs <[email protected]>
This fixes various CVEs. Among them CVE-2026-3731, which can result in an out of bounds read on sftp actions. Signed-off-by: Leonard Göhrs <[email protected]>
These are not new CVEs by any means, but somehow they did not show up before. Luckily these do not affect us very much. Signed-off-by: Leonard Göhrs <[email protected]>
Member
Author
|
I may have lost track here. We agreed to merge this as-is, right? |
Member
Once we agreed on the technical details we agreed to merge with CVE-warnings in place and fix those afterwards in the usual manner. I do not see any more technical discussion. So I guess we are good to go? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We want to keep track of vulnerabilities in our current releases. This means the nightly
testingbuilds and the biannual stable releases (including point releases for them).For that to work we have started archiving SBOM information for previous builds with #343 and will have to upload SBOM information for stable releases from now on.
This PR implements the counterpart of periodically running a CVE check based on these archived SBOMs to warn up if any new vulnerabilities pop up.