Repository navigation
Track: remaining 86 HIGH (0 CRITICAL) code-scanning findings on upstream vendor images #82
Description
Track: remaining 86 HIGH (0 CRITICAL) code-scanning findings on upstream vendor images
Summary
After PR #81 (security(deps): refresh digest-pinned images) merged on main at 7c9cbf6, the code-scanning tab still shows 86 HIGH and 0 CRITICAL findings across 4 vendor-published images. This tracking issue links the per-image follow-ups and records the resolution path for each.
Numbers (Trivy 0.74.0, current vuln DB, scanned 2026-09-14)
| Image | HIGH | CRITICAL | Resolution path |
|---|---|---|---|
nvcr.io/nvidia/k8s/dcgm-exporter:latest |
34 | 0 | #83 |
netsampler/goflow2:latest |
30 | 0 | #84 |
anchore/grype:latest |
15 | 0 | #85 |
falcosecurity/falco:0.44.1 |
3 | 0 | #86 |
osquery/osquery:5.17.0-ubuntu22.04 |
2 | 0 | #87 |
otel-collector-contrib@799dc6cf |
1 | 0 | #88 |
openobserve@88fb692a |
1 | 0 | #89 |
clamav, clamav-base, rsigma |
0 | 0 | clean |
| Total | 86 | 0 |
Already shipped
- PR security(deps): refresh digest-pinned images (openobserve, osquery, otel-contrib) #81 (merged
7c9cbf6): openobserve, otel-contrib, osquery digest bumps. Net 117 → 86 HIGH. - PR refactor(ci): make caldera build-and-test job verify-only on uv.lock #80 (merged
8f6f7e8): caldera workflow nowuv lock --checkonly, no auto-push to main.
Why we stopped (not a fix)
- No CRITICAL on any image → release gate (block on CRITICAL) is doing its job.
- The remaining HIGHs are concentrated in 4 upstream-vendor images.
- An in-repo fix would require picking a specific new digest per image. A draft PR-2 (tag-pinned bumps) showed mixed results: pinning dcgm-exporter had no effect, but pinning goflow2 to
v2.2.6regressed from 30 to 56 HIGH + 3 CRITICAL, and grype from 13 to 59 + 2 CRITICAL, on the same Trivy 0.74.0 binary. Those candidate digests are not safe to ship without upstream coordination. osquery:5.17.0-ubuntu22.04is the newest published tag for that series on Docker Hub; the 2 HIGHs (CVE-2025-68973 GnuPG, CVE-2026-45447 OpenSSL PKCS7) have no upstream fix without a major-version downgrade of the osquery image, which we will not do without a separate evaluation.
Resolution plan
- Per-image issues (one per remaining HIGH-bearing image) document:
- The full CVE list with installed vs. fixed versions
- The upstream tracking issue / release that will close each CVE
- The acceptance criteria for re-pinning
.trivyignorefollow-up: once each per-image issue has a clear owner and a fix-in-flight upstream entry, add a.trivyignoreline per CVE withreason:andexpiry:so the security tab reflects "known + tracked" rather than "open + unowned". Not blanket suppression; per-CVE documentation.- Re-scan gate: every digest bump must be re-scanned with
trivy image --scanners vuln --severity HIGH,CRITICALand have the new digest's CVE count compared against the old digest's count against the current vuln DB (not the matrix run's DB), to avoid the DB-drift false positive that misled the abandoned PR-2.
Acceptance criteria for closing this tracking issue
- All per-image child issues closed.
.trivyignorein place with documented rationale and review dates.- Either the HIGH count drops to a documented, owner-tracked floor, or each remaining HIGH has an explicit "deferred to upstream X by YYYY-MM-DD" annotation in the code-scanning tab.
Activity
JJediny commentedon Oct 4, 2026
Progress Update (via PR #103)
@sha256:fd328...) — Residual HIGH on otel/opentelemetry-collector-contrib (1 HIGH, 0 CRITICAL) #88 closed (0 HIGH, 0 CRITICAL).@sha256:d4a87...) — Residual HIGH on public.ecr.aws/zinclabs/openobserve (1 HIGH, 0 CRITICAL) #89 closed (0 HIGH, 0 CRITICAL).@sha256:788f1...) — Reduce HIGH findings on falcosecurity/falco:0.44.1 (3 HIGH, 0 CRITICAL) — blocked on 0.45.0 GA #86 closed (0 HIGH, 0 CRITICAL).ignore-unfixed: true(0 actionable HIGH/CRITICAL in code-scanning).5.17.0-ubuntu24.04has 3 HIGH;5.17.0-debian12has multiple HIGH + 1 CRITICALzlib1g). Confirmed5.17.0-ubuntu22.04is the cleanest tag series available.Total open code-scanning alerts on
maindropped from 86 to 43 (30 goflow2, 11 grype, 2 osquery).chore(security): add per-CVE .trivyignore with tracked reasons and re…
JJediny commentedon Oct 4, 2026
Status update — 2026-10-04 (Trivy 0.74.0, DB 2026-10-04)
.trivyignoreimplemented per this issue's resolution plan step 2 in4d90ba4(+ CI-consistency forscripts/scan-images.sh, which now mounts the file into the Trivy container).Fresh per-image numbers from the 2026-10-04 CI scan (
37230996409/37232639233):Verified against the real binary: osquery 3→0, goflow2 22→0, dcgm 2→0 locally and in the post-merge CI run (all targets report 0). Open HIGH Trivy alerts on the Security tab: 57 → 44 immediately after the first clean upload; the historical remainder (old-digest goflow2/dcgm/grype IDs from September) auto-resolves as fixed on subsequent uploads — weekly Monday run guarantees convergence.
Findings on process:
EXPIRY=directive (three syntax variants tested empirically); review dates are comment- enforced and tied to the weekly workflow.CVE-2026-103111(pcre2 out-of-bounds write, HIGH) appeared onclamav/clamav:latestat 2026-10-04 00:24 UTC — active profile, unpinned floating tag, intentionally not in.trivyignore. Recommend a per-image child issue (like Reduce HIGH findings on nvcr.io/nvidia/k8s/dcgm-exporter (34 HIGH, 0 CRITICAL) #83–Reduce HIGH findings on osquery/osquery:5.17.0-ubuntu22.04 (2 HIGH, 0 CRITICAL) — no upstream fix #87) and/or digest-pinning the twoclamav:latestservices so a moving vendor tag does not silently introduce findings..trivyignoreentries are ID-global across all scanned images; the weekly scan is the guard against these IDs re-appearing somewhere they would actually matter.JJediny commentedon Oct 4, 2026
Addendum — pinning doctrine now applied consistently (2026-10-04)
Since the main comment,
clamav(#111) andgrype(#85, closed) floating tags were digest-pinned after verified pulls/scans. Remaining explicit decision: goflow2 (:latest) and dcgm-exporter (:latest) intentionally stay floating in both compose and the CI matrix. Rationale: for these two, upstream fixes are not in flight, so the moving tag is the drift-monitoring instrument — a new finding on the floating ref is the signal that upstream changed (which is exactly how this issue's 86→44 alert convergence and the clamav pcre2 discovery worked). Pinning them would freeze the suppressed-HIGH baseline and mute re-pin signals; their child issues #83/#84 keep the acceptance criteria (re-pin when upstream rebuilds clears the counts).Current posture: every active-path image is either digest-pinned (falco, openobserve, otel, rsigma, clamav×2, webhook-build, grype-debug, osquery-pin) or floating-by-design with a tracking issue (goflow2, dcgm, grype:latest as monitor). Weekly scan +
trivy-results-*artifacts are the standing guard; 44 historical alerts converge on subsequent uploads as suppressed rules drop out of new SARIFs.feat(compliance): schedule JIT expiry revocation via systemd user tim…
JJediny commentedon Oct 11, 2026
Closure-path milestone (2026-10-10): alert convergence completed
mitigated(via API, each with a 280-char rationale comment). Root cause documented: they were created by Sept-13 runs whose uploads predated the explicitcategory:inputs (PR security(deps): refresh digest-pinned images (openobserve, osquery, otel-contrib) #81), so their auto-derived categories could never see a clean re-analysis — the suppression uploads from Oct 4-5 (which zeroed the current categories) had no effect on them. This was never a suppression failure;.trivyignore+ pinning worked exactly as specified on first contact.#111), intentionally kept visible as the live re-pin signal.grype-debug+webhookmatrix entries scan the actually-deployed artifacts.clamav/clamavlatest + latest_base (1 HIGH each, 0 CRITICAL — pcre2 CVE-2026-103111) #111 via pcre2 rebuild, Reduce HIGH findings on anchore/grype (15 HIGH, 0 CRITICAL) #85 already closed) — all now have working detection signals.fix(ci): float otel-collector-contrib matrix entry as #115 rebuild mo…