Trivy now skips distribution advisories for third-party OS packages — should Vuls do anything about it?

[future-naoki-maruyama]

Trivy has changed how it treats OS packages installed from a third-party repository. I would
like to ask whether Vuls wants to respond to that, and if so how.

What Trivy does now

Since v0.69.0 Trivy classifies dpkg packages from their Maintainer field and skips
Debian/Ubuntu advisory matching for the ones it treats as third-party
(#9916,
#9932). In v0.70.0 the skip moved out of
the individual drivers into the shared detection path, so it applies to every OS family, RPM
included (#10118). Since v0.73.0 it is
the default for every driver — driver.DropThirdPartyPackages, with a PackageFilter
interface for drivers whose own feed covers such packages
(detect.go,
driver.go).
It is still the default in v0.74.0.

Concretely, with Trivy v0.69.3 against the public image nginx:1.28.0-bookworm, whose
nginx is distributed by nginx.org:

$ jq '[.Results[]?.Vulnerabilities[]? |
       select(.PkgName == "nginx") | .VulnerabilityID]' trivy.json
[]

$ jq '.Results[]?.Packages[]? |
      select(.Name == "nginx") | {Maintainer, Repository}' trivy.json
{
  "Maintainer": "NGINX Packaging <nginx-packaging@f5.com>",
  "Repository": {
    "Class": "third-party"
  }
}

Where Vuls sits

Vuls's local scanners do not collect the metadata that distinction is based on. dpkg-query
collects five fields and not Maintainer
(scanner/debian.go:342),
and rpm -qa does not collect %{VENDOR}
(scanner/redhatbase.go:1029-1032).

I have not run a local scan for this report. The above is a reading of the code at 6499d0e,
and I would welcome a correction if I have it wrong.

Why I am asking rather than proposing

Following Trivy is not obviously the right answer. nginx's own advisory page lists 1.28.0 as
affected by CVE-2026-42533 (vulnerable
0.9.6-1.31.2), so dropping the package discards a finding upstream itself confirms. Not
following it means continuing to apply a distribution's advisories to a build that
distribution did not produce — the false positive Trivy set out to avoid.

Question

Does Vuls want to do anything here? If it does, what should "third-party" mean: skip
distribution advisories (Trivy's default), report with lower confidence, match against an
upstream advisory source instead, or keep the current detection and expose the package's
origin?