| Message ID | 20250220095944.114203-1-felix.moessbauer@siemens.com |
|---|---|
| Headers | show |
| Series | SBOM Generation for isar | expand |
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 <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
> 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? Your assumption is correct. Nothing stops you from adding additional external references after generation of the SBOM. This script only considers information available in the dpkg databases, which only contains a link to the homepage afaik. If you know of other things in the packages that could be added to the externalReferences field let us know so we can incorporate it. > > 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 <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 > > -- > You received this message because you are subscribed to a topic in the > Google Groups "isar-users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/ > isar-users/8L-CF4BJY0I/unsubscribe <https:// > eur01.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgroups.google.com%2Fd%2Ftopic%2Fisar-users%2F8L- > CF4BJY0I%2Funsubscribe&data=05%7C02%7Cchristoph.steiger%40siemens.com%7C38fbfcce41dc4115eb7708ddcff60649%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638895377762504213%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZJLWNsyTk9pxvt0sF6yuQ5TBcpvp%2B1Wet%2FUFss%2BFnnQ%3D&reserved=0>. > To unsubscribe from this group and all its topics, send an email to > isar-users+unsubscribe@googlegroups.com <mailto: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 <https:// > eur01.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fisar-users%2F39f0bde3- > fac8-48a9- > a393-2566c17831e9n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cchristoph.steiger%40siemens.com%7C38fbfcce41dc4115eb7708ddcff60649%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638895377762533091%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0DSm3jmR%2F1tI0a%2Bct3D2juZGQ4UmmnyNh%2FwHeEJX8u0%3D&reserved=0>.
On 31.07.25 07:38, Syeda Shagufta Naaz wrote: > 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? At this stage, better use your time to contribute those missing entries to the original package data. That's more sustainable. Jan
From: Christoph Steiger <christoph.steiger@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