Many OS packages missing when scanning CycloneDX SBOM with trivy sbom #9006

masahiro331 · 2025-06-07T16:20:32Z

masahiro331
Jun 7, 2025

Description

When generating a CycloneDX SBOM from an Amazon Linux 2023 system and then scanning it using trivy sbom, a significant number of OS packages (pkg:rpm) disappear.

Note: Due to this issue, any vulnerabilities associated with the overwritten OS packages are not detected during the trivy sbom scan.

Desired Behavior

The number of pkg:rpm entries should remain roughly the same between the original and scanned SBOMs.

Actual Behavior

The scanned SBOM (scan_sbom.json) contains significantly fewer pkg:rpm entries than the original

Reproduction Steps

1. Launch an EC2 instance using Amazon Linux 2023
AMI: ami-027fff96cc515f7bc

2. Install some basic tools

sudo yum update && sudo yum install -y git tar

Generate and scan the SBOM using Trivy

trivy fs --scanners vuln --pkg-types os --skip-dirs "/proc,/home/ec2-user/" -f cyclonedx -o scan_fs.json /
trivy sbom -f cyclonedx -o scan_sbom.json scan_fs.json

Count the number of rpm-package entries in both SBOM

$ cat scan_fs.json | grep pkg:rpm | grep bom-ref | wc -l
485
$ cat scan_sbom.json | grep pkg:rpm | grep bom-ref | wc -l
16



### Target

SBOM

### Scanner

Vulnerability

### Output Format

CycloneDX

### Mode

Standalone

### Debug Output

