[Request] Ability to customize top level metadata

[idunbarh]

What would you like to be added:

Users are looking to create SBOMs that meet the NTIA Minimum Fields requirements. Users typically do this through a two step process.

1. Generate an SBOM with syft
2. Augment it with additional top level data
   • Who the top level component supplier is
   • What license
   • etc ...

This second step often requires a lot of custom scripting with jq, python or using a tool like sbomasm.

This feature request is to include a method to specify user defined top level metadata as options when calling syft or through a configuration file.

The files proposed are ...

• Document
  • author
  • supplier
  • lifecycle
• Top Level Component
  • author
  • supplier
  • name
  • version
  • description
  • copyright
  • repository
  • cpe
  • purl
  • hash
  • license

Why is this needed:

Most of the fields required for NTIA Minimum Field compliance need to be defined by the creator of the software product and there is no easy way for syft to discover their values. Allowing users to specify these field in a syft call reduces the steps required to create a "complete" SBOM.

Additional context:

This is a recommendation that originates from the CISA SBOM Generation Reference Implementation Tiger Team. Today https://github.com/interlynk-io/sbomasm is being used in the reference implementations.

CC/ @joshbressers

[kzantow]

This is related to: #3098

[kzantow]

I spoke with @wagoodman about this and we think a reasonable path forward is the following:

• Add a pkg.Package to the source.Description, which is used to fill in any additional top-level package data when output in other formats; there will be overlap with the source-name and source-version, which were effectively setting these values on the package (I recommend deprecating the existing source.name/version, and setting both with --source-name/version flags)
• To enable Option to set PackageSupplier in root of SPDX document generated by CLI #3098, specifically, add a new pkg.Supplier struct with direct reference on the pkg.Package to it
• Other fields we support here could be added, such as Copyright
• We would support setting any top-level package elements here, not anything that ends up in the metadata sections

We believe that the values provided to configure this package have a moderate likelihood to be dynamic, such as the --source-version and being configurable from the CLI is important rather than only via configuration file / environment variables.

Some other suggestions for the CLI

Add many unique flags:

syft --source-name asdf --source-supplier-type org --source-supplier-name blah --source-supplier-url https://... myimage:latest

Use JSON:

syft --source-name asdf --source-package '{"supplier":"{"type":"org","name":"blah"}}' https://... myimage:latest

Multiple args:

syft --source-license id=MIT --source-supplier org=name --source-supplier url=https://...

Something more complicated than the suggestion below:

syft --source-package name=asdf,supplier{type=org,name=blah,url=https://...} myimage:latest

... my preferred idea is to consolidate based on an object structure to a format like <field>(.<field>)*=<value>(,<field>(.<field>)*=<value>)*. For example:

syft --source-package name=asdf,supplier.type=org,supplier.name=blah,supplier.url=https://... myimage:latest

There will likely be some overlap with the existing name/version options e.g. these may result in predominantly the same thing:

syft --source-name asdf --source-package name=asdf

This could also be populated through a YAML configuration such as:

source-package:
  name: asdf
  supplier:
    type: org
    name: blah
    url: htpts://...

If anyone has some prior art that might help inform the direction here, please let us know!