Hi, Based on the patch, it seems that the externalReferences field is added when the homepage is available for the package. Would it be feasible to use our own scripts to populate the externalReferences field for the packages where it is currently missing? For the two packages considered below, we can see that the externalReferences field is added for one component (apparmor) and missing from the other (adduser). ``` { "bom-ref": "CDXRef-adduser", "description": "add and remove users and groups", "name": "adduser", "purl": "pkg:deb/debian/adduser@3.134?arch=all", "supplier": { "contact": [ { "email": "adduser@packages.debian.org" } ], "name": "Debian Adduser Developers " }, "type": "library", "version": "3.134" }, { "bom-ref": "CDXRef-apparmor", "description": "user-space parser utility for AppArmor", "externalReferences": [ { "comment": "homepage", "type": "website", "url": "https://apparmor.net/" } ], "name": "apparmor", "purl": "pkg:deb/debian/apparmor@3.0.8-3?arch=amd64", "supplier": { "contact": [ { "email": "pkg-apparmor-team@lists.alioth.debian.org" } ], "name": "Debian AppArmor Team " }, "type": "library", "version": "3.0.8-3" }, ``` Thanks, Syeda Shagufta Naaz syedashagufta.naaz@siemens.com On Thursday, February 20, 2025 at 3:31:38 PM UTC+5:30 Felix Moessbauer wrote: From: Christoph Steiger This patch would add SBOM generation support for isar. We already generate a manifest as part of the do_rootfs task which is used by some people internally at Siemens to create SBOMs, but it has a proprietary format and is not documented. It also has become apparent that more information than in the manifest is required. To create the SBOMs we parse the dpkg status file in a given image and have some python scripts to build a valid SBOM for the two standard formats (CycloneDX and SPDX). The python scripts are a very minimal implementation to generate SBOMs, as all other tools have heavier dependencies that are not packaged in debian. As we also require only a small subset of these libraries (we only generate a specific version and format, using also only a small part of the data structures) I chose to quickly implement this myself. The current implementation also emits source package information in the SPDX format. Unfortunately the CDX standard does not allow to map the relationship between a debian source and binary package in a satisfactory way, so I omitted it for now. There is talks internally about how to represent this relationship, but it is probably a good idea to leave it empty for now. TODOs/next steps: - license/copyright parsing: debian has no machine-readable format for these, but they are very valuable for clearing purposes - tigther bitbake integration: if we hook into each recipe we could add more information and correctly represent vendor packages Please tell me what you think and how we could land SBOM generation here :-) Christoph Steiger (1): meta: add CycloneDX/SPDX SBOM generation meta/classes/create-sbom.bbclass | 49 ++++ meta/classes/image.bbclass | 2 + meta/lib/sbom.py | 446 +++++++++++++++++++++++++++++++ meta/lib/sbom_cdx_types.py | 82 ++++++ meta/lib/sbom_spdx_types.py | 95 +++++++ 5 files changed, 674 insertions(+) create mode 100644 meta/classes/create-sbom.bbclass create mode 100644 meta/lib/sbom.py create mode 100644 meta/lib/sbom_cdx_types.py create mode 100644 meta/lib/sbom_spdx_types.py -- 2.39.5 -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/39f0bde3-fac8-48a9-a393-2566c17831e9n%40googlegroups.com.