l3montree-dev / l3montree-dev/devguard
Go pseudo-version causes false positives for patched Prometheus releases
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 161
- Forks
- 43
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 37
Description
Summary
DevGuard reports patched Prometheus 3.14.0 as vulnerable because the Go binary SBOM contains both the authoritative release component and an embedded Go pseudo-version:
pkg:golang/github.com/prometheus/prometheus@3.14.0pkg:golang/github.com/prometheus/prometheus@v0.0.0-20260817133844-d7598b714141+dirty
The pseudo-version is compared against module fix versions such as v0.305.2 and v0.311.3, producing false positives even though the shipped binary reports Prometheus 3.14.0.
Observed findings
GHSA-8rm2-7qqf-34qmand aliasGO-2026-5264GHSA-vffh-x6r8-xx99and aliasGO-2026-5662GHSA-fw8g-cg8f-9j28and aliasGO-2026-5381GHSA-3m87-5598-2v4f, which is withdrawn because it does not apply to the Prometheus Go package
GO-2026-5264 is also emitted twice for the same artifact because it is attached to both Prometheus component representations.
Evidence
- Artifact: Prometheus 3.14.0, linux/amd64
- Upstream revision:
d7598b7141418fa35be2b5ec5d0fefb634199610 - GHSA-8rm2-7qqf-34qm affects
<3.5.3and>=3.6.0, <3.11.3; 3.14.0 is outside the affected range. - The other active advisories were likewise fixed in the 3.11.x line before 3.14.0.
Expected behavior
- Correlate Go pseudo-versions embedded in release binaries with the authoritative release component/version when both identify the same main module.
- Apply the release-semver affected ranges so patched later releases are not flagged.
- Collapse GO/GHSA aliases and duplicate component representations into one logical finding per artifact/path.
- Ignore withdrawn advisories.
Current workaround
The artifact-specific findings were marked false positive using vulnerable_code_not_present, preserving the original SBOM and its provenance.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file or test path is identified in the issue. Start by locating the Go SBOM component/version-correlation and advisory range-matching entry points, then reproduce the Prometheus 3.14.0 linux/amd64 case with the listed advisories. Done means patched releases are not flagged, withdrawn advisories are ignored, and duplicate aliases or component representations produce one finding.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, prometheus
- Domain
- backend, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100