fix(sbom): detect main OS and ignore pkgs for other OSes

[DmitriyLewen]

Description

Trivy doesn't currently support multiple OSes.
To avoid flaky packages - we need to sort found OS and select only one of them (packages for other OS should be ignored).

Sorting order:

1. Take the OS with the largest number of packages.
2. If OSes contain same number of packages, we compare them by SPDXID/BOMRef.

example flaky pkgs (nginx-helm.json file(see #5812 (comment)):

➜  trivy sbom nginx-helm.json --quiet --format json --list-all-pkgs | jq '.Results[0].Packages | length'
128
➜  trivy sbom nginx-helm.json --quiet --format json --list-all-pkgs | jq '.Results[0].Packages | length'
159

New Field

This PR adds new SPDXID field for Package.Identifier.
We populate this field from SPDX files, similar to BOMRef for CycloneDX files.

Related issues

• Inconsistencies on SBOM vulnerabilities scanning #5812 (comment)

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

I think they are not orphan packages. They belong to another OS. Since we don't support multiple OSes, we should ignore them. What do you think?

[DmitriyLewen]

hmm... you're probably right, but then we must maintain order in order to exclude uncertainty (I mean that every time we scan a file with multiple OSes, we should take only the first one found)

[knqyf263]

then we must maintain order in order to exclude uncertainty

Yes, we keep OSes as an array instead of picking up the first one, sort them somehow and pick up one of them deterministically.

trivy/pkg/sbom/io/decode.go

Lines 121 to 130 in f7720f5

	if m.osID != uuid.Nil {
	onceMultiOSWarn()
	continue
	}
	m.osID = id
	sbom.Metadata.OS = &ftypes.OS{
	Family: ftypes.OSType(c.Name),
	Name: c.Version,
	}
	continue

[DmitriyLewen]

pick up one of them deterministically.

We can take OS with the most related packages.
wdyt?

[knqyf263]

We can take OS with the most related packages.

Sounds good. But we must consider cases where several OSes have the same number of packages.

[DmitriyLewen]

But we must consider cases where several OSes have the same number of packages.

Name fields can be same. So it looks like we need to use SPDXID to sort these OSes (and BomRef for CycloneDX).

[DmitriyLewen]

@knqyf263 wdyt about using BOMRef for SPDXID?
Name (I mean BOMRef) can be confusing (because BOMRef is field from CycloneDX), but using two fields for similar fields is also wrong

[DmitriyLewen]

I thought about it again.
Using two same fields doesn't make sense and may lead to bugs.
So i used PkgIdentifier.BOMRef for SPDXID in 964f16a.

[knqyf263]

How about the case where the input is CycloneDX, and the output is SPDX? I'm concerned BOM-Ref is mistakenly used as SPDX-ID, as we are currently trying to reuse the same ID after #7340.

[DmitriyLewen]

you are right. After #7340 it can be problem.
I thought about adding SPDXID field (68abc78)
But it looks as bad way.

What if we will use struct with type + ref/ID. e.g.:

	type BomID struct {
		ID   string // UUID/purl/SPDXID
		Type BomType // cyclonedx/spdx
	}

If BomID.Type == outputType => save ID, otherwise - create new ID.

[DmitriyLewen]

github.com/spdx/tools-golang returns Package SPDX identifier without SPDXRef- prefix.
On the one hand, docs say: "SPDXRef-"[idstring] where [idstring] is a unique string containing letters, numbers, ., and/or -. (https://spdx.github.io/spdx-spec/v2.3/package-information/#72-package-spdx-identifier-field). So id is text after SPDXRef-.
On the other hand, BOMRef will not match string from SPDXID field.

[github-actions]

This PR is stale because it has been labeled with inactivity.

[github-actions]

This PR is stale because it has been labeled with inactivity.