Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] Host SBOM scan fails on any executable dd-agent can't read: the deferred analysis pass doesn't skip permission errors

Open
  • Is something wrong?
#57,795 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
56/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
backend, security

Research direction

Start with pkg/collector/corechecks/sbom/processor.go and trace the deferred analysis path into the pinned Trivy fork’s AnalyzerGroup.DeferredAnalyze and parallel.WalkDir; the issue also points to handler/sysfile for path normalization. Reproduce with host SBOM enabled and os plus languages analyzers on a file the agent cannot read. Done when permission-denied files no longer fail the scan and dpkg-owned paths are skipped, with tests covering both cases.

Written by the indexing model from the issue text.

Description

oss/0 pending team/agent-security
Agent version

7.84.2 (also seen on 7.84.1)

Bug Report

With host SBOM enabled and sbom.host.analyzers: [os, languages], the agent, running as dd-agent, fails the whole host scan at the first non-empty file that has an exec bit, sits outside the compiled-in skip list, and that dd-agent can't open:

ERROR | (pkg/collector/corechecks/sbom/processor.go:305 in processHostScanResult) | Scan error: unable to marshal report to sbom format, err: unable to scan rootfs, err: trivy scan failed: trivy scan failed: failed analysis: deferred analysis error: deferred analysis error: file open error: open /var/lib/cloud/instances/<instance-id>/scripts/runcmd: permission denied

No SBOM is produced, so the host gets no vulnerability findings at all, which in Datadog looks the same as a host with nothing to report. Every scan fails the same way until the file goes away.

Expected: the file is skipped, as it is everywhere else in the scan. The walker's ErrorCallback (ddtrivy's errorCallback) ignores fs.ErrPermission, AnalyzerGroup.AnalyzeFile breaks on it, and 7.84.0's release note fixed the same class for the static paths (/root/buildinfo/content_manifests).

Cause, in the Trivy fork the agent pins (DataDog/trivy 13735d029a7b, branch djc/main-dd-069). Since 5d0baf780031, "Defer per file application analyzers past OS package detection", the languages and executable analyzers run in AnalyzerGroup.DeferredAnalyze, after the walk, through parallel.WalkDir over the composite FS. During the walk, CompositeFS.CreateLink only records the file without opening it. So the first open is in parallel.walk, which returns file open error for any fsys.Open error. That ends WalkDir and fails the artifact.

A second problem in the same pass. DeferredAnalyze means to skip files an OS package owns (result.SystemInstalledFiles), but nothing is skipped for dpkg. dpkgAnalyzer.parseDpkgMd5sums records each file as "/"+file, while the composite FS's paths are relative, and mapfs.FS.Filter compares them with slices.Contains. The fork's test case "deferred analyzer skips a file owned by an OS package" feeds a relative path, so it passes. Observed: once the first file was readable, the scan stopped at /usr/libexec/samba/smbspool_krb5_wrapper. That file is 0700, from Debian's smbclient (maintainer Debian Samba Maintainers), which isThirdPartyPackage treats as first-party, so it should have been skipped.

Suggested fix:

  1. In the deferred walk, handle fs.ErrPermission as AnalyzeFile does: log it and skip the file. One way is to pass opts.WalkErrCallback through to parallel.WalkDir.
  2. Trim the leading / from SystemInstalledFiles before Filter, as handler/sysfile already does ("Trim leading slashes to be the same format as the path in container images").
Reproduction Steps
  1. Boot a Debian 13 (trixie) cloud image with any cloud-init runcmd. Ours is one line of vendor data, runcmd: [[systemctl, start, qemu-guest-agent.service]], and cloud-init writes it to /var/lib/cloud/instances/<instance-id>/scripts/runcmd as 0700 root:root.
  2. Install agent 7.84.2 with the configuration below.
  3. Start the agent. The host scan runs at start, and agent.log shows the error above for every scan. Successfully generated SBOM for host never appears.

The same happens on a Debian 13 host with HPE's ssacli package installed, whose binaries under /opt/smartstorageadmin/ssacli/bin are 0500.

Workarounds that work: give dd-agent read on the file (setfacl -m u:dd-agent:r <file>), after which the scan succeeds. Or scan with analyzers: [os], which uses the static paths only.

Agent configuration
sbom:
  enabled: true
  host:
    enabled: true
    analyzers:
      - os
      - languages
Operating System

Debian GNU/Linux 13 (trixie); also Proxmox VE 9 on Debian 13

Other environment details

Agent from the Debian package, running as dd-agent. Trivy fork DataDog/trivy@13735d029a7b, ddtrivy bf6bcaf2f9b7, both still pinned by main's go.mod.

Dominant language
Go
Stars
3.8k
Forks
1.5k
Avg merge
1d 11h
Merged PRs (30d)
594

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataDog/datadog-agent

All issues in DataDog/datadog-agent

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.