json SPDX invalid format

[jonathongardner]

What happened:
When generating an SPDX json SBOM the format is invalid (missing required copyrightText in packages and files and required described package)

What you expected to happen:
To generate a valid SPDX json sbom.

• "copyrightText": "NOASSERTION" for all package and files
• This is a little harder to explain (and i might misunderstand the SPDX) but for the alpine image i would expect an extra package entry for the image being scanned, something like:

{
 "SPDXID": "SPDXRef-1",
 "name": "alpine-latest",
 "licenseConcluded": "NOASSERTION",
 "downloadLocation": "https://docker.io/alpine/latest/...",
 "copyrightText": "NOASSERTION",
 "filesAnalyzed": false,
 "licenseDeclared": "NOASSERTION"
},

Than in relationship i would expect something like:

"relationships": [
{
 "spdxElementId": "SPDXRef-DOCUMENT",
 "relationshipType": "DESCRIBES",
 "relatedSpdxElement": "SPDXRef-1"
},
{
 "spdxElementId": "SPDXRef-1",
 "relationshipType": "CONTAINS",
 "relatedSpdxElement": "SPDXRef-20dc20cbb6dbea6"
},
...

SPDXRef-1 should than have a relationship "CONTAINS" for every package in the SBOM (the describe one is required in the docs, you can see below, the extra "CONTAINS" im not 100% about but thats how i interpret the docs b/c the package/image we are describing (alpine:latest) contains all those packages in the file (alpine-baselayout, etc))

How to reproduce it (as minimally and precisely as possible):

docker run --rm -it anchore/syft:latest alpine:latest -o spdx-json

Anything else we need to know?:
To validate the SPDX file I used https://tools.spdx.org/app/validate/ and I used documentation here to confirm.

• copyrightText in the docs Section 3.17 and Section 4.8
• Missing "Described" Package (This was missing in the SPDX tag/value format too, i think) in the docs Section 7.1 the first value in the table says "this [DESCRIBE] is a logical relationship to help organize related items within an SPDX document that is mandatory if more than one package or set of files (not in a package) is present"

Environment:

• Output of syft version: syft 0.45.1
• OS (e.g: cat /etc/os-release or similar): docker image (anchore/syft:latest)

[kzantow]

Hi @jonathongardner there definitely sounds like room for improvement here. One thing to note: we have had some discussion with various people (I'm relaying this 3rd hand), including folks on the SPDX team. There was some guidance to actually generate a separate SBOM to represent the image, or something along those lines. It has been a little difficult to nail down exactly how it should, or could, be represented in a single SPDX file. I believe other tools may use the approach you indicated, using CONTAINS relationships with a single "top-level" package with a DESCRIBES relationship to the document; but this does raise some further questions -- the biggest of which is: I don't think there's a definitive way to specify that a package is a container image. Is there something that you've found in the spec that help here?

[seabass-labrax]

I can confirm that there is a change for the upcoming 2.3.0 release of the SPDX specification which adds just this! There'll be a new 'package purpose' field, of which container image is one option. See spdx/spdx-spec#622 for the latest draft of this. SPDX 2.3.0 will probably be published in the next few weeks. Hope this helps; please let me know if I've missed anything 😃

[kzantow]

@seabass-labrax that is excellent! This definitely seems like something we would love to support when the new spec is published.

[jonathongardner]

@kzantow so this isn't just docker images, i would expect it on any image i scan with Syft (docker was just the easiest to repeat). With that I was under the idea that "anything" could be a package in SPDX, so what syft calls an image SPDX just calls that a package b/c its some code that has other packages and some license attached to it, etc. But i am no SPDX expert so i could be wrong.

I think the purpose package field would be helpful but not necessary.

I do agree though its hard to nail down what exactly to do b/c I've seen different tools handling it differently.

[kzantow]

@jonathongardner agreed; apologies if I misspoke but yes: any image scan. The main problem without having a purpose field is properly reading SPDX documents: we would not have a definitive way to identify a single image was scanned, which the document represents - it could be a filesystem, or a Go binary, etc..

[rjb4standards]

I've heard that copyright and license elements will be optional in V 2.3.

[spiffcs]

@jonathongardner thanks for filing the issue here! It does look like with the imminent release of v2.3 this field will soon be optional. Patches are welcome for the current version, but we'll wait for the standard to roll forward here and then update our validation tools based on the latest schema. Closing for until 2.3 drops.