Skip to main content
YahyaYozo
YahyaYozo
Associate
March 4, 2026
Solved

Best practices for generating SBOM

  • March 4, 2026
  • 2 replies
  • 542 views

Hi everyone,

I am trying to generate a professional SBOM for my project.
I have a few questions regarding the best workflow:

  • Tooling & Detection: What the best tool to generate the SBOM.
    I tried using ScanCode, but it didn't find any component in my project (e.g., FreeRTOS). I had to manually add .about files to the folder to get results. Is there a better tool that can generate the SBOM with minimal manual intervention?

  • ST Cube SBOM : The Cube MCU packages contain dozens of libraries (FatFS, FreeRTOS, USB_Host, etc.). If my project only uses FatFS, the package JSON still lists everything. Do I have to manually extract the components I use from the ST JSON? how to get use of the ST SBOM?

I’d love to hear if anyone has a script or a specific toolchain that automates this without the manual "copy-paste" from the ST manifests

 
Thank you!
Yahya

 

 

Best answer by Dor_RH

Hello Yahya,

For our firmware packages we use Black Duck to generate the SBOM.

The ST Cube SBOM is a reference to help you accurately describe ST‑provided components; it does not replace your project SBOM. You can reuse the needed information from ST’s SBOM (component name, version, license, origin) for the libraries you actually use, instead of recreating it.

I hope my answer has been helpful. When your question is resolved, please mark this topic as the solution. This will help others find the answer more quickly.

Thank you for your contribution.

Best regards,
Dor_RH

2 replies

D
Dor_RHBest answer
ST Employee
March 12, 2026

Hello Yahya,

For our firmware packages we use Black Duck to generate the SBOM.

The ST Cube SBOM is a reference to help you accurately describe ST‑provided components; it does not replace your project SBOM. You can reuse the needed information from ST’s SBOM (component name, version, license, origin) for the libraries you actually use, instead of recreating it.

I hope my answer has been helpful. When your question is resolved, please mark this topic as the solution. This will help others find the answer more quickly.

Thank you for your contribution.

Best regards,
Dor_RH

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Dor_RH
S
sbom-expert
Visitor II
July 14, 2026

Hi Yahya,

On the first question: ScanCode works off license texts and package manifests, so it struggles with embedded C/C++ where components like FreeRTOS are just vendored source folders with no manifest. That's why you had to add .about files by hand. Take a look at lynkctl (disclosure: I work on it at Interlynk) or bomtique, which is open source. Both are built for embedded projects and fingerprint vendored source directly, so FreeRTOS and similar components get picked up without any manual annotation.

 

On the ST Cube question: the package JSON lists everything in the Cube distribution, not what your firmware actually uses, so copying from it by hand will always overstate your SBOM. The way to solve this automatically is with a tool that analyzes your build output, the linker map file and the binary itself, to determine which libraries actually made it into the image. If only FatFS is linked in, only FatFS shows up in the SBOM. That gives you an accurate list without touching the ST manifests at all.

 

Hope that helps.

Terms & ConditionsAccessibility statement