Bump x/crypto, x/net and cel-go to clear trivy image findings

[wallrj-cyberark]

Why now?

We are about to tag v1.12.0-alpha.0. Trivy reports three fixable vulnerabilities, including a CRITICAL, in all three images we publish — venafi-agent, disco-agent and discovery-agent. This clears all three.

Module	Was	Now	Severity	ID
golang.org/x/crypto	v0.52.0	v0.57.0	CRITICAL	CVE-2026-56854, ssh auth bypass
golang.org/x/net	v0.55.0	v0.58.0	HIGH	CVE-2026-46600, dns/dnsmessage DoS
github.com/google/cel-go	v0.28.1	v0.30.0	MEDIUM	GHSA-gcjh-h69q-9w9g, JSON private fields exposed

Found by running the proposed oci-security-scan target from cert-manager/makefile-modules#688 against this repo.

Two of the fixed versions are not the obvious ones

Both caught by @FelixPhipps in review; I verified each against the module source and the Go vulnerability database before changing anything.

cel-go needs v0.30.0, not the v0.29.0 the GitHub advisory names. ext/native.go is byte-identical between v0.28.1 and v0.29.0. The isSkippedFieldName guard that actually fixes it first appears in v0.30.0:

$ diff cel-go@v0.28.1/ext/native.go cel-go@v0.29.0/ext/native.go
$ diff cel-go@v0.29.0/ext/native.go cel-go@v0.30.0/ext/native.go
166a167,170
> func isSkippedFieldName(name string) bool {
> 	return name == "" || name == "-"
> }

The databases disagree, and the Go one is right:

Source	Fixed in
GitHub Advisory GHSA-gcjh-h69q-9w9g	0.29.0
Go vuln DB GO-2026-6094 (same advisory)	0.30.0

Trivy resolves Go advisories against the GitHub database. So the first version of this PR bumped to v0.29.0 and the scan came back clean — a metadata error, not a fix. Worse, it would have marked the one plausibly-reachable finding as resolved while leaving it in place.

x/crypto needs at least v0.56.0. Two further x/crypto/ssh advisories were published on 2026-09-02, after v0.55.0: CVE-2026-78662 (GO-2026-6354) and CVE-2026-56855 (GO-2026-6355). Confirmed against vuln.go.dev, both fixed in 0.56.0. Tagging at v0.55.0 would have meant fresh findings appearing within days.

These are almost certainly not exploitable here

This explains why govulncheck reports zero while trivy reports three, and it should shape how urgently you treat it. I checked what is actually linked:

• CRITICAL, x/crypto. Only golang.org/x/crypto/pbkdf2 is linked. golang.org/x/crypto/ssh, where every one of these advisories lives, is not in the binary at all.
• HIGH, x/net. Linked packages are idna, httpguts, http2, http2/hpack, html. dns/dnsmessage from the module is not linked — the apparent hit is the Go standard library's own vendored copy.
• MEDIUM, cel-go. cel-go/ext, where NativeTypes lives, is linked, via the Kubernetes apiserver CEL support. This is the one that is at least plausibly reachable, though govulncheck does not see the vulnerable symbols being called. It is also the one the v0.29.0 mistake would have papered over.

So why bump at all? Trivy works from module versions recorded in the binary, not reachability. So do Artifact Hub and the scanners our customers run. A released image gets reported as carrying a CRITICAL regardless of exploitability, and that becomes a support conversation.

This is hygiene, not an incident. It should not be read as "we shipped an exploitable CRITICAL".

What changed

go get golang.org/x/crypto@v0.57.0 github.com/google/cel-go@v0.30.0 && go mod tidy, then make generate.

Only go.mod and go.sum. make generate produced no further changes, so LICENSES is untouched — it records no versions, and no dependency was added or removed. All three are indirect dependencies and there is no source change to review.

