Invalid SBOM generated - non-unique dependencies

[LesSyner]

Description

SBOM generated (in CycloneDX format) is invalid whewn validated against 1.6 schema since dependencies are not unique (first dependence ref is repeated 2 times)

Desired Behavior

To generate proper SBOM which is valid according to schema.

Actual Behavior

Improper SBOM which is invalid, has repeated dependencies refs.

Reproduction Steps

1. trivy image --no-progress --format cyclonedx --scanners license --output result.json cr.fluentbit.io/fluent/fluent-bit:2.0.5
2. cyclonedx validate --input-file result.json

Validation failed:
Found duplicates at the following index pairs: "(0, 1)"
http://cyclonedx.org/schema/bom-1.6.schema.json#/properties/dependsOn
On instance: /dependencies/1/dependsOn:
[
        "028c75ed-3fb5-40bf-88cc-e3dc08a1d457",
        "028c75ed-3fb5-40bf-88cc-e3dc08a1d457",

Unable to validate against any JSON schemas.
BOM is not valid.

Target

Container Image

Scanner

License

Output Format

CycloneDX

Mode

Standalone

Debug Output

2025-01-22T09:19:32+01:00	DEBUG	No plugins loaded
2025-01-22T09:19:32+01:00	DEBUG	Default config file "file_path=trivy.yaml" not found, using built in values
2025-01-22T09:19:32+01:00	DEBUG	Cache dir	dir="/Users/leszek/Library/Caches/trivy"
2025-01-22T09:19:32+01:00	DEBUG	Cache dir	dir="/Users/leszek/Library/Caches/trivy"
2025-01-22T09:19:32+01:00	DEBUG	Parsed severities	severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-01-22T09:19:32+01:00	DEBUG	Ignore statuses	statuses=[]
2025-01-22T09:19:32+01:00	DEBUG	[pkg] Package types	types=[os library]
2025-01-22T09:19:32+01:00	DEBUG	[pkg] Package relationships	relationships=[unknown root workspace direct indirect]
2025-01-22T09:19:32+01:00	INFO	[license] License scanning is enabled
2025-01-22T09:19:32+01:00	DEBUG	Enabling misconfiguration scanners	scanners=[azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan-json terraformplan-snapshot]
2025-01-22T09:19:32+01:00	DEBUG	Initializing scan cache...	type="fs"
2025-01-22T09:19:35+01:00	DEBUG	[image] Detected image ID	image_id="sha256:5fdd67ca84c7c620771ea2eb965d5f4d1f5f4c5a15140cbac62b7ef1d46ee4f3"
2025-01-22T09:19:35+01:00	DEBUG	[image] Detected diff ID	diff_ids=[sha256:9fce6bd02a21068901a96271d3160c2ce9da9c83c152eeb22312f65226da108c sha256:00c562532b203116c721c11aee6fe1fe50b5e2068cee2c343c1df1050a866b3e sha256:e83d4114481dc897d49d5a9a8b68bf71c4f08f1a5c1adff44603c56b958fed53 sha256:dfc1925298ca80fb829baf334874d0cbb08e447d37d8b32dd6654615ea257e45 sha256:ea9d320ece0883ce3609bd435461442a7e23e3edb09220a9f8a0f9e751e6e9be sha256:e59a20181e4d3b1195cc9ebb0c5a3455bed9b61a1dcc94a5a1af156c48f55500]
2025-01-22T09:19:35+01:00	DEBUG	[image] Detected base layers	diff_ids=[]
2025-01-22T09:19:35+01:00	INFO	Detected OS	family="debian" version="11.5"
2025-01-22T09:19:35+01:00	INFO	Number of language-specific files	num=0
2025-01-22T09:19:35+01:00	DEBUG	Found an ignore file	file_path=".trivyignore"
2025-01-22T09:19:35+01:00	DEBUG	[vex] VEX filtering is disabled

Operating System

macOS 15.2

Version

Version: 0.58.2
Vulnerability DB:
  Version: 2
  UpdatedAt: 2025-01-20 12:17:37.583856157 +0000 UTC
  NextUpdate: 2025-01-21 12:17:37.583855886 +0000 UTC
  DownloadedAt: 2025-01-20 16:14:17.65162 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2024-12-30 05:06:53.947339247 +0000 UTC
  NextUpdate: 2025-01-02 05:06:53.947339087 +0000 UTC
  DownloadedAt: 2025-01-03 17:35:31.852757 +0000 UTC

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Hello @LesSyner
Thanks for your report!

This image contains 2 dpkg status files with the same name/version/etc:

So it's a bug like in #7824.

But your case is a bit weird.
IIUC fluent uses COPY to install packages.
And it looks like it's a bug with directory names (libssl1 and libssl1.1).

[knqyf263]

It is complicated by the fact that the file is currently named differently, libssl1 and libssl1.1, but if we think about /var/lib/dpkg/status, this file could be contained in more than one layer. And if the package versions are the same, we try to get the oldest layer where the package is installed. In the following example, we show the layer 2.

• Layer 1 (base)
• Layer 2 <-- /var/lib/dpkg/status including [email protected]+deb11u3
• Layer 3 <-- /var/lib/dpkg/status including [email protected]+deb11u3
• Layer 4

Wouldn't it be a good idea to think of it in the same way? The package [email protected]+deb11u3 was initially introduced in the layer where either of the files was added.

• Layer 1
• Layer 2 <-- libssl including [email protected]+deb11u3 added
• Layer 3 <-- libssl1.1 including [email protected]+deb11u3 added
• Layer 4

In the above example, the package was introduced in the layer 2.

Yes, it's still confusing because libssl1.1 was added in the layer 3, but I think that's a reasonable compromise for now. BTW, #4539 probably helps.

[DmitriyLewen]

ok, let's start with this.
I'll create a PR and write to you if I find other issues.

BTW, #4539 probably helps.

hmm... This might actually help. But I think we can wait for user feedback. As you rightly said - this is a rare case.

[knqyf263]

Yes, working on #4539 for this matter is too much, but regardless of this one, showing the source file would be helpful for users.

[DmitriyLewen]

we can think about it, but it seems that it is not very interesting for users (judging by the number of reactions)

[knqyf263]

I got queries internally. I guess enterprise users are more interested in that.

[DmitriyLewen]

Anyway, this is duplicate of #7824.

Wrote about this case in #7824 (comment)