fix(cyclonedx): duplicated entries in dependsOn

[d3vv3]

Description

Reproduce:

1. trivy -q image --format cyclonedx --output /tmp/postgresql.json --timeout 3600s --parallel 2 docker.io/bitnamilegacy/postgresql:15.4.0-debian-11-r45
2. cat /tmp/postgresql.json | jq ".dependencies[139].dependsOn"
3. Duplicated entries don't comply with the Cyclonedx BOM schema.

Related issues

• None

Related PRs

• None

Remove this section if you don't have related PRs.

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).

[CLAassistant]

All committers have signed the CLA.

[DmitriyLewen]

Hi @d3vv3,
Thanks for your work!

I checked the image. It contains three identical packages that differ only by the SPDXID suffix. This looks like a bug.

➜ cat .spdx-postgresql.spdx | jq ' .packages[] | select (.name=="org.postgresql:pljava")'
{
  "name": "org.postgresql:pljava",
  "SPDXID": "SPDXRef-Package-81b064a6dd4b165f",
  "versionInfo": "1.6.6",
  "supplier": "NOASSERTION",
  "downloadLocation": "NONE",
  "licenseConcluded": "NONE",
  "licenseDeclared": "NONE",
  "copyrightText": "NOASSERTION",
  "externalRefs": [
    {
      "referenceCategory": "PACKAGE_MANAGER",
      "referenceType": "purl",
      "referenceLocator": "pkg:maven/org.postgresql/[email protected]"
    }
  ],
  "filesAnalyzed": false
}
{
  "name": "org.postgresql:pljava",
  "SPDXID": "SPDXRef-Package-200e4c8a9fedcdb5",
  "versionInfo": "1.6.6",
  "supplier": "NOASSERTION",
  "downloadLocation": "NONE",
  "licenseConcluded": "NONE",
  "licenseDeclared": "NONE",
  "copyrightText": "NOASSERTION",
  "externalRefs": [
    {
      "referenceCategory": "PACKAGE_MANAGER",
      "referenceType": "purl",
      "referenceLocator": "pkg:maven/org.postgresql/[email protected]"
    }
  ],
  "filesAnalyzed": false
}
{
  "name": "org.postgresql:pljava",
  "SPDXID": "SPDXRef-Package-c30a860d16f62e1b",
  "versionInfo": "1.6.6",
  "supplier": "NOASSERTION",
  "downloadLocation": "NONE",
  "licenseConcluded": "NONE",
  "licenseDeclared": "NONE",
  "copyrightText": "NOASSERTION",
  "externalRefs": [
    {
      "referenceCategory": "PACKAGE_MANAGER",
      "referenceType": "purl",
      "referenceLocator": "pkg:maven/org.postgresql/[email protected]"
    }
  ],
  "filesAnalyzed": false
}

SPDXRef-Package-200e4c8a9fedcdb5 and SPDXRef-Package-c30a860d16f62e1b do not have any relationships with other components.

If this is not a bug, then we cannot simply drop the duplicates — we would “lose” some of the packages.
In that case, we need to include the SPDXID in Package.Identifier (similar to how we handle BomRef) to generate a correct unique identifier for identical packages that only differ by their SPDXID.

Regards, Dmitriy

[d3vv3]

Hi @DmitriyLewen
Very insightful!

I added the SPDXID to maintain uniqueness. I think the previous commit is still important to ensure the output schema is valid.

What do you think?

[DmitriyLewen]

I think the previous commit is still important to ensure the output schema is valid.

In this case, we must not prioritize a “valid-looking” SBOM over correct package detection.
People trust our SBOM, and if we simply drop duplicates — and users rely on that — it can lead to serious issues.

So we shouldn’t remove duplicated packages.
Instead, we need to fix the root cause and properly handle them, rather than hiding or deleting them.

I added the SPDXID to maintain uniqueness

About SPDXID — this field helps us see that packages are different (in pkgIdentifier.UID).
But we still have a problem with dependencies.

For example, in the SBOM we have:
• pkgA 1.0.0 (SPDX-1) -> pkgB 2.0.0 (SPDX-2)
• pkgA 1.0.0 (SPDX-3) -> pkgB 2.0.0 (SPDX-4)

For the SPDX-1 and SPDX-3 packages, the DependsOn entry will be the same: [email protected].
This means that one of the packages (SPDX-2 or SPDX-4) will be “lost” when we build the dependency graph.

This situation is similar to the problem we had with Maven modules:
#7879

I think we should use bomRef / SPDXID as the Package.ID.
Then, during decoding, we’ll have a clear mapping between the SBOM component and the resulting Package,
and we’ll be able to build relationships between packages more reliably.

We already discussed about BOMID (#9597 (comment))
We can add this field and use for bomRef|SPDXID
@knqyf263 wdyt?

[d3vv3]

Hi @DmitriyLewen , thanks for your input.

Then, as for the invalid cyclonedx format, I think trivy should fail and exit when there al duplicated entries in a dependsOn array. What do you think?

For the root cause of the issue, thanks for the explanation. I see that it would be a huge refactor and it would sadly escape my golang skills.

[DmitriyLewen]

No problem!
Thank you for helping uncover this issue and for your attempt to solve it!

I’ve created #9815 for it.

[github-actions]

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