x/crypto v0.57.0 pulls x/net to v0.58.0 by MVS, past the 0.56.0 that fixes CVE-2026-46600, and brings sync, sys, term and text forward.

Testing

All three images clean, plus verify, 457 unit tests and govulncheck

Before, on master at 2463606, make --keep-going oci-security-scan exits 2:

Scanning jetstack.local/venafi-agent     Total: 3 (MEDIUM: 1, HIGH: 1, CRITICAL: 1)
Scanning jetstack.local/disco-agent      Total: 3 (MEDIUM: 1, HIGH: 1, CRITICAL: 1)
Scanning jetstack.local/discovery-agent  Total: 3 (MEDIUM: 1, HIGH: 1, CRITICAL: 1)

After this change it exits 0, with all three images reporting no findings.

Note the cel-go part of that clean result is not by itself proof, for the database reason above — trivy would have called v0.29.0 clean too. The evidence for cel-go is the source diff and GO-2026-6094, not the scanner.

Also on this branch:

• make verify — exit 0
• make test-unit — 457 tests, 0 failures
• make verify-govulncheck — 0 vulnerabilities (unchanged; it was already zero, which is the point above)

--keep-going matters when reproducing. Without it, make stops at the first failing image and you see only one of three reports.

[FelixPhipps]

Reviewed this. The mechanics are sound: go mod tidy is a no-op on top of the branch, LICENSES genuinely doesn't need regenerating (it records no versions, and no dependency was added or removed), and the MVS claim checks out — golang.org/x/crypto@v0.55.0 does require golang.org/x/net@v0.57.0, so overshooting 0.56.0 is forced rather than chosen. Your reachability analysis is also exactly right; go list -deps confirms only x/crypto/pbkdf2 is linked (no ssh), the only dns/dnsmessage is the stdlib's vendored copy, and cel-go/ext is linked.

Two findings, both the same shape: the versions picked aren't the ones that actually clear the advisories.

1. cel-go v0.29.0 does not fix GHSA-gcjh-h69q-9w9g

ext/native.go is byte-identical between v0.28.1 and v0.29.0. The fix — an isSkippedFieldName guard that skips fields tagged json:"-" in Fields(), FindStructFieldType and friends — first lands in v0.30.0:

$ diff cel-go@v0.28.1/ext/native.go cel-go@v0.29.0/ext/native.go
$ diff cel-go@v0.29.0/ext/native.go cel-go@v0.30.0/ext/native.go
164a165,168
> func isSkippedFieldName(name string) bool {
>       return name == "" || name == "-"
> }
...
289c293
<               fields := make([]string, fieldCount)
---
>               fields := make([]string, 0, fieldCount)

The two vulnerability databases disagree, which is what makes this easy to miss:

Source	Fixed in
GitHub Advisory GHSA-gcjh-h69q-9w9g	0.29.0
Go vuln DB GO-2026-6094 (same advisory)	0.30.0

The source says the Go DB is right. Trivy resolves Go module advisories against the GitHub database, so it reports this as fixed at v0.29.0 — which is why the post-bump scan came back clean. That clean result is a metadata error, not a fix.

This is the one that matters most, because it's the one you correctly identify as plausibly reachable. As it stands the change clears two findings that were never reachable, leaves the one that might be, and makes the scanner report it as resolved.

2. x/crypto v0.55.0 was superseded a week before this PR

Two further x/crypto/ssh advisories were published on 2026-09-02, both fixed in v0.56.0:

• CVE-2026-78662 / GO-2026-6354 — DoS on deadlocked undecided channel
• CVE-2026-56855 / GO-2026-6355 — DoS on deadlocked established channel

Same reachability story as CVE-2026-56854 — x/crypto/ssh isn't in the binary, so neither is exploitable here. But by this PR's own (correct) argument that isn't the point: trivy, Artifact Hub and customer scanners key off the recorded module version. Tagging v1.12.0-alpha.0 at x/crypto v0.55.0 means the image starts reporting two fresh x/crypto findings as soon as those reach the scanner DBs, and we're back in the same conversation within days.

