Problem
The image ships criteo/ocserv-exporter as a pre-built release binary (currently v0.2.2). That binary is compiled with Go 1.25.4, which bundles ~15 Go stdlib HIGH/CRITICAL CVEs that Trivy flags (crypto/tls, net/url, crypto/x509, net/http2, net/mail, mime, …).
v0.2.2 is the latest upstream release — there is no newer pre-built binary to bump to. The CVEs are therefore suppressed in .trivyignore as a stopgap.
Proposed fix
Build ocserv-exporter from source in a dedicated Go builder stage using a current Go toolchain (≥ 1.26), instead of downloading the release binary. This eliminates all bundled Go stdlib CVEs in one shot and makes the exporter track Go security releases independently of upstream's release cadence.
Considerations:
- Pin the source by tag + verify (the current approach pins the binary by SHA-256; source build should pin commit/tag).
- If upstream tooling lags, maintain a light fork.
- Re-evaluate whether the exporter is worth the maintenance vs. ocserv's own occtl metrics.
Cleanup when done
Remove the exporter Go-CVE block from .trivyignore once the binary is built with a patched Go.
Problem
The image ships criteo/ocserv-exporter as a pre-built release binary (currently v0.2.2). That binary is compiled with Go 1.25.4, which bundles ~15 Go stdlib HIGH/CRITICAL CVEs that Trivy flags (crypto/tls, net/url, crypto/x509, net/http2, net/mail, mime, …).
v0.2.2 is the latest upstream release — there is no newer pre-built binary to bump to. The CVEs are therefore suppressed in
.trivyignoreas a stopgap.Proposed fix
Build ocserv-exporter from source in a dedicated Go builder stage using a current Go toolchain (≥ 1.26), instead of downloading the release binary. This eliminates all bundled Go stdlib CVEs in one shot and makes the exporter track Go security releases independently of upstream's release cadence.
Considerations:
Cleanup when done
Remove the exporter Go-CVE block from
.trivyignoreonce the binary is built with a patched Go.