[PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

This series is an RFC and a follow-up to patch 6/6 ("Add class for
post-build CVE analysis"), which was previously discussed [1].
I have prepared two RFC series, this one and another, each exploring
different approaches to handling the download of CVE databases.

I explored using BitBake's internal fetcher instead of direct Git calls
for fetching CVE databases. However, I encountered two major issues:

- No proper shallow clone support: I wanted to clone the repository
  without downloading the entire history (which is very large). While
  `BB_GIT_SHALLOW` exists, it creates multiple tarballs in the download
  directory, which is inefficient for updates.

  In this series, we are going to do a full clone of the git repository,
  so this point is not going to be fixed.

- Performance overhead for CVE databases deployment: The recipes
  downloading CVE databases must copy them to the sysroot or to the
  deploy directory. This requires copying the extracted databases
  multiple times, even with hard links, which is slow due to the
  combined size (~6 GB, ~672,000 small files).

  In this series, we are using a custom deploy task that is going to
  copy the git repository using rsync directly in the final deploy
  directory, by-passing all the Bitbake logic.

Additionally, there's no built-in way to control the interval between
CVE database fetches: In this series, we are going to use AUTOREV,
which imply to query the git repositories for each build, to check if
there is a new git revision.

Moreover, this series ensures that the CVE analysis runs only when
the original SBOM changes or when the CVE databases are updated.

Upon revisiting the class and its associated recipes, I identified
several areas for improvement, which were fixed in the first commit.
This series also includes a second commit making the VEX class optional
rather than mandatory.

[1] https://lore.kernel.org/all/20260226-add-sbom-cve-check-v3-0-2e60423f4d35@bootlin.com/

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
Benjamin Robin (2):
      sbom-cve-check: Download CVE DB using BitBake fetcher
      sbom-cve-check: VEX class is no longer mandatory

 .../sbom-cve-check-update-db.bbclass               | 87 ----------------------
 meta/classes-recipe/sbom-cve-check.bbclass         | 63 ++++++++++------
 meta/recipes-core/meta/sbom-cve-check-config.inc   |  4 +
 .../meta/sbom-cve-check-update-cvelist-native.bb   | 11 ++-
 .../recipes-core/meta/sbom-cve-check-update-db.inc | 28 +++++++
 .../meta/sbom-cve-check-update-nvd-native.bb       | 11 ++-
 6 files changed, 89 insertions(+), 115 deletions(-)
---
base-commit: ac13c78c0b1a73aa3f21a506a8709ecebfd98faf
change-id: 20260308-add-sbom-cve-check-p2b-f3d30694d3a5

Best regards,
-- 
Benjamin Robin <benjamin.robin@bootlin.com>

[PATCH RFC 1/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

Use BitBake's internal fetcher to download the CVE databases and fix
task dependencies to ensure the CVE analysis runs only if either the
original SBOM changes or the CVE databases are updated.
To achieve this:

- Remove the `nostamp` flag from the `do_sbom_cve_check` task.
- Remove the unnecessary "recrdeptask" on `do_create_image_sbom_spdx`.
  The only required dependency is to run after the
  `do_create_image_sbom_spdx` task of the image recipe.
- Add the `do_sbom_cve_check_setscene` task.
- Update the dependency for the two CVE database-fetching recipes: the
  `do_sbom_cve_check` task now runs after their `do_populate_sysroot`.
- In the two CVE database-fetching recipes, directly copy the downloaded
  Git repository to the deploy directory using `rsync` from the
  `do_install` task. While this is an hack, it is the fastest solution
  I found for deploying the downloaded CVE database. The `do_install`
  task is only executed when `SRCREV` actually changes.

Additional improvements include:

- Add missing `HOMEPAGE` links to `sbom-cve-check-update-*-native.bb`.
- Move the code in `sbom-cve-check-update-db.bbclass` to a simple
  include file. Other layers that may want to add a new recipe to
  download another database can still include it using:
  `require recipes-core/meta/sbom-cve-check-update-db.inc`.
- Rename configuration variables for clarity.
- Add `SBOM_CVE_CHECK_DATABASES_DIR` to define the base directory for
  CVE databases, allowing users to configure an alternate storage
  location.
- Improve documentation for all configuration variables.
- By default, the class now generates a JSON file in the `cve-check`
  format in addition to the exported SPDX 3.0 output.

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
 .../sbom-cve-check-update-db.bbclass               | 87 ----------------------
 meta/classes-recipe/sbom-cve-check.bbclass         | 53 ++++++++-----
 meta/recipes-core/meta/sbom-cve-check-config.inc   |  4 +
 .../meta/sbom-cve-check-update-cvelist-native.bb   | 11 ++-
 .../recipes-core/meta/sbom-cve-check-update-db.inc | 28 +++++++
 .../meta/sbom-cve-check-update-nvd-native.bb       | 11 ++-
 6 files changed, 83 insertions(+), 111 deletions(-)

diff --git a/meta/classes-recipe/sbom-cve-check-update-db.bbclass b/meta/classes-recipe/sbom-cve-check-update-db.bbclass
deleted file mode 100644
index 4f62c831eb72..000000000000
--- a/meta/classes-recipe/sbom-cve-check-update-db.bbclass
+++ /dev/null
@@ -1,87 +0,0 @@
-# SPDX-License-Identifier: MIT
-
-INHIBIT_DEFAULT_DEPS = "1"
-EXCLUDE_FROM_WORLD = "1"
-
-inherit native
-
-deltask do_patch
-deltask do_configure
-deltask do_compile
-deltask do_install
-deltask do_populate_sysroot
-
-SBOM_CVE_CHECK_FETCH_PATH[doc] = "Path to the Git repository to be downloaded. \
-    Should be prefixed by {DL_DIR}/sbom_cve_check/databases/"
-
-SBOM_CVE_CHECK_FETCH_URL[doc] = "Git clone URL of the CVE database"
-
-SBOM_CVE_CHECK_FETCH_INTERVAL ?= "57600"
-SBOM_CVE_CHECK_FETCH_INTERVAL[doc] = "\
-    CVE database update interval, in seconds. By default every 16 hours. \
-    Use 0 to force the update. Use a negative value to skip the update. \
-"
-
-python do_fetch() {
-    from datetime import datetime, timezone, timedelta
-    import fcntl
-    import os
-    import pathlib
-    import subprocess
-
-    bb.utils.export_proxies(d)
-
-    fetch_interval = int(d.get("SBOM_CVE_CHECK_FETCH_INTERVAL"))
-    git_url = d.getVar("SBOM_CVE_CHECK_FETCH_URL")
-    git_dir = pathlib.Path(d.getVar("SBOM_CVE_CHECK_FETCH_PATH"))
-    git_dir.mkdir(parents=True, exist_ok=True)
-
-    def _exec_git_cmd(args):
-        cmd = ["git"]
-        cmd.extend(args)
-        return subprocess.run(
-            cmd,
-            input="",
-            capture_output=True,
-            check=True,
-            cwd=git_dir,
-            encoding="utf-8",
-        )
-
-    # Lock the git directory: take an exclusive lock
-    lock_fd = os.open(git_dir, os.O_RDONLY | os.O_NOCTTY)
-    try:
-        fcntl.flock(lock_fd, fcntl.LOCK_EX)
-
-        # Clone the git repository if it does not exist
-        if not git_dir.joinpath(".git", "HEAD").is_file():
-            _exec_git_cmd(["clone", "--depth", "1", "--single-branch", git_url, "."])
-            return
-
-        # Check if an updated is necessary
-        if fetch_interval < 0:
-            return
-
-        if fetch_interval > 0:
-            # Get date of last commit
-            r = _exec_git_cmd(["show", "-s", "--format=%ct", "HEAD"])
-            commit_date = datetime.fromtimestamp(int(r.stdout.strip()), tz=timezone.utc)
-            delta_last_commit = datetime.now(timezone.utc) - commit_date
-            if delta_last_commit < timedelta(seconds=fetch_interval):
-                return
-
-        _exec_git_cmd(["pull"])
-    except subprocess.SubprocessError as e:
-        bb.error(f"{e.cmd} failed:\n{e.stdout}\n---\n{e.stderr}\n")
-    finally:
-        # Release the exclusive lock
-        os.close(lock_fd)
-}
-
-do_fetch[file-checksums] = ""
-do_fetch[vardeps] = " \
-    SBOM_CVE_CHECK_FETCH_PATH \
-    SBOM_CVE_CHECK_FETCH_URL \
-    SBOM_CVE_CHECK_FETCH_INTERVAL \
-"
-do_fetch[nostamp] = "1"
diff --git a/meta/classes-recipe/sbom-cve-check.bbclass b/meta/classes-recipe/sbom-cve-check.bbclass
index 86e06bdf7c23..2ab29001008a 100644
--- a/meta/classes-recipe/sbom-cve-check.bbclass
+++ b/meta/classes-recipe/sbom-cve-check.bbclass
@@ -1,17 +1,34 @@
 # SPDX-License-Identifier: MIT
 
-SBOM_CVE_CHECK_WORKDIR ??= "${WORKDIR}/sbom_cve_check"
-SBOM_CVE_CHECK_DEPLOYDIR = "${SBOM_CVE_CHECK_WORKDIR}/image-deploy"
+require recipes-core/meta/sbom-cve-check-config.inc
 
-SBOM_CVE_CHECK_EXTRA_ARGS[doc] = "Allow to specify extra arguments to sbom-cve-check. For example to add filtering"
-SBOM_CVE_CHECK_EXTRA_ARGS ?= ""
+SBOM_CVE_CHECK_DEPLOYDIR = "${WORKDIR}/sbom_cve_check/image-deploy"
 
-SBOM_CVE_CHECK_EXPORT_VARS[doc] = "List of variables that declare export files to generate. Each variable must have a 'type' and an 'ext' flag set"
-SBOM_CVE_CHECK_EXPORT_VARS ?= "SBOM_CVE_CHECK_EXPORT_FILE"
+SBOM_CVE_CHECK_EXTRA_ARGS[doc] = "Allow to specify extra arguments to sbom-cve-check. \
+    For example to add export flags for filtering (e.g., only export vulnerable CVEs). \
+"
+SBOM_CVE_CHECK_EXTRA_ARGS ??= ""
 
-SBOM_CVE_CHECK_EXPORT_FILE[doc] = "Default configuration of generated export file"
-SBOM_CVE_CHECK_EXPORT_FILE[type] ?= "spdx3"
-SBOM_CVE_CHECK_EXPORT_FILE[ext] ?= ".cve-check.spdx.json"
+SBOM_CVE_CHECK_EXPORT_VARS[doc] = "List of variables that declare export files to generate. \
+    Each variable must have a 'type' and an 'ext' flag set. \
+    The 'type' flag contains the value that is passed to the --export-type command flags. \
+    The 'ext' flag contains the filename extension (suffix). The output filename is going \
+    to be ${IMAGE_NAME}${ext} \
+"
+SBOM_CVE_CHECK_EXPORT_VARS ?= "SBOM_CVE_CHECK_EXPORT_SPDX3 SBOM_CVE_CHECK_EXPORT_CVECHECK"
+
+SBOM_CVE_CHECK_EXPORT_SPDX3[doc] = "Export configuration to generate an SPDX3 SBOM file, \
+    with the following name: ${IMAGE_NAME}.cve-check.spdx.json \
+"
+SBOM_CVE_CHECK_EXPORT_SPDX3[type] ?= "spdx3"
+SBOM_CVE_CHECK_EXPORT_SPDX3[ext] ?= ".cve-check.spdx.json"
+
+SBOM_CVE_CHECK_EXPORT_CVECHECK[doc] = "Export configuration to generate a JSON manifest \
+    in the same format as the cve-check class, with the following name: \
+    ${IMAGE_NAME}.cve-check.json \
+"
+SBOM_CVE_CHECK_EXPORT_CVECHECK[type] ?= "yocto-cve-check-manifest"
+SBOM_CVE_CHECK_EXPORT_CVECHECK[ext] ?= ".cve-check.json"
 
 SBOM_CVE_CHECK_ALLOW_NETWORK[doc] = "Set to 1 to enable network usage."
 SBOM_CVE_CHECK_ALLOW_NETWORK ?= "0"
@@ -31,7 +48,7 @@ python do_sbom_cve_check() {
 
     sbom_path = d.expand("${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.spdx.json")
     vex_manifest_path = d.expand("${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.json")
-    dl_db_dir = d.expand("${DL_DIR}/sbom_cve_check/databases")
+    dl_db_dir = d.getVar("SBOM_CVE_CHECK_DATABASES_DIR")
     deploy_dir = d.getVar("SBOM_CVE_CHECK_DEPLOYDIR")
     img_link_name = d.getVar("IMAGE_LINK_NAME")
     img_name = d.getVar("IMAGE_NAME")
@@ -66,9 +83,7 @@ python do_sbom_cve_check() {
         bb.note("Running: {}".format(" ".join(cmd_args)))
         bb.process.run(cmd_args, env=cmd_env)
     except bb.process.ExecutionError as e:
-        bb.fatal(
-            f"sbom-cve-check failed with exit code {e.exitcode}\n{e.stdout}\n{e.stderr}"
-        )
+        bb.error(f"sbom-cve-check failed: {e}")
         return
 
     for export_file in export_files:
@@ -79,18 +94,20 @@ python do_sbom_cve_check() {
 addtask do_sbom_cve_check after do_create_image_sbom_spdx before do_build
 
 SSTATETASKS += "do_sbom_cve_check"
-SSTATE_SKIP_CREATION:task-sbom-cve-check = "1"
 do_sbom_cve_check[cleandirs] = "${SBOM_CVE_CHECK_DEPLOYDIR}"
 do_sbom_cve_check[sstate-inputdirs] = "${SBOM_CVE_CHECK_DEPLOYDIR}"
 do_sbom_cve_check[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
-do_sbom_cve_check[recrdeptask] += "do_create_image_sbom_spdx"
 do_sbom_cve_check[depends] += " \
     python3-sbom-cve-check-native:do_populate_sysroot \
     ${@oe.utils.conditional('SBOM_CVE_CHECK_ALLOW_NETWORK','0',' \
-        sbom-cve-check-update-cvelist-native:do_fetch \
-        sbom-cve-check-update-nvd-native:do_fetch \
+        sbom-cve-check-update-cvelist-native:do_populate_sysroot \
+        sbom-cve-check-update-nvd-native:do_populate_sysroot \
     ','',d)} \
 "
 
 do_sbom_cve_check[network] = "${SBOM_CVE_CHECK_ALLOW_NETWORK}"
-do_sbom_cve_check[nostamp] = "1"
+
+python do_sbom_cve_check_setscene() {
+    sstate_setscene(d)
+}
+addtask do_sbom_cve_check_setscene
diff --git a/meta/recipes-core/meta/sbom-cve-check-config.inc b/meta/recipes-core/meta/sbom-cve-check-config.inc
new file mode 100644
index 000000000000..a1a909e22250
--- /dev/null
+++ b/meta/recipes-core/meta/sbom-cve-check-config.inc
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: MIT
+
+SBOM_CVE_CHECK_DATABASES_DIR ??= "${DEPLOY_DIR}/sbom_cve_check/databases"
+SBOM_CVE_CHECK_DATABASES_DIR[doc] = "Download directory path where to store the CVE databases"
diff --git a/meta/recipes-core/meta/sbom-cve-check-update-cvelist-native.bb b/meta/recipes-core/meta/sbom-cve-check-update-cvelist-native.bb
index cd5ed680b4dd..fb213e238ed1 100644
--- a/meta/recipes-core/meta/sbom-cve-check-update-cvelist-native.bb
+++ b/meta/recipes-core/meta/sbom-cve-check-update-cvelist-native.bb
@@ -1,7 +1,12 @@
 SUMMARY = "Updates the CVE List database"
 LICENSE = "MIT"
 
-SBOM_CVE_CHECK_FETCH_PATH = "${DL_DIR}/sbom_cve_check/databases/cvelist"
-SBOM_CVE_CHECK_FETCH_URL = "https://github.com/CVEProject/cvelistV5.git"
+HOMEPAGE = "https://github.com/CVEProject/cvelistV5"
+SRC_URI = "git://github.com/CVEProject/cvelistV5.git;branch=main;protocol=https"
+SRCREV = "${AUTOREV}"
+SBOM_CVE_CHECK_DB_NAME = "cvelist"
 
-inherit sbom-cve-check-update-db
+# FIXME
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+require sbom-cve-check-update-db.inc
diff --git a/meta/recipes-core/meta/sbom-cve-check-update-db.inc b/meta/recipes-core/meta/sbom-cve-check-update-db.inc
new file mode 100644
index 000000000000..5ecb79820247
--- /dev/null
+++ b/meta/recipes-core/meta/sbom-cve-check-update-db.inc
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: MIT
+
+INHIBIT_DEFAULT_DEPS = "1"
+EXCLUDE_FROM_WORLD = "1"
+
+inherit native
+require sbom-cve-check-config.inc
+
+SBOM_CVE_CHECK_DB_NAME[doc] = "Database name, which is the Git repository directory name. \
+    The git repository will be stored in ${SBOM_CVE_CHECK_DATABASES_DIR)/"
+
+DEPENDS += "rsync-native"
+
+# Leverage BitBake's checksum computation for populated sysroot files to determine
+# whether other recipe tasks dependent on this output need to be re-executed.
+do_compile() {
+    git -C "${S}" rev-parse --verify "HEAD^{object}" > "${WORKDIR}/${SBOM_CVE_CHECK_DB_NAME}.rev"
+}
+
+# In the install task, also deploy directly to ${DEPLOY_DIR} using rsync.
+# This is an hack, we are not using do_deploy to prevent multiple unecessary copy of the CVE database.
+do_install() {
+    install -m 644 -D -t "${D}${datadir}/sbom_cve_check/databases/" "${WORKDIR}/${SBOM_CVE_CHECK_DB_NAME}.rev"
+
+    dst="${SBOM_CVE_CHECK_DATABASES_DIR}/${SBOM_CVE_CHECK_DB_NAME}"
+    mkdir -p "$dst"
+    rsync -aH --delete --link-dest="${S}/" "${S}/" "${dst}/"
+}
diff --git a/meta/recipes-core/meta/sbom-cve-check-update-nvd-native.bb b/meta/recipes-core/meta/sbom-cve-check-update-nvd-native.bb
index 7add8e6bfba5..2ed52f7a518a 100644
--- a/meta/recipes-core/meta/sbom-cve-check-update-nvd-native.bb
+++ b/meta/recipes-core/meta/sbom-cve-check-update-nvd-native.bb
@@ -1,7 +1,12 @@
 SUMMARY = "Updates the NVD CVE database"
 LICENSE = "MIT"
 
-SBOM_CVE_CHECK_FETCH_PATH = "${DL_DIR}/sbom_cve_check/databases/nvd-fkie"
-SBOM_CVE_CHECK_FETCH_URL = "https://github.com/fkie-cad/nvd-json-data-feeds.git"
+HOMEPAGE = "https://github.com/fkie-cad/nvd-json-data-feeds"
+SRC_URI = "git://github.com/fkie-cad/nvd-json-data-feeds.git;branch=main;protocol=https"
+SRCREV = "${AUTOREV}"
+SBOM_CVE_CHECK_DB_NAME = "nvd-fkie"
 
-inherit sbom-cve-check-update-db
+# FIXME
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+require sbom-cve-check-update-db.inc

-- 
2.53.0

[PATCH RFC 2/2] sbom-cve-check: VEX class is no longer mandatory

[Benjamin Robin]

Execute `sbom-cve-check` with the generated VEX manifest only if
enabled and if `SPDX_INCLUDE_VEX` is set to a value other than "all".
When `SPDX_INCLUDE_VEX=all`, the SPDX 3.0 file already contains all
the necessary information for CVE analysis, making the VEX manifest
redundant.

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
 meta/classes-recipe/sbom-cve-check.bbclass | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes-recipe/sbom-cve-check.bbclass b/meta/classes-recipe/sbom-cve-check.bbclass
index 2ab29001008a..3709fa98d97e 100644
--- a/meta/classes-recipe/sbom-cve-check.bbclass
+++ b/meta/classes-recipe/sbom-cve-check.bbclass
@@ -41,8 +41,6 @@ python do_sbom_cve_check() {
     import bb
     from oe.cve_check import update_symlinks
 
-    if not bb.data.inherits_class("vex", d):
-        bb.fatal("Cannot execute sbom-cve-check missing vex inherit.")
     if not bb.data.inherits_class("create-spdx-3.0", d):
         bb.fatal("Cannot execute sbom-cve-check missing create-spdx-3.0 inherit.")
 
@@ -68,10 +66,14 @@ python do_sbom_cve_check() {
         d.expand("${STAGING_BINDIR_NATIVE}/sbom-cve-check"),
         "--sbom-path",
         sbom_path,
-        "--yocto-vex-manifest",
-        vex_manifest_path,
     ]
 
+    # Assume that SPDX_INCLUDE_VEX is set globally to "all", and not only for the
+    # image recipe, which is very unlikely. This is not an issue to include the
+    # VEX manifest even if not needed.
+    if bb.data.inherits_class("vex", d) and d.getVar("SPDX_INCLUDE_VEX") != "all":
+        cmd_args.extend(["--yocto-vex-manifest", vex_manifest_path])
+
     for export_file in export_files:
         cmd_args.extend(
             ["--export-type", export_file[0], "--export-path", export_file[1]]

-- 
2.53.0

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Richard Purdie]

Hi,

On Mon, 2026-03-09 at 12:57 +0100, Benjamin Robin via lists.openembedded.org wrote:
> This series is an RFC and a follow-up to patch 6/6 ("Add class for
> post-build CVE analysis"), which was previously discussed [1].
> I have prepared two RFC series, this one and another, each exploring
> different approaches to handling the download of CVE databases.
> 
> I explored using BitBake's internal fetcher instead of direct Git calls
> for fetching CVE databases. However, I encountered two major issues:
> 
> - No proper shallow clone support: I wanted to clone the repository
>   without downloading the entire history (which is very large). While
>   `BB_GIT_SHALLOW` exists, it creates multiple tarballs in the download
>   directory, which is inefficient for updates.
> 
>   In this series, we are going to do a full clone of the git repository,
>   so this point is not going to be fixed.
> 
> - Performance overhead for CVE databases deployment: The recipes
>   downloading CVE databases must copy them to the sysroot or to the
>   deploy directory. This requires copying the extracted databases
>   multiple times, even with hard links, which is slow due to the
>   combined size (~6 GB, ~672,000 small files).
> 
>   In this series, we are using a custom deploy task that is going to
>   copy the git repository using rsync directly in the final deploy
>   directory, by-passing all the Bitbake logic.
> 
> Additionally, there's no built-in way to control the interval between
> CVE database fetches: In this series, we are going to use AUTOREV,
> which imply to query the git repositories for each build, to check if
> there is a new git revision.
> 
> Moreover, this series ensures that the CVE analysis runs only when
> the original SBOM changes or when the CVE databases are updated.
> 
> Upon revisiting the class and its associated recipes, I identified
> several areas for improvement, which were fixed in the first commit.
> This series also includes a second commit making the VEX class optional
> rather than mandatory.
> 
> [1] https://lore.kernel.org/all/20260226-add-sbom-cve-check-v3-0-2e60423f4d35@bootlin.com/

I've just been trying to work out where we're at with this coming up to
release and we need to get this resolved.

I feel quite strongly that we need to use the fetcher for obtaining
this data. "fetching" isn't trivial and is full of
license/auditing/sbom issues. Making any exception to that, even for
cve data tends to become problematic later.

The existing approach was only done as it was a sqlite database and we
didn't have fetcher support for such a thing. If we need to improve the
git fetcher in some way to better support this use case (e.g. shallow
clone update efficiency), that is something we can work on.

As such, I was wondering if you had never versions of these patches?

I'd note that we can't set AUTOREV by default, we'll need to specify a
revision, and document how the user can enable AUTOREV in their config
(maybe even a config fragment?). Whilst it is annoying to do that, it
is a requirement that the system doesn't touch the network outside
mirrors unless configured to.

Cheers,

Richard

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 4249 bytes --]

On Wed, Mar 18, 2026 at 6:45 PM Richard Purdie via lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:

> Hi,
>
> On Mon, 2026-03-09 at 12:57 +0100, Benjamin Robin via
> lists.openembedded.org wrote:
> > This series is an RFC and a follow-up to patch 6/6 ("Add class for
> > post-build CVE analysis"), which was previously discussed [1].
> > I have prepared two RFC series, this one and another, each exploring
> > different approaches to handling the download of CVE databases.
> >
> > I explored using BitBake's internal fetcher instead of direct Git calls
> > for fetching CVE databases. However, I encountered two major issues:
> >
> > - No proper shallow clone support: I wanted to clone the repository
> >   without downloading the entire history (which is very large). While
> >   `BB_GIT_SHALLOW` exists, it creates multiple tarballs in the download
> >   directory, which is inefficient for updates.
> >
> >   In this series, we are going to do a full clone of the git repository,
> >   so this point is not going to be fixed.
> >
> > - Performance overhead for CVE databases deployment: The recipes
> >   downloading CVE databases must copy them to the sysroot or to the
> >   deploy directory. This requires copying the extracted databases
> >   multiple times, even with hard links, which is slow due to the
> >   combined size (~6 GB, ~672,000 small files).
> >
> >   In this series, we are using a custom deploy task that is going to
> >   copy the git repository using rsync directly in the final deploy
> >   directory, by-passing all the Bitbake logic.
> >
> > Additionally, there's no built-in way to control the interval between
> > CVE database fetches: In this series, we are going to use AUTOREV,
> > which imply to query the git repositories for each build, to check if
> > there is a new git revision.
> >
> > Moreover, this series ensures that the CVE analysis runs only when
> > the original SBOM changes or when the CVE databases are updated.
> >
> > Upon revisiting the class and its associated recipes, I identified
> > several areas for improvement, which were fixed in the first commit.
> > This series also includes a second commit making the VEX class optional
> > rather than mandatory.
> >
> > [1]
> https://lore.kernel.org/all/20260226-add-sbom-cve-check-v3-0-2e60423f4d35@bootlin.com/
>
> I've just been trying to work out where we're at with this coming up to
> release and we need to get this resolved.
>
> I feel quite strongly that we need to use the fetcher for obtaining
> this data. "fetching" isn't trivial and is full of
> license/auditing/sbom issues. Making any exception to that, even for
> cve data tends to become problematic later.
>
> The existing approach was only done as it was a sqlite database and we
> didn't have fetcher support for such a thing. If we need to improve the
> git fetcher in some way to better support this use case (e.g. shallow
> clone update efficiency), that is something we can work on.
>
> As such, I was wondering if you had never versions of these patches?
>
> I'd note that we can't set AUTOREV by default, we'll need to specify a
> revision, and document how the user can enable AUTOREV in their config
> (maybe even a config fragment?). Whilst it is annoying to do that, it
> is a requirement that the system doesn't touch the network outside
> mirrors unless configured to.
>
>
Fetching the complete git repos has a number of problems. Why not use
release
tarballs like those in  https://github.com/CVEProject/cvelistV5/releases ?
Fkie feeds also have them
https://github.com/fkie-cad/nvd-json-data-feeds/releases

CVE versions of those repositories are good for manual analysis, but a
simple
check does not need all of that.

Also, I'm worried about the size explosion with additional databases that
will be
needed in the 1-2 years time period. I also wouldn't assume all of them
will have
git mirrors.

For an analysis I think it would be better to integrate sources in a
database,
but not a relational one (like it was done with sqlite). An object database
corresponds
better to what the data contains.

Kind regards,
Marta

[-- Attachment #2: Type: text/html, Size: 5514 bytes --]

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Richard Purdie]

On Thu, 2026-03-19 at 08:29 +0100, Marta Rybczynska wrote:
> 
> 
> On Wed, Mar 18, 2026 at 6:45 PM Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> > Hi,
> > 
> > On Mon, 2026-03-09 at 12:57 +0100, Benjamin Robin via lists.openembedded.org wrote:
> > > This series is an RFC and a follow-up to patch 6/6 ("Add class for
> > > post-build CVE analysis"), which was previously discussed [1].
> > > I have prepared two RFC series, this one and another, each exploring
> > > different approaches to handling the download of CVE databases.
> > > 
> > > I explored using BitBake's internal fetcher instead of direct Git calls
> > > for fetching CVE databases. However, I encountered two major issues:
> > > 
> > > - No proper shallow clone support: I wanted to clone the repository
> > >   without downloading the entire history (which is very large). While
> > >   `BB_GIT_SHALLOW` exists, it creates multiple tarballs in the download
> > >   directory, which is inefficient for updates.
> > > 
> > >   In this series, we are going to do a full clone of the git repository,
> > >   so this point is not going to be fixed.
> > > 
> > > - Performance overhead for CVE databases deployment: The recipes
> > >   downloading CVE databases must copy them to the sysroot or to the
> > >   deploy directory. This requires copying the extracted databases
> > >   multiple times, even with hard links, which is slow due to the
> > >   combined size (~6 GB, ~672,000 small files).
> > > 
> > >   In this series, we are using a custom deploy task that is going to
> > >   copy the git repository using rsync directly in the final deploy
> > >   directory, by-passing all the Bitbake logic.
> > > 
> > > Additionally, there's no built-in way to control the interval between
> > > CVE database fetches: In this series, we are going to use AUTOREV,
> > > which imply to query the git repositories for each build, to check if
> > > there is a new git revision.
> > > 
> > > Moreover, this series ensures that the CVE analysis runs only when
> > > the original SBOM changes or when the CVE databases are updated.
> > > 
> > > Upon revisiting the class and its associated recipes, I identified
> > > several areas for improvement, which were fixed in the first commit.
> > > This series also includes a second commit making the VEX class optional
> > > rather than mandatory.
> > > 
> > > [1] https://lore.kernel.org/all/20260226-add-sbom-cve-check-v3-0-2e60423f4d35@bootlin.com/
> > 
> > I've just been trying to work out where we're at with this coming up to
> > release and we need to get this resolved.
> > 
> > I feel quite strongly that we need to use the fetcher for obtaining
> > this data. "fetching" isn't trivial and is full of
> > license/auditing/sbom issues. Making any exception to that, even for
> > cve data tends to become problematic later.
> > 
> > The existing approach was only done as it was a sqlite database and we
> > didn't have fetcher support for such a thing. If we need to improve the
> > git fetcher in some way to better support this use case (e.g. shallow
> > clone update efficiency), that is something we can work on.
> > 
> > As such, I was wondering if you had never versions of these patches?
> > 
> > I'd note that we can't set AUTOREV by default, we'll need to specify a
> > revision, and document how the user can enable AUTOREV in their config
> > (maybe even a config fragment?). Whilst it is annoying to do that, it
> > is a requirement that the system doesn't touch the network outside
> > mirrors unless configured to.
> 
> 
> Fetching the complete git repos has a number of problems. Why not use release
> tarballs like those in  https://github.com/CVEProject/cvelistV5/releases ?
> Fkie feeds also have them https://github.com/fkie-cad/nvd-json-data-feeds/releases

FWIW we can shallow clone git repos, it is just isn't optimal in how
updates are handled which was Benjamin's concern as the shallow clones
end up more like tarballs.

If we use the bitbake fetcher, it also makes it much easier to actually
use tarballs directly too, since the fetcher also supports those and it
just becomes a simple SRC_URI change.

Cheers,

Richard

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

Hello Marta and Richard,

On Thursday, March 19, 2026 at 8:52 AM, Richard Purdie wrote:
> On Thu, 2026-03-19 at 08:29 +0100, Marta Rybczynska wrote:

> > Fetching the complete git repos has a number of problems. Why not use release
> > tarballs like those in  https://github.com/CVEProject/cvelistV5/releases ?
> > Fkie feeds also have them https://github.com/fkie-cad/nvd-json-data-feeds/releases

Here the reasons:
 - Fetching the tarballs is quite complex to implement. This was done
   in cve-update-db-native.bb. To do that we must use a custom fetcher
   because we cannot expect the user to manually update the URL each
   time a new CVE analysis needs to be done.
 - Also, sbom-cve-check is expecting a git repository. It does not
   support a simple extraction of the CVE database.
 - sbom-cve-check also expects one JSON file per CVE, which is not
   the case with release tarball for FKIE. This is a simple compressed
   JSON file.

> FWIW we can shallow clone git repos, it is just isn't optimal in how
> updates are handled which was Benjamin's concern as the shallow clones
> end up more like tarballs.
> 
> If we use the bitbake fetcher, it also makes it much easier to actually
> use tarballs directly too, since the fetcher also supports those and it
> just becomes a simple SRC_URI change.

If we are using BitBake fetcher, with tarballs, the download directory
is going to be filled with a lot of version of the CVE databases.
This is really inefficient.

For cvelistV5 the release zip file is the roughly the same size that
the git shallow clone.

For https://github.com/fkie-cad/nvd-json-data-feeds/releases
this is not even an option to use tarball since sbom-cve-check is
not compatible with this format.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

Hello Marta,

On Thursday, March 19, 2026 at 8:29 AM, Marta Rybczynska wrote:
> Fetching the complete git repos has a number of problems. Why not use
> release
> tarballs like those in  https://github.com/CVEProject/cvelistV5/releases ?
> Fkie feeds also have them
> https://github.com/fkie-cad/nvd-json-data-feeds/releases

sbom-cve-check is not compatible with the tarball release of FKIE. The
CVE database is not in the same format.
For cvelistV5, the shallow git clone is globally the same speed and same
size that the release zip file.

Why fetching git repo has problem? I only see advantages. The update is
quick. We can easily know with which version the analysis was done:
This is the git version.

> CVE versions of those repositories are good for manual analysis, but a
> simple
> check does not need all of that.

I don't understand your point.

> Also, I'm worried about the size explosion with additional databases that
> will be
> needed in the 1-2 years time period. I also wouldn't assume all of them
> will have
> git mirrors.

The git shallow clone of the git repository is the same size that the
tarball, which is logical. I don't understand your point.

> For an analysis I think it would be better to integrate sources in a
> database,
> but not a relational one (like it was done with sqlite). An object database
> corresponds
> better to what the data contains.

sbom-cve-check was not designed like that. We did not want to take this
approach which generates a lot of limitation.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

Hello Richard,

On Wednesday, March 18, 2026 at 6:45 PM, Richard Purdie wrote:
> I've just been trying to work out where we're at with this coming up to
> release and we need to get this resolved.
> 
> I feel quite strongly that we need to use the fetcher for obtaining
> this data. "fetching" isn't trivial and is full of
> license/auditing/sbom issues. Making any exception to that, even for
> cve data tends to become problematic later.

I have just a slight implementation "detail" if we are using BitBake
fetcher. What is the license that we should use for the sources?
How to declare that in the recipes?

Because the license of the repositories:
 - https://github.com/CVEProject/cvelistV5 : Their is none
 - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
   It looks like custom license.

cve-update-db-native.bb is specifying MIT but this is kind of a lie.
I have done the same on my recipes for now...
 
> The existing approach was only done as it was a sqlite database and we
> didn't have fetcher support for such a thing.

The recipes used to download the CVE databases for the cve-check class
are downloading tarballs. Yes these recipes are going to create a sqlite
database from that. But these recipes implements there own fetcher to
simply download a tarball.
That is why I thought I could implement my own fetcher, which is way
simpler than the update_db_file() in cve-update-db-native.bb which is
quite complex.

> If we need to improve the
> git fetcher in some way to better support this use case (e.g. shallow
> clone update efficiency), that is something we can work on.

Well that was my plan, but for the LTS release this was going to be too
short. So in the meantime I preferred to used a custom fetcher which
was implemented in the other RFC (or in the v4 of the original series).

> As such, I was wondering if you had never versions of these patches?

I sent 2 RFCs, one using my own fetcher, and one using the internal
fetcher (this series). And I sent a v4 of the original series.

> I'd note that we can't set AUTOREV by default, we'll need to specify a
> revision, and document how the user can enable AUTOREV in their config
> (maybe even a config fragment?). Whilst it is annoying to do that, it
> is a requirement that the system doesn't touch the network outside
> mirrors unless configured to.

If we can't use AUTOREV by default, which I understand, a config fragment
is the way to go (I think), with sane default to enable sbom-cve-check.
If the user want specific configuration, they can create their own
configuration. The config fragment would set:
 - IMAGE_CLASSES += "sbom-cve-check"
 - SRCREV:pn-sbom-cve-check-update-nvd-native = "${AUTOREV}"
 - SRCREV:pn-sbom-cve-check-update-cvelist-native = "${AUTOREV}"
 - SPDX_INCLUDE_VEX = "all"
 - SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"

Also, what do you think about the deployment of the CVE databases
done using rsync? Do you have a better idea?

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 4038 bytes --]

On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via lists.openembedded.org
<benjamin.robin=bootlin.com@lists.openembedded.org> wrote:

> Hello Richard,
>
> On Wednesday, March 18, 2026 at 6:45 PM, Richard Purdie wrote:
> > I've just been trying to work out where we're at with this coming up to
> > release and we need to get this resolved.
> >
> > I feel quite strongly that we need to use the fetcher for obtaining
> > this data. "fetching" isn't trivial and is full of
> > license/auditing/sbom issues. Making any exception to that, even for
> > cve data tends to become problematic later.
>
> I have just a slight implementation "detail" if we are using BitBake
> fetcher. What is the license that we should use for the sources?
> How to declare that in the recipes?
>
> Because the license of the repositories:
>  - https://github.com/CVEProject/cvelistV5 : Their is none
>  - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
>    It looks like custom license.
>

The CVE project repo does not have a licence included, but it is covered by
https://www.cve.org/legal/termsofuse (the usage part). It is basically MIT.

NVD has the specific,  licence, the one that is in the repo. A warning on
the
needed disclosure sentence in all documentation.

>
> cve-update-db-native.bb is specifying MIT but this is kind of a lie.
> I have done the same on my recipes for now...
>
> > The existing approach was only done as it was a sqlite database and we
> > didn't have fetcher support for such a thing.
>
> The recipes used to download the CVE databases for the cve-check class
> are downloading tarballs. Yes these recipes are going to create a sqlite
> database from that. But these recipes implements there own fetcher to
> simply download a tarball.
> That is why I thought I could implement my own fetcher, which is way
> simpler than the update_db_file() in cve-update-db-native.bb which is
> quite complex.
>

They implement the fetcher to feed into sqlite. Which was an error to use,
in my opinion.


>
> > If we need to improve the
> > git fetcher in some way to better support this use case (e.g. shallow
> > clone update efficiency), that is something we can work on.
>
> Well that was my plan, but for the LTS release this was going to be too
> short. So in the meantime I preferred to used a custom fetcher which
> was implemented in the other RFC (or in the v4 of the original series).
>
> > As such, I was wondering if you had never versions of these patches?
>
> I sent 2 RFCs, one using my own fetcher, and one using the internal
> fetcher (this series). And I sent a v4 of the original series.
>
> > I'd note that we can't set AUTOREV by default, we'll need to specify a
> > revision, and document how the user can enable AUTOREV in their config
> > (maybe even a config fragment?). Whilst it is annoying to do that, it
> > is a requirement that the system doesn't touch the network outside
> > mirrors unless configured to.
>
> If we can't use AUTOREV by default, which I understand, a config fragment
> is the way to go (I think), with sane default to enable sbom-cve-check.
> If the user want specific configuration, they can create their own
> configuration. The config fragment would set:
>  - IMAGE_CLASSES += "sbom-cve-check"
>  - SRCREV:pn-sbom-cve-check-update-nvd-native = "${AUTOREV}"
>  - SRCREV:pn-sbom-cve-check-update-cvelist-native = "${AUTOREV}"
>  - SPDX_INCLUDE_VEX = "all"
>  - SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"
>
> Also, what do you think about the deployment of the CVE databases
> done using rsync? Do you have a better idea?
>

AUTOREV isn't great here because it will re-fetch for each build. So if
you're
building multiple images or platforms (in CI or so), you will get
potentially different
results. cve-check has a set of variable to handle such use cases. You pin
to one specific release and do the whole checking with one single common
version.

Regards,
Marta

[-- Attachment #2: Type: text/html, Size: 5826 bytes --]

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

Hello Marta,

On Thursday, March 19, 2026 at 9:58 AM, Marta Rybczynska wrote:
> On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via lists.openembedded.org
> <benjamin.robin=bootlin.com@lists.openembedded.org> wrote:

> > I have just a slight implementation "detail" if we are using BitBake
> > fetcher. What is the license that we should use for the sources?
> > How to declare that in the recipes?
> >
> > Because the license of the repositories:
> >  - https://github.com/CVEProject/cvelistV5 : Their is none
> >  - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
> >    It looks like custom license.

> The CVE project repo does not have a licence included, but it is covered by
> https://www.cve.org/legal/termsofuse (the usage part). It is basically MIT.
> 
> NVD has the specific,  licence, the one that is in the repo. A warning on
> the
> needed disclosure sentence in all documentation.

So for you, it is fine to declare that the CVE databases are MIT?

> > cve-update-db-native.bb is specifying MIT but this is kind of a lie.
> > I have done the same on my recipes for now...
> >
> > > The existing approach was only done as it was a sqlite database and we
> > > didn't have fetcher support for such a thing.
> >
> > The recipes used to download the CVE databases for the cve-check class
> > are downloading tarballs. Yes these recipes are going to create a sqlite
> > database from that. But these recipes implements there own fetcher to
> > simply download a tarball.
> > That is why I thought I could implement my own fetcher, which is way
> > simpler than the update_db_file() in cve-update-db-native.bb which is
> > quite complex.
> >
> 
> They implement the fetcher to feed into sqlite. Which was an error to use,
> in my opinion.

Well, I understand why they did that. It makes a lot of sense. But it has
a lot of limitation, that is why we developed sbom-cve-check.


> AUTOREV isn't great here because it will re-fetch for each build. So if
> you're
> building multiple images or platforms (in CI or so), you will get
> potentially different
> results. cve-check has a set of variable to handle such use cases. You pin
> to one specific release and do the whole checking with one single common
> version.

Yes, that is why I initially pushed to use my custom fetcher that is
doing a git pull / shallow clone. With this fetcher I have a full control
on the update period.

But if we want to use BitBake fetcher, an user could pin to a specific
version instead of using AUTOREV. But the user needs to to that manually.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

On Thu, Mar 19, 2026 at 10:48 AM Benjamin Robin <benjamin.robin@bootlin.com>
wrote:

> Hello Marta,
>
> On Thursday, March 19, 2026 at 9:58 AM, Marta Rybczynska wrote:
> > On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via
> lists.openembedded.org
> > <benjamin.robin=bootlin.com@lists.openembedded.org> wrote:
>
> > > I have just a slight implementation "detail" if we are using BitBake
> > > fetcher. What is the license that we should use for the sources?
> > > How to declare that in the recipes?
> > >
> > > Because the license of the repositories:
> > >  - https://github.com/CVEProject/cvelistV5 : Their is none
> > >  - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
> > >    It looks like custom license.
>
> > The CVE project repo does not have a licence included, but it is covered
> by
> > https://www.cve.org/legal/termsofuse (the usage part). It is basically
> MIT.
> >
> > NVD has the specific,  licence, the one that is in the repo. A warning on
> > the
> > needed disclosure sentence in all documentation.
>
> So for you, it is fine to declare that the CVE databases are MIT?
>

CVE database is MIT
NVD (so also FKIE) is custom


>
>
> > AUTOREV isn't great here because it will re-fetch for each build. So if
> > you're
> > building multiple images or platforms (in CI or so), you will get
> > potentially different
> > results. cve-check has a set of variable to handle such use cases. You
> pin
> > to one specific release and do the whole checking with one single common
> > version.
>
> Yes, that is why I initially pushed to use my custom fetcher that is
> doing a git pull / shallow clone. With this fetcher I have a full control
> on the update period.
>
> But if we want to use BitBake fetcher, an user could pin to a specific
> version instead of using AUTOREV. But the user needs to to that manually.
>
>
I agree with Richard that using a git fetcher (or other existing fetcher)
is a better
idea than developing a custom fetcher.

Regards,
Marta

[-- Attachment #2: Type: text/html, Size: 3253 bytes --]

Re: [OE-core] [PATCH RFC 0/2] sbom-cve-check: Download CVE DB using BitBake fetcher

[Benjamin Robin]

On Thursday, March 19, 2026 at 1:00 PM, Marta Rybczynska wrote:
> On Thu, Mar 19, 2026 at 10:48 AM Benjamin Robin <benjamin.robin@bootlin.com>
> wrote:
> 
> > Hello Marta,
> >
> > On Thursday, March 19, 2026 at 9:58 AM, Marta Rybczynska wrote:
> > > On Thu, Mar 19, 2026 at 9:45 AM Benjamin Robin via
> > lists.openembedded.org
> > > <benjamin.robin=bootlin.com@lists.openembedded.org> wrote:
> >
> > > > I have just a slight implementation "detail" if we are using BitBake
> > > > fetcher. What is the license that we should use for the sources?
> > > > How to declare that in the recipes?
> > > >
> > > > Because the license of the repositories:
> > > >  - https://github.com/CVEProject/cvelistV5 : Their is none
> > > >  - https://github.com/fkie-cad/nvd-json-data-feeds/tree/main/LICENSES
> > > >    It looks like custom license.
> >
> > > The CVE project repo does not have a licence included, but it is covered
> > by
> > > https://www.cve.org/legal/termsofuse (the usage part). It is basically
> > MIT.
> > >
> > > NVD has the specific,  licence, the one that is in the repo. A warning on
> > > the
> > > needed disclosure sentence in all documentation.
> >
> > So for you, it is fine to declare that the CVE databases are MIT?
> >
> 
> CVE database is MIT
> NVD (so also FKIE) is custom

NVD license is apparently "cve-tou" which is available in Yocto.

> >
> > > AUTOREV isn't great here because it will re-fetch for each build. So if
> > > you're
> > > building multiple images or platforms (in CI or so), you will get
> > > potentially different
> > > results. cve-check has a set of variable to handle such use cases. You
> > pin
> > > to one specific release and do the whole checking with one single common
> > > version.
> >
> > Yes, that is why I initially pushed to use my custom fetcher that is
> > doing a git pull / shallow clone. With this fetcher I have a full control
> > on the update period.
> >
> > But if we want to use BitBake fetcher, an user could pin to a specific
> > version instead of using AUTOREV. But the user needs to to that manually.
> >
> >
> I agree with Richard that using a git fetcher (or other existing fetcher)
> is a better
> idea than developing a custom fetcher.

I am preparing a v5 of the patch series based on this RFC series, which is
going to use the BitBake fetcher.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com