Go binary scan misses subpackage-scoped GHSA despite detecting vulnerable module versions #11018
Replies: 1 comment 1 reply
|
Hi @pjroth, thanks for the very detailed report! The good news is that this needs no fix on Trivy's detection side and no special-casing of this binary. The problem is in the data of the GHSA-rjr7-jggh-pgcp advisory itself. What's wrong with the advisoryAll five Per the OSV specification, for the The upstream Go Vulnerability Database models the same vulnerability correctly — GO-2026-5777: "package": { "name": "github.com/go-chi/chi/v5", "ecosystem": "Go" },
"ranges": [{ "type": "SEMVER", "events": [{ "introduced": "0" }, { "fixed": "5.3.0" }] }],
"ecosystem_specific": {
"imports": [
{ "path": "github.com/go-chi/chi/v5/middleware", "symbols": ["RealIP"] }
]
}The module goes into What you can doAdvisories are fixed in the GitHub Advisory Database itself, and anyone can propose a change. The proposal is to drop the
Once the fix lands in GHSA it will reach the Trivy DB within a day, and both versions from your binary ( One caveat: even after that fix, detection stays at module level, so Trivy will report the vulnerability regardless of whether |
|
I created github/advisory-database#8900. I'd appreciate it if someone reviewed my PR since I don't really understand the advisory details. Thanks for all you do for this great tool! |
Uh oh!
There was an error while loading. Please reload this page.
IDs
GHSA-rjr7-jggh-pgcp
Description
Trivy misses GHSA-rjr7-jggh-pgcp in a container image even though it detects the affected Go binary and both vulnerable module versions.
The image contains
/usr/local/bin/aws-lambda-rie. Trivy identifies it as agobinaryand inventories:github.com/go-chi/chiv1.5.5github.com/go-chi/chi/v5v5.2.4The current Trivy DB contains GHSA-rjr7-jggh-pgcp under:
github.com/go-chi/chi/middleware<= 1.5.5github.com/go-chi/chi/v5/middleware< 5.3.0Because the Go binary inventory contains module roots while the advisory is keyed to subpackage paths, the vulnerability is not reported. AWS Inspector reports the same advisory against this binary.
This appears to be the false-negative mirror of discussion #10944: module-only binary inventory can prevent a subpackage-scoped advisory from matching at all, rather than only causing module-level false positives.
Expected: when the compiled binary contains the vulnerable subpackage, Trivy should report it. A general solution might derive imported subpackages/symbols from Go binaries or integrate an analyzer capable of doing so, rather than special-casing this binary or advisory.
Actual: Trivy reports no HIGH finding for this advisory.
Reproduction Steps
Target
Container Image
Scanner
Vulnerability
Target OS
Amazon Linux 2023
Debug Output
Version
Checklist
-f jsonthat shows data sources and confirmed that the security advisory in data sources was correctAll reactions