Suggested

go get github.com/google/cel-go@v0.30.0 golang.org/x/crypto@v0.57.0 && go mod tidy

That gives cel-go v0.30.0, x/crypto v0.57.0, x/net v0.58.0, plus sync/sys/term/text forward. I ran it on this branch: go mod tidy is stable, go build ./... is clean, and go test ./... passes except the two cases needing KUBEBUILDER_ASSETS (Test_ValidateAndCombineConfig_VenafiConnection, TestVenConnClient_PostDataReadingsWithOptions) — an envtest setup gap in my local run, unrelated to the bump. Worth re-running oci-security-scan to confirm, but OSV reports no remaining advisories against any of the three at those versions.

One that won't go away either way: GO-2026-5932 ("x/crypto/openpgp is unmaintained") has no fixed version and applies to every release — not actionable, ignore it if it surfaces.

Nothing else to flag — the diff itself is clean and there's no source change to review.

[Generated with claude code]

[wallrj-cyberark]

Both findings confirmed and fixed. Force-pushed as e5ea0e8, now cel-go@v0.30.0 and x/crypto@v0.57.0 (which takes x/net to v0.58.0 by MVS).

I verified each one independently rather than take it on trust, and you are right on both counts.

cel-go. ext/native.go really is byte-identical between v0.28.1 and v0.29.0, and isSkippedFieldName first appears in v0.30.0:

$ diff cel-go@v0.28.1/ext/native.go cel-go@v0.29.0/ext/native.go
$ diff cel-go@v0.29.0/ext/native.go cel-go@v0.30.0/ext/native.go
166a167,170
> func isSkippedFieldName(name string) bool {
> 	return name == "" || name == "-"
> }

And the Go database backs it up:

$ curl -s https://vuln.go.dev/ID/GO-2026-6094.json
aliases: ['GHSA-gcjh-h69q-9w9g']
github.com/google/cel-go [{'introduced': '0.22.0'}, {'fixed': '0.30.0'}]

This is the one I am glad you caught. The clean trivy result on the previous push was a metadata artefact, and the effect would have been the worst of both worlds: the two findings that were never reachable get cleared, the one that plausibly is stays put, and the scanner starts reporting it as resolved. A green scan would have actively concealed it.

x/crypto. Confirmed too:

$ curl -s https://vuln.go.dev/ID/GO-2026-6354.json   # CVE-2026-78662
golang.org/x/crypto [{'introduced': '0'}, {'fixed': '0.56.0'}]
$ curl -s https://vuln.go.dev/ID/GO-2026-6355.json   # CVE-2026-56855
golang.org/x/crypto [{'introduced': '0'}, {'fixed': '0.56.0'}]

Same reachability story, and the same reason it does not matter: the argument for this PR was never exploitability, it was what the scanners report. Tagging at v0.55.0 would have put us back here inside a week. I went to v0.57.0 as you suggested rather than the minimum 0.56.0.

Re-verified after the change: make --keep-going oci-security-scan exits 0 with all three images clean, make verify passes, make test-unit gives 457 tests and 0 failures, make verify-govulncheck still reports 0.

I have added a caveat to the description noting that the clean cel-go scan result is not itself evidence, for exactly the database reason above — the evidence is the source diff and GO-2026-6094.

On your two envtest failures, Test_ValidateAndCombineConfig_VenafiConnection and TestVenConnClient_PostDataReadingsWithOptions: I hit the same pair earlier in this work and they passed on a re-run with nothing changed. In my case it was envtest startup contention from parallel builds on the same machine, so I think your reading of it as a local setup artefact is right.

Noted on GO-2026-5932 (x/crypto/openpgp unmaintained, no fixed version) — nothing to do there.

[FelixPhipps]

Thanks for the fix.

Approved!