Repository navigation
Reduce HIGH findings on \otel/opentelemetry-collector-contrib\ pinned digest (4 HIGH, 0 CRITICAL — 2026 Go stdlib/x-net wave) #115
Description
Reduce HIGH findings on otel/opentelemetry-collector-contrib (4 HIGH, 0 CRITICAL)
Status
Open. Surfaced 2026-10-05..10 by the weekly scan after new Go CVEs were published against existing package versions (DB movement against a frozen image — the exact scenario flagged in docs/container_security_scan.md's re-scan notice). The collector itself did not drift; nothing broke.
Pin
otel/opentelemetry-collector-contrib@sha256:fd328de2552466ad78385e1b1289c3f2402b1c45f265b252aab1955b42845ac1 (0.161.0; 0 HIGH/0 CRIT at pin-time 2026-10-03).
Findings (Trivy 0.74.0, DB 2026-10-10, HIGH+CRITICAL, ignore-unfixed)
| CVE | Package | Installed -> Fixed |
|---|---|---|
| CVE-2026-78667 | stdlib | 1.26.8 -> 1.26.9 / 1.27.2 |
| CVE-2026-78669 | stdlib + golang.org/x/net | x/net v0.58.0 -> 0.60.0 |
| CVE-2026-97031 | stdlib (crypto/tls) | 1.26.8 -> 1.26.9 / 1.27.2 |
Re-pin verification (2026-10-10, #82 re-scan gate)
Registry :latest = sha256:8b9211db... scanned on the same DB: identical 4 findings. Upstream collector releases are not yet built with fixed Go/x-net, so NO re-pin was adopted (gate: adopt only on verified equal-or-better). Same gate correctly rejected the newer grype:debug (3518aea7..., same 4 findings) in favor of our clean 0-finding 1d10432f... deployment pin.
Why NOT in .trivyignore
Core default-profile path (the pipeline's ingest spine). These IDs are shared with #83/#84 images, and ID-global suppression would also blind future OTel regressions. Keep visible until rebuilt.
Resolution path
The CI matrix entry now floats to :latest as the drift monitor (this issue's companion PR; same doctrine as clamav/#111 and goflow2/dcgm). The weekly/push scan job Trivy scan (otel-collector-contrib) dropping to 0 on floating :latest = the signal to verify + re-pin compose to the patched digest.
Acceptance criteria
- Compose re-pinned to a verified 0-HIGH/0-CRITICAL contrib digest built with Go >= 1.26.9/1.27.2 and x/net >= 0.60.0, docs rows + this issue closed; or
- Upstream declares the stdlib DoS vectors non-exploitable in the collector (document + VEX instead of re-pin).
Owner
TBD. Active in the default compose path (highest-priority image in the stack).
Activity
fix(ci): float otel-collector-contrib matrix entry as #115 rebuild mo…
JJediny commentedon Oct 11, 2026
Monitor restored + re-pin gate result (2026-10-10)
Monitor. PR #116 (squash
f29a2a3, merged 2026-10-11 02:23 UTC) floated the CI matrixotel-collector-contribentry so it tracks the upstream rebuild. First post-merge run onmain(run38105001331) passed all 12 scan jobs;Trivy scan (otel-collector-contrib)reporting 4 HIGH is now expected steady state (gate is CRITICAL-only). When upstream rebuilds with fixed Go (>= 1.26.9 / 1.27.2) and/orgolang.org/x/net0.60.0, findings drop to 0 — that drop is the re-pin trigger.Gate result. Registry
:latest=sha256:8b9211db…scanned with current Trivy DB yields the identical 4 findings as the deployed pinsha256:fd328de2…(CVE-2026-78667, CVE-2026-78669 stdlib+x/net, CVE-2026-97031). Lateral move → no re-pin; compose keepsfd328de2….Suppression. The new-wave IDs are deliberately not added to
.trivyignore: ID-global suppression would blind this issue's own regression signal on a fixable, core-path image. Revisit only after the pin moves to a >= fixed build.Related: the 19 new-wave alerts (#495–#513) stay open as current upstream-pending signals; umbrella tracking on #82.