Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12

[Leo_dev]

Hi NXP team,

We are using LSDK-25.12_DEBIAN-13_LF-6.12.20 with FlexBuild to build a Debian-based product image for the i.MX8MP. To support our vulnerability assessment and conformity assessment under RED / EN 18031, we need to establish a repeatable process for identifying the software components and known vulnerabilities in the final shipping image.

We have reviewed the FlexBuild 25.12 source tree and found that:

• SBOM-flexbuild.spdx.json contains only a single package entry describing the FlexBuild tool itself, rather than the contents of a built image.

• SCR.txt is an SDK-wide Software Content Register and does not represent the components actually installed in a specific target image.

• We could not identify any image-specific SBOM or CVE manifest generation mechanism in flex-builder.

Based on these findings, could you please clarify the following?

1. Does NXP currently provide an official or recommended method for generating an image-specific SBOM, such as a per-image SPDX document, from a FlexBuild Debian build?

   If this capability is planned, could you indicate the target release or expected availability?

2. Does NXP currently provide or plan to provide Vigiles integration for the Debian Linux SDK / FlexBuild, equivalent to the meta-timesys workflow available for Yocto?

   If direct integration is not available, is manually creating and importing a CSV manifest, as described in the Vigiles FAQ, still the recommended approach for FlexBuild-based images?

3. What are the official sources for security advisories, CVE applicability information, and security fixes for the following components included in this release?

   • linux-imx lf-6.12.20-2.0.0

   • uboot-imx lf-6.12.20-2.0.0

   • imx-atf

   • imx-optee-os

   • NXP-provided firmware and binary packages, such as DDR, HDMI, VPU, and wireless firmware

   For example, should we rely on NXP security advisories, fixed-CVE lists in release notes, specific maintained Git branches, or another official source?

4. What is the maintenance and security-update lifecycle for LSDK-25.12 and its associated lf-6.12.20 BSP components?

   In particular:

   • For how long will security fixes be provided for this release?

   • Which branches or repositories should be monitored for backported fixes?

   • What upgrade cadence does NXP recommend for products requiring an ongoing vulnerability-management process?

Our goal is to establish a repeatable and evidence-based SBOM and CVE assessment process for the actual shipping image. References to any official documentation, supported tools, or recommended procedures would be greatly appreciated.

Thank you.

[Chavira]

Hi  @Leo_dev,

Thank you for contacting NXP Support.

Unfortunately, Debian is considered by NXP to be a proof of concept distribution and therefore does not receive the same level of support, validation, and long term maintenance as our Yocto based BSP releases.

In fact, during boot, Debian displays a disclaimer indicating that the software is provided without any guarantee of functionality or support. As a result, issues encountered on Debian may not receive the same level of investigation or validation as those reproduced on a Yocto based image.

For production development and fully supported use cases, we recommend using the Yocto BSP provided by NXP.

All of our publicly available source code is hosted on GitHub and can be accessed through the following organization:

https://github.com/nxp-imx

Best regards,
Chavira

[Leo_dev]

Hi @Chavira ,

Thank you for the clarification regarding the support status of the Debian distribution.

We understand that the Debian integration itself is provided as a proof of concept. However, our remaining questions concern the underlying BSP components, which as far as we can tell are the same repositories and branches consumed by the Yocto BSP releases:

- linux-imx (lf-6.12.20-2.0.0)
- uboot-imx (lf-6.12.20-2.0.0)
- imx-atf
- imx-optee-os
- NXP-provided firmware binaries (DDR, HDMI, VPU, wireless)

Could you please confirm, independently of which build system or root filesystem is used:

1. Are security fixes for these components delivered through the lf-* release branches, and is the fixed-CVE information published in the Yocto BSP release notes the authoritative source for CVE remediation status of these components?

2. For the lf-6.12.20 generation specifically, which subsequent lf-* releases or branches should we monitor to obtain security fixes applicable to these components?

3. What is the maintenance duration for the lf-6.12.20 BSP component generation, and what upgrade cadence does NXP recommend for products that must maintain an ongoing vulnerability-management process?

We are not asking NXP to support or validate our Debian-based image; we only need to identify the official sources of security-fix information for the NXP BSP components themselves, so that we can track and apply them in our own maintenance process.

Thanks

[Chavira]

Hi @Leo_dev,

1. Yes. Security fixes for NXP BSP components are typically delivered through the official lf- release branches. The i.MX Linux BSP release notes (RN00210) and associated manifests/change logs are the primary NXP references for tracking integrated fixes and CVE remediation status

2. For the LF6.12.20 generation, monitor subsequent BSP releases such as LF6.12.34_2.1.0, LF6.12.49_2.2.0, LF6.18.2_1.0.0, and newer releases, as security and maintenance fixes are carried forward into these branches.

3. For products requiring ongoing vulnerability management, NXP's recommended practice is to regularly track and evaluate newer BSP maintenance and quarterly releases to obtain security updates and bug fixes