From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39DB7D3514F for ; Wed, 1 Apr 2026 07:43:13 +0000 (UTC) Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.7661.1775029387190820767 for ; Wed, 01 Apr 2026 00:43:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=dkim header.b=j1HIdVxL; spf=pass (domain: bootlin.com, ip: 185.246.85.4, mailfrom: benjamin.robin@bootlin.com) Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 08A864E42893 for ; Wed, 1 Apr 2026 07:43:05 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id B9625602BF; Wed, 1 Apr 2026 07:43:04 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 1966410450257; Wed, 1 Apr 2026 09:43:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775029383; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=543SE/GtJ9od1L4mdmzS7Xu5ntNH++5ZgDuBPOQX780=; b=j1HIdVxLOFOvgxGjvi7OjCEEDMB5NdXNpq5e4VusDFY4HyyVWvPs2rt0/2NsMu478rc3PB PhXV61C4auCyjUhwhXHNkdFYi17dgFnfRFnuAdk+7UFXto7YHcmQVPBhvpLnICRWgd5bx8 RoSkwGK89yp6L2zsE62aYtocUXrOHFBw4IZNBEJ49BFIzDean412fci0wuDYwG5DTrE/k7 OUnMs6ezfYb1aIrc+qAgyhsUsibIYWkERazc9oPANn3yTQnUVP/8adoT7tFheBFvTdUTGU DVDlHVgcF+R+HGz52hUT04yVPNeZKcoPceVM71et6DXL+LjHA+gQ27oAHFg2/w== From: Benjamin Robin To: "stondo@gmail.com" , "Tondo, Stefano" , "Freihofer, Adrian" Cc: "openembedded-core@lists.openembedded.org" , "ross.burton@arm.com" , Joshua Watt , Richard Purdie , "marta.rybczynska@syslinbit.com" , "Marko, Peter" , "mathieu.dubois-briand@bootlin.com" Subject: Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation Date: Wed, 01 Apr 2026 09:43:00 +0200 Message-ID: <9600909.CDJkKcVGEf@brobin-bootlin> In-Reply-To: References: <20260331141956.608976-1-stondo@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Last-TLS-Session-Version: TLSv1.3 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 01 Apr 2026 07:43:13 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/234329 Hello, On Wednesday, April 1, 2026 at 12:05=E2=80=AFAM, Freihofer, Adrian wrote: > I agree that generating the SBOM and then processing it with > independent, specialized tools is the right approach =E2=80=94 and I beli= eve > that was also what I proposed, based on Ross's post in that earlier > discussion. >=20 > Taking this further, though, raises an interesting question: how could > CVEs discovered after the SBOM/VEX was built with Bitbake be handled in > a more automated way? I=E2=80=99m not sure I fully understand the question. This is exactly the p= urpose of `sbom-cve-check`. It can be executed automatically from Yocto post-build, or at any time later outside of Yocto. > A tool with access to the latest CVE database, an XL SBOM, and the > corresponding source and debug packages could likely mark many CVEs as > not_affected automatically =E2=80=94 for instance, because certain source= files > are not compiled, or a relevant #ifdef is disabled. `sbom-cve-check` is designed to do precisely this, or at least that is the goal. However, supporting `#ifdef` is not planned in the short term; filtering is currently done by filename. Unfortunately, not many CVE entries contain the information needed to automatically mark them as not affected. Only the kernel typically has this information properly filled in. > Would it make sense to extend sbom-cve-check to support exporting an > OpenVEX document covering all CVEs at the time of execution? Such a > tool would need to: >=20 > * Download the CVE database > * Extract static CVE status information from the SPDX document > * Attempt to automatically evaluate the status of CVEs found in the > database but not mentioned in the static SPDX I=E2=80=99m not sure I follow what you mean, this is exactly what `sbom-cve-check` is already trying to do. It can generate OpenVEX files. Perhaps not everything is perfect yet (far from it), and some parts may still need improvement. > This essentially describes merging Joshua's tool with Benjamin's sbom- > cve-check into a unified tool that can ingest SPDX data, NIST > information, source files, and more =E2=80=94 and produce various outputs= such > as CVE check graphs, summary tables, and VEX documents in multiple > variants. `sbom-cve-check` can generate multiple export formats and can be extended to support additional formats. > It's also worth asking how Yocto-specific such a tool would actually > need to be. It could potentially be generic enough to support various > Linux distributions =E2=80=94 which leads to the question: does something= like > this already exist? The goal of `sbom-cve-check` is not to be tied to Yocto. As long as you can provide an SBOM in a supported format, `sbom-cve-check` should work. That said, there is still a lot of development needed to fully achieve this goal. >=20 > Regards, > Adrian Best regards, =2D-=20 Benjamin Robin, Bootlin Embedded Linux and Kernel engineering https://bootlin.com