Create a package record for the artifact an SBOM described when creating a SPDX SBOM

[eliaslevy]

What would you like to be added:
Syft should create an SPDX Package to represent the artifact an SBOM describes when creating a SPDX SBOM.

Why is this needed:
The SPDX spec is silent on whether a package should be created within the SPDX document to represent the artifact or component associated with the SBOM. If the artifact is not modeled as a SPDX package at the root of the SPDX relationship tree, there is no place to record artifact metadata such as its digest, author, license, download location, etc.

For comparison, CycloneDX is explicit about this issue. The metadata.component field specifies the component that the SBOM describes, and it has the same schema as the dependent components, so you specify the artifact's digests (hashes), author, licenses, cpe, purl, etc.

Syft does not create a SPDX package for the artifact it analyzes. Thus, it does not record pertinent information, such as the author, digest, or license of the artifact. That means it can be difficult to identify what artifact an SBOM belong to and perform SBOM merging.

Additional context:
When creating a CyclonDX file Syft will fill out some of the metadata.component fields, although it fails to fill in the hashes. If the artifact is a container image, it will fill out metadata.component.version with the container digest (e.g., sha256:<digest>).

[kzantow]

Hi @eliaslevy we are planning on doing this -- there's definitely some overlap with: #1518

[eliaslevy]

@kzantow yes, this issue is a superset of #1518. The same rationale applies to other artifacts beyond container images. It'd be nice if the SPDX spec were more prescriptive about this.

[oej]

I agree that this is needed - even without containers. When creating an SBOM of a python project I want to be able to add metadata in the config file and/or command line - or if I create an SBOM within a build system based on a linux distro I want to document which system and when.