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"
},
```

On Thursday, February 20, 2025 at 3:31:38 PM UTC+5:30 Felix Moessbauer wrote:

From: Christoph Steiger <christop...@siemens.com>

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