Hello, On Thursday, February 5, 2026 at 12:54 AM, Joshua Watt wrote: > Yes, I agree this should be the strategy for handling CVEs. It would > also be really good to get this in before the LTS
Targeting Wrynose (around April 2026) is ambitious, but it might be feasible. > I'm working on some changes to SPDX that I think will help with this. > Specifically, I'm adding "Package" objects to describe recipes. This > allows the recipes to be linked as build time dependencies > independently of the build provenance (which does the same thing, but > for builds). The data in the recipe package will contain only data > that can be statically determined without actually building the > recipe, so it will give us the avenue to do CVE analysis without > actually building anything[1]. This should allow CVE analysis on the > native and static libraries since they will be included as build time > dependencies, even though they don't appear in the final image. Thank you for working on this. I have a couple of requests: - It would be helpful to distinguish between native and target packages. The goal is to support a flag in `sbom-cve-check` that limits analysis to packages deployed in the target (including static dependencies) or extends it to all components. - If possible (though not a priority), including layer information (URL, Git version, etc.) associated with a `build_Build` object would be valuable. > [1]: Sadly, it _can't_ include license information because > NO_GENERIC_LICENSE means you can have license text that you don't know > until after do_unpack; we should consider doing something about that. > > On Wed, Feb 4, 2026 at 10:31 AM Ross Burton <[email protected]> wrote: > > To summarise [5] the pros and cons: > > + sbom-cve-check can run at any point after the build > > + has better data sources which report more issues "Better" might be too strong, we support *more* data sources. Sometimes, version ranges in the CVE List are incorrect, while the NVD database may provide more accurate information. However, users can configure their preferred data sources via a custom configuration file, so this isn’t a major concern from my perspective. > > - only scans the literal packages that are in a final image, so we don’t > > get coverage of native packages or static linkage > > > > I wonder if the easiest fix for this gap is to enhance the SPDX generation > > to not only generate an “image SPDX” but also a “build SPDX”, which is > > essentially an aggregation of every recipe’s SPDX that is present. A > > recursive execution of the SPDX generation task will mean this covers > > both any native tools and static libraries that are in the dependency > > graph, for maximal coverage. > > > > This gives a solution without needing to be more clever in the image SPDX > > generation, for example including packages for all of the build > > dependencies (be them native or target). I agree with Joshua: improving the SPDX SBOM file is the right direction. > > If this is done then I think sbom-cve-check is at least at parity with > > cve-check, and in many ways far superior. This will allow us to merge the > > few recipes and class from meta-sbom-cve-check into core, and delete > > cve-check. I concur, but we (Joshua?) need to tackle the SPDX generation improvements, which is no small task. On my end, I’ll update `sbom-cve-check` to handle these changes properly. -- Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#230566): https://lists.openembedded.org/g/openembedded-core/message/230566 Mute This Topic: https://lists.openembedded.org/mt/117638558/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
