feat: extend the Go re-check to +dirty builds, other module paths and the project's own advisory

[Eandalf-Bigstack]

What type of PR is this?

/kind feature

What this PR does / why we need it

Extends the Go re-check that #206 added, for cubecos's sixth 3.2.0 scan-review round. A scan of cubecos's rebuilt binaries showed three cases it missed:

case	change
A build from a modified tree	The Go toolchain stamps such a build's pseudo-version with +dirty (beats' builds: v7.0.0-20260930214605-b80bf8464fba+dirty). The pass now reads it as a pseudo-version.
Another module path of the same repository	An advisory can give semantic ranges under one module path and only a fixed pseudo-version under another. GitHub's advisory for a Packetbeat flaw fixes github.com/elastic/beats in 8.19.9, 9.1.9 and 9.2.3, but github.com/elastic/beats/v7 only at a commit on the 9.2 branch. The pass now reads the ranges of the repository's other module paths too. When the linked commit is itself a release (v9.5.5), a fixed pseudo-version it does not contain no longer keeps the match, because the pseudo-version only names that release.
A blanket entry in the Go vulnerability database	The database can list a project's older module path with no affected range (every version, no fix) where the project's own advisory names only the newer path. Two examples: containerd v1 for two CRI checkpoint flaws in a feature only v2 has, and chi v1 to v4 for a RedirectSlashes flaw introduced in v5.2.2. grype reports such a match with no constraint. It now moves to ignoredMatches when the GitHub advisory the repository itself published for the flaw names only the repository's other module paths.

It also fixes a build blocker from #206's 7302fb2 (8611c97). The E610 check looked ixgbe up by name in the jail's module tree (modinfo -k). The jail installs its kernel packages with rpm -i --nodeps, which never runs depmod there, so that tree has no index. On the 7.2.11 kernel the check failed although its ixgbe carries the E610, which stopped cubecos's jim pipeline #162 in the base rootfs. The check now reads the kernel's own ixgbe.ko directly, and still fails the build on a kernel with no ixgbe or one without the E610 id.

Which issue(s) this PR fixes

Refs bigstack-oss/cubecos#578

Special notes for your reviewer

Note

Stacked: the base is jim.lin/fix/vuln-handling-5 (#206), on #205, and this PR is in the same GitHub stack. Merge #205 and #206 first.

Pairs with the cubecos PR for jim.lin/fix/vuln-handling-6, whose hex bumps point at cac1851 and 8611c97. Both repos merge fast-forward, so the SHAs stay valid.

Conservative by design:

• The release exception needs an exact release. It applies only when the linked commit is a release tag. An untagged commit whose fixed pseudo-version lies elsewhere keeps the match, as before.

• Another path's ranges need the advisory to name this module too. They count only when the advisory names this module path as well; an advisory that names only the other path judges nothing.

• The deferral is narrow. All of these must hold:

  • the Go database's record gives this module path no range at all, and grype matched it with no constraint;
  • the GitHub advisory is the repository's own, linking its security/advisories page;
  • that advisory names only other module paths of the same repository.

  Pseudo-versions stay with the pseudo-version rules.

Verification:

• Unit tests: scripts/tests/test_recheckvulns.sh passes 126 checks, 6 of them new.

  • Cleared cases: a +dirty build, a release judged by the other path's ranges, and the project's advisory deferred to.
  • Kept cases: the same advisory on a commit that is no release, an advisory naming only the other path, a database record with a range, an advisory without the project's own page, and an advisory naming the module itself.

  test_projsbom.sh passes its 12.

• On real reports (jim build jail, grype 0.119.0):

  • Rebuilt filebeat and auditbeat: both beats matches are ignored as release v9.5.5.
  • cubecos's 3.2.0 rootfs report: the pseudo-version counts are unchanged. The new check ignores exactly seven matches, the two containerd v1 Criticals and a Medium, and four chi v4 matches, each confirmed against the project's own advisory.

• The E610 check: run as committed through make in the rebuilt jim build jail. It passes for 7.2.11-1.el9.x86_64, whose ixgbe.ko.xz carries v00008086d000057B0, and fails for a kernel with no ixgbe in the tree.

Additional documentation

NONE

🤖 Generated with Claude Code