SBOM support

[TobiasNils]

Hi everyone,
first of all I want to express my appreciation for this repo and the effort spent on maintaining the recipes.
We are currently preparing to use the iot2050 as the main platform for several industrial deployments and using this repo as a base for our custom OS.
In that context and with the EU Cyber Resilience Act's SBOM requirement on the horizon, I was wondering if and on which timeline you are planning to pull SBOM support into a release.
I have tried to find roadmap-related info regarding the iot2050 specifically, but have not found any. If you discuss such things some place else, please point me in that direction.

On master, SBOM generation is included already with the update of upstream isar and this compiles fine for me overall. So I'm basically just wondering if I should be wary of basing my own layers on master and if I can contribute somehow to make this feature land in a release.

[jan-kiszka]

Thanks for raising this. Colleagues need to comment on the release plans, though.

Regarding the SBOM generation itself, you likely already figured out that this is coming via Isar and from there via debsbom. The latter is still comparably fresh, and we are definitely interested in learning about where it already fits further users' needs or where there might be gaps / room for improvements. So far, the tool is primarily receiving internal feedback, though this is starting to change, not only since this talk.

[huaqianli]

Thanks for raising this.

We have already planned the overall SBOM-related work for the whole meta-iot2050 project. As Jan mentioned, SBOM generation is primarily coming from upstream Isar and debsbom, and we are actively following that development.

At the same time, we are very interested in understanding your expectations and real-world requirements. Feedback like yours is extremely valuable to us in evaluating maturity, identifying gaps, and prioritizing improvements before integrating this into a formal release.

Regarding the release timeline, we are currently aligning internally and will share more concrete plans once they are finalized. However it won't be too long.

Please feel free to share more details about your use cases or expectations around SBOM — that would help us a lot.

[TobiasNils]

Thanks for the quick feedback.
Let me have a closer look at the debsbom package and the talk, then I'll be back with more details from our end.

[TobiasNils]

Thanks for the link to the talk, very nice and helpful for context.
As for our interest in the topic, the first and foremost motivator is of course the regulation and compliance aspect, which would be especially the license clearing and providing access to sources and license texts where required. Apart from that there is mainly the security aspect, in that we want to ship a secure system and be able to react fast to the discovery of new vulnerabilities which could affect our customers.

Our deployments won't all be in the EU, so the CRA is not necessarily the applicable regulation, but to cover our bases from the start we want to automatically generate an SBOM for a release and based on that and the package versions gather the corresponding licenses (including their texts) and required sources to keep as artifacts.

So , pretty much aligned with the motivations mentioned in the talk, with the restriction that as an "end-user" the modeling of a debian system in and of itself is not our focus. I do very much like the resulting tree representation though which allows analyses like debsbom sec-scan --with-paths-to-root to pinpoint why a package is even there in the first place and where it needs to be patched. The feature-set of the debsbom package seems really useful in general.

My remaining questions then revolve mostly around how and to which extent this will be integrated here and how it interacts with custom recipes, especially ones defined with inherit dpkg-raw with no link to an upstream debian snapshot. Many of the recipes in the meta-iot2050 project also show up without concluded licence or suppliers in spdx, which I thinks is expected at this point but it would be great to know what this is planned to be represented.
We are also already generating SBOMs for our production software, which then runs in a container on the OS built with meta-iot2050 layers, so we will also have SBOMs for those containers.
Bringing all of that together is the next challenge, which I would not expect to be solved by Isar integrating debsbom. But it would be great to be able to establish a link in the debsbom-generated SBOM from a isar-recipe to the version of a binary it installs, so that I can then provide the SBOM for that binary separately at least, if not merged into the tree.

Hope that helps, please feel free to ask back.

[Urist-McGit]

Hi, one of the co-maintainers of debsbom here.

My remaining questions then revolve mostly around how and to which extent this will be integrated here and how it interacts with custom recipes, especially ones defined with inherit dpkg-raw with no link to an upstream debian snapshot.

Is this a problem mostly related to the downloading of the source packages? We have a plugin infrastructure for download resolving of packages. This allows you to use packages not available in snapshot.debian.org in the debsbom workflows. There is a simple example here, we also have some internal implementations which I might be able to share if there is interest.

Many of the recipes in the meta-iot2050 project also show up without concluded license or suppliers in spdx, which I thinks is expected at this point but it would be great to know what this is planned to be represented.

For the license part: this is a known problem unfortunately, and not one debsbom can solve unless we also want to provide "proper" license scanning functionality. There is talks with the people in Debian how to improve the situation, but I think a solution is still far off. In the meantime you will need to acquire that license information from a separate source and add it to the SBOM manually as needed.

For the missing suppliers: the philosophy of debsbom is to rely solely on the package metadata. They should show up once this metadata is available in the packages. If they are missing for packages provided by meta-iot2050 we should add them.

But it would be great to be able to establish a link in the debsbom-generated SBOM from a isar-recipe to the version of a binary it installs, so that I can then provide the SBOM for that binary separately at least, if not merged into the tree.

Correct me if I understood you wrong, but what you want is the SBOM as currently generated by debsbom with additional information for each packages, e.g. for a source package which files are in it and how exactly they are licensed. So, more or less, a package SBOM, which can then also be linked in the system SBOM. There have been ideas floating around to implement such an SBOM generator in the Debian packaging workflow and to distribute them directly in the system somewhere. Thinking further this could be picked up by debsbom automatically, and then included and linked appropriately.

The feature-set of the debsbom package seems really useful in general.

Thank you for your feedback! We open-sourced all of this since we thought it might be useful to other people, so hearing what other people think is very appreciated.