fix(relationship): restore same-name guard for binary-overlap exclusion (fixes #5214) - #5227
fix(relationship): restore same-name guard for binary-overlap exclusion (fixes #5214)#5227CAOShurong wants to merge 1 commit into
Conversation
…S/Bitnami packages The ownership-overlap exclusion introduced in anchore#1948 (fix for anchore#931) was documented as requiring the OS package and the binary detection to have identical names, but the current implementation of identifyOverlappingOSRelationship and identifyOverlappingBitnamiRelationship drops the binary finding whenever any OS package owns the file, regardless of what software the OS package is. A vendor product RPM bundling its own copy of a library therefore silently suppresses the binary classifier result, hiding vulnerable vendored components from the SBOM (anchore#5214). Restore the name-match requirement with case-insensitive comparison: binary detections are only excluded when the owning OS or Bitnami package has the same name, i.e. they refer to the same software. Fixes anchore#5214 Signed-off-by: Shurong Cao <170531907+CAOShurong@users.noreply.github.com>
|
I ran this branch on my local against 3 images just to confirm that new packages will show up: Three images, HEAD~1 vs HEAD: debian:12 — 88 to 89 packages, one added: ubi9/openjdk-17-runtime — 134 to 137, three added: bitnamilegacy/apache — 123 to 125: I'm not sure I understand the fix totally yet and will take some more time tomorrow morning to read the PR and see if I can find any edge cases we're not covering. The other thing to consider is how this affects current users of syft and finding cases(if any) where the excluded package is the expected behavior. |
Fixes #5214
Root cause
The ownership-overlap exclusion introduced in #1948 (fixing #931) documents four conditions for excluding a binary package when an OS/Bitnami package owns the same file - one of them being that the parent and child have identical names (so e.g. an
opensslOS package may suppress a detected vendoredopensslbinary).The refactors in
identifyOverlappingOSRelationship/identifyOverlappingBitnamiRelationshipdropped that name check: any OS or Bitnami package owning a file suppresses binary detection under it, regardless of names. That reproduces the exact symptom in #5214 - an unrelatedvendor-productRPM owning a file hides the vendored OpenSSL 3.5.0 binary detection entirely.Change
Restores a case-insensitive
isSamePackageNamegate in both the OS and Bitnami paths before excluding the binary candidate.Verification (Windows, go1.26.6)
vendor-productRPM) no longer excludes the binarygo build ./...+go vetcleanmainbyte-identical across./syft/... ./internal/... ./cmd/syft/...(pre-existing Windows env failures only; Linux CI unaffected)Full analysis also posted on the issue thread.