```bash
$ mage build
$ ./trivy version
Version: 0.63.0

$ cat out.json  | grep pkg:rpm | grep bom-ref  | wc -l
485

$ ./trivy sbom -f cyclonedx  --debug out.json  | grep pkg:rpm | grep bom-ref  | wc -l
2025-06-07T16:14:22Z    DEBUG   No plugins loaded
2025-06-07T16:14:22Z    DEBUG   Default config file "file_path=trivy.yaml" not found, using built in values
2025-06-07T16:14:22Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-06-07T16:14:22Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-06-07T16:14:22Z    DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-06-07T16:14:22Z    DEBUG   Ignore statuses statuses=[]
2025-06-07T16:14:22Z    INFO    "--format cyclonedx" disables security scanning. Specify "--scanners vuln" explicitly if you want to include vulnerabilities in the "cyclonedx" report.
2025-06-07T16:14:22Z    DEBUG   [pkg] Package types     types=[os library]
2025-06-07T16:14:22Z    DEBUG   [pkg] Package relationships     relationships=[unknown root workspace direct indirect]
2025-06-07T16:14:22Z    DEBUG   Initializing scan cache...      type="memory"
2025-06-07T16:14:22Z    DEBUG   [notification] Running version check
2025-06-07T16:14:22Z    INFO    Detected SBOM format    format="cyclonedx-json"
2025-06-07T16:14:22Z    DEBUG   Unmarshalling CycloneDX JSON...
2025-06-07T16:14:22Z    INFO    Detected OS     family="amazon" version="2023.7.20250527 (Amazon Linux)"
2025-06-07T16:14:22Z    INFO    Number of language-specific files       num=0
2025-06-07T16:14:22Z    DEBUG   Specified ignore file does not exist    file=".trivyignore"
2025-06-07T16:14:22Z    DEBUG   [vex] VEX filtering is disabled
16

Operating System

amazonlinux 2023

Version

$ ./trivy version
Version: 0.63.0

Checklist

Run trivy clean --all
Read the troubleshooting

masahiro331 · 2025-06-07T16:52:50Z

masahiro331
Jun 7, 2025
Author

Cause Investigation

To investigate the issue, I created a set of test scripts and used git bisect to identify the commit that likely introduced the problem.

These scripts automates the build and comparison between fs and sbom scans, helping to isolate the regression that causes missing OS packages in the SBOM scan.

run.bash

#!/bin/bash
set -euo pipefail

# Define known bad and good versions
BAD=v0.59.0
GOOD=v0.58.0

# Start bisect session
git bisect start $BAD $GOOD
git bisect run ./test.bash
git bisect reset

test.bash

#!/bin/bash
set -euo pipefail

# build trivy
function build_trivy() {
  mage build
}

# check function
function check() {
  ./trivy fs --skip-dirs "/proc,/home/ec2-user/" --scanners vuln -f cyclonedx -o out.json /
  count_scan_fs=$(cat out.json | grep pkg:rpm | grep bom-ref | wc -l)
  count_scan_sbom=$(./trivy sbom -f cyclonedx out.json | grep pkg:rpm  | grep bom-ref | wc -l)
  echo $count_scan_fs $count_scan_sbom
  if [[ $count_scan_sbom -eq $count_scan_fs ]]; then
    echo "GOOD: sbom and fs scan result is same"
    exit 0
  else
    echo "BAD: sbom and fs scan result is different"
    exit 1
  fi
}

build_trivy
check

Identified Cause

It appears that the cause is in the following pull request:
aquasecurity/trivy#8144

Specifically, due to cycle detection logic, some orphan OS packages (orphan-pkg) are created during the SBOM decoding phase.

These orphan packages are added to the result in the following code:
pkg/sbom/io/decode.go

As a result, the internal SBOM structure ends up looking like this:

[]ftypes.PackageInfo{
   PackageInfo{
	FilePath: "",
	Packages: rpm-rpm-packages,    // Normal OS packages
   },
   PackageInfo{
	FilePath: "",
	Packages: orphan-rpm-packages,     // Orphaned OS packages
   }  
}

Note: Both PackageInfo objects have an empty FilePath ("").

The []ftypes.PackageInfo slice described above is eventually merged in the following code:
pkg/fanal/applier/docker.go

However, since both PackageInfo entries have the same FilePath value (an empty string ""), they are merged into the same key when inserted into the nestedMap via nestedMap.SetByString.

This causes the first entry (which contains the package dependency graph) to be overwritten by the second entry (which orphan packages). As a result, the packages collected via the dependency graph are lost, and only the orphan packages remain.

1 reply

knqyf263 Jun 9, 2025
Maintainer

@DmitriyLewen Can you take a look?

masahiro331 · 2025-06-07T17:30:17Z

masahiro331
Jun 7, 2025
Author

#9007

0 replies

DmitriyLewen · 2025-06-09T10:07:59Z

DmitriyLewen
Jun 9, 2025
Maintainer

Hello @masahiro331
Thanks for your report and PR.

I investigated amazon linux image and found that problem is related to encoding SBOM file (instead of decoding).
The problem is infinite loops for dependencies.
e.g. Trivy thinks that pkg:rpm/amazon/git@2.47.1-1.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29 is orphan package.
But this package is in an infinite loop with the package `pkg:rpm/amazon/perl-Git@2.47.1-1.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29 package:

    {
      "ref": "pkg:rpm/amazon/perl-Git@2.47.1-1.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
      "dependsOn": [
        "pkg:rpm/amazon/git@2.47.1-1.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-Error@0.17029-5.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29&epoch=1",
        "pkg:rpm/amazon/perl-Exporter@5.74-459.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-constant@1.33-459.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-libs@5.32.1-477.amzn2023.0.6?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29&epoch=4"
      ]
    },
    {
      "ref": "pkg:rpm/amazon/git@2.47.1-1.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
      "dependsOn": [
        "pkg:rpm/amazon/git-core-doc@2.47.1-1.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/git-core@2.47.1-1.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-File-Basename@2.85-477.amzn2023.0.6?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-File-Find@1.37-477.amzn2023.0.6?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-Getopt-Long@2.52-2.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29&epoch=1",
        "pkg:rpm/amazon/perl-Git@2.47.1-1.amzn2023.0.2?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-IPC-Open3@1.21-477.amzn2023.0.6?arch=noarch&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-PathTools@3.78-459.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-TermReadKey@2.38-9.amzn2023.0.2?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-lib@0.65-477.amzn2023.0.6?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29",
        "pkg:rpm/amazon/perl-libs@5.32.1-477.amzn2023.0.6?arch=aarch64&distro=amazon-2023.7.20250512+%28Amazon+Linux%29&epoch=4"
      ]
    },

In other words, these components are not related to the root component (OS component).
So when we analyze the dependency tree starting from OS component, we don't find these components.

The problem is with the following logic:

trivy/pkg/sbom/io/encode.go

