False negative: trivy sbom on Syft SPDX-JSON retains 1 of 151 packages and reports 0 vulnerabilities, where CycloneDX from the same Syft run on the same tar reports 137

[GautamTalksDev]

IDs

N/A - false negative. 0 unique CVE IDs on the SPDX path where trivy image on the same tar reports 409.

Description

Related to #11139 but a different path and a much larger effect. #11139 is
the CycloneDX SrcName under-count. Here the OS packages are skipped
entirely. Filing separately because the debug output points at a different
cause.

What the debug output shows

Same image tar, same Syft binary, same Trivy binary, same DB, same minute.
Only the SBOM format differs.

SPDX:
INFO Detected SBOM format format="spdx-json"
INFO Detected OS family="none" version=""
WARN Unsupported os family="none"
INFO Number of language-specific files num=1

CycloneDX:
INFO Detected SBOM format format="cyclonedx-json"
INFO Detected OS family="debian" version="12.5"
INFO [debian] Detecting vulnerabilities... os_version="12" pkg_num=149

On the SPDX path no OS is detected, the family is declared unsupported, and
OS package detection never runs. 151 packages carrying valid
pkg:deb/debian/... PURLs are present in the document on disk. One package
survives, and it is a genuine maven component
(pkg:maven/libintl/libintl@0.21), not a misread deb.

format          packages with a PURL in the SBOM   trivy packages   trivy unique vulns
cyclonedx-json                               151              150                  137
spdx-json                                    151                1                    0
trivy image (same tar)                         -              149                  409

Same shape on debian:bookworm-slim: 89 packages with PURLs in the SPDX
document, 0 packages and 0 vulnerabilities from trivy sbom, 87 unique
vulnerabilities from trivy image.

Prior art I found and how I think this differs

#8629 reports RPMs not scanned in a Red Hat cosign SPDX document with the
same "no OS detected" shape, and #7100 added OS detection from PURL when
the OS component is missing. So the general failure is known and there is
already a fallback on at least one path.

What I think is new here, and I may be wrong: this is a Syft-generated
SPDX document on a Debian image where every OS package carries a valid
pkg:deb/debian/... PURL, and the same Syft run's CycloneDX output detects
debian 12.5 correctly from the same tar. If the PURL fallback from #7100
applies to this path, it is not firing on these documents.

Grype reading the same Syft SPDX document retains the packages and matches
its own direct image scan, so the information is present and consumable by
another consumer.

What I can and cannot say

I measured that the package data is present in the input and absent from
the output, and that Trivy reports no OS on the SPDX path and debian 12.5
on the CycloneDX path for the same image. I have not read the ingest code
and am not asserting where in it the OS determination diverges.

Why this matters more than a partial under-count

A zero is indistinguishable from a genuinely clean image from outside.
Some organizations standardize on SPDX for compliance deliverables, and on
that path this produces a clean report from a complete and valid SBOM.

Would it be in scope either to derive the OS from pkg:deb and pkg:apk
externalRef PURL locators on the SPDX path as #7100 does elsewhere, or to
warn when a document contains OS package PURLs and no OS family is
detected?

Happy to attach both SBOM fixtures.

Reproduction Steps

1. docker pull nginx:1.25 && docker save nginx:1.25 -o nginx.tar
2. syft scan docker-archive:nginx.tar -o cyclonedx-json=nginx.cdx.json
3. syft scan docker-archive:nginx.tar -o spdx-json=nginx.spdx.json
4. Count packages carrying a PURL in each SBOM, before trivy runs:
   jq '[.components[]? | select(.purl)] | length' nginx.cdx.json
   Observed: 151
   jq '[.packages[]? | select(any(.externalRefs[]?; .referenceType=="purl"))] | length' nginx.spdx.json
   Observed: 151
5. trivy sbom nginx.cdx.json --format json | jq '[.Results[]?.Packages[]?]|length'
   Observed: 150
6. trivy sbom nginx.spdx.json --format json | jq '[.Results[]?.Packages[]?]|length'
   Observed: 1
7. trivy sbom nginx.cdx.json --format json | jq -r '[.Results[]?.Vulnerabilities[]?.VulnerabilityID]|unique|length'
   Observed: 137
8. trivy sbom nginx.spdx.json --format json | jq -r '[.Results[]?.Vulnerabilities[]?.VulnerabilityID]|unique|length'
   Observed: 0
9. trivy image --input nginx.tar --format json | jq -r '[.Results[]?.Vulnerabilities[]?.VulnerabilityID]|unique|length'
   Observed: 409
10. Run step 6 with --debug. The SPDX path logs
    Detected OS family="none" and WARN Unsupported os, and OS package
    detection never runs. The CycloneDX path on the same tar logs
    Detected OS family="debian" version="12.5" and pkg_num=149.

Same shape on debian:bookworm-slim: 89 packages with PURLs in the SPDX
document, 0 packages and 0 vulnerabilities from trivy sbom, and 87 unique
vulnerabilities from trivy image on the same tar.

