l3montree-dev / l3montree-dev/devguard

Go pseudo-version causes false positives for patched Prometheus releases

Open
#2,922 1 comment 0 reactions 0 assignees View on GitHub

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.0
  • pkg: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-34qm and alias GO-2026-5264
  • GHSA-vffh-x6r8-xx99 and alias GO-2026-5662
  • GHSA-fw8g-cg8f-9j28 and alias GO-2026-5381
  • GHSA-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.3 and >=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

  1. Correlate Go pseudo-versions embedded in release binaries with the authoritative release component/version when both identify the same main module.
  2. Apply the release-semver affected ranges so patched later releases are not flagged.
  3. Collapse GO/GHSA aliases and duplicate component representations into one logical finding per artifact/path.
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.