Lines 412 to 434 in 3b1426a

    
           func (*Encoder) belongToParent(pkg ftypes.Package, parents map[string]ftypes.Packages, hasRoot bool) bool { 
        
           	// Case 1: Relationship: known , DependsOn: known 
        
           	//         Packages with no parent are included in the parent 
        
           	//         - Relationship: 
        
           	//           - Root: true (it doesn't have a parent) 
        
           	//           - Workspace: false (it always has a parent) 
        
           	//           - Direct: 
        
           	//             - No root dependency in the project: true (e.g., poetry.lock) 
        
           	//             - Otherwise: false (Direct dependencies should belong to the root/workspace) 
        
           	//           - Indirect: false (it always has a parent) 
        
           	// Case 2: Relationship: unknown, DependsOn: unknown (e.g., conan lockfile v2) 
        
           	//         All packages are included in the parent 
        
           	// Case 3: Relationship: known , DependsOn: unknown (e.g., go.mod without $GOPATH) 
        
           	//         All packages are included in the parent 
        
           	// Case 4: Relationship: unknown, DependsOn: known (e.g., GoBinaries, OS packages) 
        
           	//         - Packages with parents: false. These packages are included in the packages from `parents` (e.g. GoBinaries deps and root package). 
        
           	//         - Packages without parents: true. These packages are included in the parent (e.g. OS packages without parents). 
        
           	if pkg.Relationship == ftypes.RelationshipDirect { 
        
           		return !hasRoot 
        
           	} 
        
           	return len(parents[pkg.ID]) == 0 
        
           }

rpm packages don't have a Relationship field, so we only check parents.
But both packages nominally have parents, so we don't relate them to the parent component.

0 replies

DmitriyLewen · 2025-06-09T10:13:38Z

DmitriyLewen
Jun 9, 2025
Maintainer

track #9011

0 replies

masahiro331 · 2025-06-09T10:18:26Z

masahiro331
Jun 9, 2025
Author

@DmitriyLewen
Thank you. I have two question.

Does this mean that the wrong SBOM was created in the first place?
When reading SBOMs that are not Trivy SBOMs, I think the same problem will occur as you reported, but will we fix the process after decode?

I think this problem needs to be solved from both encode and decode.

1 reply

DmitriyLewen Jun 9, 2025
Maintainer

Does this mean that the wrong SBOM was created in the first place?

This is hard question.
To some extent, you are right. In this SBOM, there is no link between the OS component and the git component.
However, the problem is that it’s not possible to determine which of the two components was actually installed (unless you were the one who ran the installation command):
e.g. yum shows both packages:

bash-5.2# yum list installed | grep -i git
crypto-policies.noarch               20240828-2.git626aa59.amzn2023.0.1 @System     
git.aarch64                          2.47.1-1.amzn2023.0.2              @amazonlinux
git-core.aarch64                     2.47.1-1.amzn2023.0.2              @amazonlinux
git-core-doc.noarch                  2.47.1-1.amzn2023.0.2              @amazonlinux
perl-Git.noarch                      2.47.1-1.amzn2023.0.2              @amazonlinux

So, there are two possible options (and neither of them will be 100% correct):
• No element is linked to the OS component (this is the current situation)
• Both components are linked to the OS component (this is probably the more accurate solution)

When reading SBOMs that are not Trivy SBOMs, I think the same problem will occur as you reported, but will we fix the process after decode?

I think we should first look into an example like this.
If the situation is the same as now, then — as I already mentioned — this SBOM is incorrect.
But if there are two OS components, then Trivy currently does not support such SBOMs.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Many OS packages missing when scanning CycloneDX SBOM with trivy sbom #9006

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 5 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Many OS packages missing when scanning CycloneDX SBOM with trivy sbom #9006

Uh oh!

Uh oh!

masahiro331 Jun 7, 2025

Description

Desired Behavior

Actual Behavior

Reproduction Steps

Operating System

Version

Checklist

Replies: 5 comments · 2 replies

Uh oh!

masahiro331 Jun 7, 2025 Author

Cause Investigation

Identified Cause

Uh oh!

knqyf263 Jun 9, 2025 Maintainer

Uh oh!

masahiro331 Jun 7, 2025 Author

Uh oh!

DmitriyLewen Jun 9, 2025 Maintainer

Uh oh!

DmitriyLewen Jun 9, 2025 Maintainer

Uh oh!

Uh oh!

masahiro331 Jun 9, 2025 Author

Uh oh!

DmitriyLewen Jun 9, 2025 Maintainer

masahiro331
Jun 7, 2025

Replies: 5 comments 2 replies

masahiro331
Jun 7, 2025
Author

knqyf263 Jun 9, 2025
Maintainer

masahiro331
Jun 7, 2025
Author

DmitriyLewen
Jun 9, 2025
Maintainer

DmitriyLewen
Jun 9, 2025
Maintainer

masahiro331
Jun 9, 2025
Author

DmitriyLewen Jun 9, 2025
Maintainer