Target

SBOM

Scanner

Vulnerability

Target OS

Debian 12 (not detected on the SPDX path; this is the bug)

Debug Output

$ trivy sbom nginx.spdx.json --format json --debug

2026-08-25T03:25:33-04:00  INFO   [vuln] Vulnerability scanning is enabled
2026-08-25T03:25:33-04:00  INFO   Detected SBOM format    format="spdx-json"
2026-08-25T03:25:33-04:00  INFO   Detected OS     family="none" version=""
2026-08-25T03:25:33-04:00  WARN   Unsupported os  family="none"
2026-08-25T03:25:33-04:00  INFO   Number of language-specific files       num=1
2026-08-25T03:25:33-04:00  INFO   [jar] Detecting vulnerabilities...

Result: 1 package, 0 vulnerabilities.
The single retained package is a genuine maven component:

  "Target": "Java",
  "Class": "lang-pkgs",
  "Type": "jar",
  "Packages": [
    {
      "ID": "libintl:libintl:0.21",
      "Name": "libintl:libintl",
      "Identifier": {
        "PURL": "pkg:maven/libintl/libintl@0.21",
        "UID": "8576f1dff80cd85f"
      },
      "Version": "0.21",
      "Licenses": ["NOASSERTION"],
      "Digest": "sha1:1460d2aaf8dd90a68249717470bcda7415a9ef01"
    }
  ]

$ trivy sbom nginx.cdx.json --format json --debug

2026-08-25T03:25:34-04:00  INFO   [vuln] Vulnerability scanning is enabled
2026-08-25T03:25:34-04:00  INFO   Detected SBOM format    format="cyclonedx-json"
2026-08-25T03:25:34-04:00  WARN   Third-party SBOM may lead to inaccurate vulnerability detection
2026-08-25T03:25:34-04:00  WARN   Recommend using Trivy to generate SBOMs
2026-08-25T03:25:34-04:00  INFO   Detected OS     family="debian" version="12.5"
2026-08-25T03:25:34-04:00  INFO   [debian] Detecting vulnerabilities...   os_version="12" pkg_num=149
2026-08-25T03:25:34-04:00  INFO   Number of language-specific files       num=1
2026-08-25T03:25:34-04:00  INFO   [jar] Detecting vulnerabilities...

Result: 150 packages, 137 unique vulnerabilities.

Both SBOMs generated by the same syft 1.51.0 run from the same nginx:1.25
docker-archive tar. The only difference is the output format flag.

Version

Version: 0.72.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2026-08-25 06:59:59.307495517 +0000 UTC
  NextUpdate: 2026-08-26 06:59:59.307495287 +0000 UTC
  DownloadedAt: 2026-08-25 07:25:13.65940968 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2026-08-24 01:07:04.599776272 +0000 UTC
  NextUpdate: 2026-08-27 01:07:04.599776152 +0000 UTC
  DownloadedAt: 2026-08-24 07:00:25.559842448 +0000 UTC

Note: 0.74.0 is available and I have not tested it yet. Happy to retest and
report back if the behaviour differs.

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[nikpivkin]

Trivy finds the operating system in SPDX only by the SPDXRef-OperatingSystem- prefix of a package entry, and only Trivy's own SPDX output creates such an entry. Syft does not describe the operating system in SPDX at all, so the only place the distro is left is the distro=debian-12 qualifier in the PURL. In CycloneDX Syft writes a component with "type": "operating-system" and Trivy reads it directly, which is why the same Syft run works there.

The packages are read correctly. But the OS is unknown and there are packages, so Trivy sets the family to none. No driver matches that family, so the OS result is dropped and the package list goes with it. That is why the report looks the same as a clean image instead of showing 149 packages with no matches.

@knqyf263 #7101 was closed and #9034 was merged instead, because wolfi-base does have /etc/os-release, so the OS does not need to come from the SBOM. That is true for image, fs and rootfs. But sbom has no files to read. The document is the only source of the OS, and if the generator did not write an OS entry, there is nothing else to use. #9034 made the decoder keep those OS packages, but the family still has no source, so they are dropped a bit later instead.

One more thing on the SPDX side. The component type is taken from the SPDXID prefix (parseType in pkg/sbom/spdx/unmarshal.go). SPDXID carries no meaning in the spec, it is only a unique label (7.2), so the prefix works for documents Trivy wrote itself and for nothing else. SPDX 2.3 has a field for exactly this, primaryPackagePurpose, and Trivy already writes OPERATING-SYSTEM there. It is optional (0..1), so it cannot replace the prefix check, but reading it when present would cover other generators. anchore/syft#3462 would set it too, along with an SPDXRef-OperatingSystem- id, but it has been open since Nov 2024.

@GautamTalksDev as a workaround, --distro debian/12 sets the OS by hand and the OS packages come back into the report. Detection will still be incomplete: source package names are lost on this path too, so you will land near your CycloneDX number rather than at parity with trivy image.