@jamesh we need the SBOM for a customer of ours, that is in the transitioning phase of being EU CRA compatible.
He requires all his suppliers to provide SBOM for all provided software.
All our information we have so far (consulting and customers, searching the web) seem to indicate that a SBOM will be necessary to be CRA compatible.
For example see following medium post with pointers to SBOM requirements: https://medium.com/@interlynkblog/sbom- ... 87090c80e3
I certainly agree that the SBOM for an entire OS is a moving target and would change with every update and every single packet install.
I think a SBOM of the .iso file should suffice in most circumstances as a "baseline" - as new vulnerabilities and problems would creep up the auditing softwares (e.g. Fossa / Fossology / ...) would alert the user about issues and they could fix/update the software.
However as you seem aware this will be a requirement in the future for many IoT and embedded devices.
This particular customer just wishes to start the process of getting the SBOM information early so he will be able to self certify sooner and thus have a unique selling point against his competitors.
I think the .info unfortunately does not contain any licensing information which typically is included in a SBOM file and is required for CRA.
It also seems to lack some software projects: it contains no linux kernel information, I think some bootloader information is missing as well.
The "apt list"/dpkg approaches will also be missing licensing information, they also require a running system - which is workable but not optimal for us.
Do you see any path forward for getting to the SBOM of the Raspberry Pi OS?
You mention that you have this in the backlog - when do you think you will be able to provide the SBOM for the various Raspberry Pi products?
He requires all his suppliers to provide SBOM for all provided software.
All our information we have so far (consulting and customers, searching the web) seem to indicate that a SBOM will be necessary to be CRA compatible.
For example see following medium post with pointers to SBOM requirements: https://medium.com/@interlynkblog/sbom- ... 87090c80e3
I certainly agree that the SBOM for an entire OS is a moving target and would change with every update and every single packet install.
I think a SBOM of the .iso file should suffice in most circumstances as a "baseline" - as new vulnerabilities and problems would creep up the auditing softwares (e.g. Fossa / Fossology / ...) would alert the user about issues and they could fix/update the software.
However as you seem aware this will be a requirement in the future for many IoT and embedded devices.
This particular customer just wishes to start the process of getting the SBOM information early so he will be able to self certify sooner and thus have a unique selling point against his competitors.
I think the .info unfortunately does not contain any licensing information which typically is included in a SBOM file and is required for CRA.
It also seems to lack some software projects: it contains no linux kernel information, I think some bootloader information is missing as well.
The "apt list"/dpkg approaches will also be missing licensing information, they also require a running system - which is workable but not optimal for us.
Do you see any path forward for getting to the SBOM of the Raspberry Pi OS?
You mention that you have this in the backlog - when do you think you will be able to provide the SBOM for the various Raspberry Pi products?
Statistics: Posted by Deadolus — Tue Jul 09, 2024 9:21 am