[pbalogh-sa]

Resolves open Aikido findings for tokenex.

• Bump golang.org/x/crypto to 0.57.0, golang.org/x/net to 0.60.0, golang.org/x/text to 0.42.0, google.golang.org/grpc to 1.83.1 (govulncheck clean)
• Raise minimum Go version to 1.26.10
• Replace deprecated google.CredentialsFromJSON with CredentialsFromJSONWithType
• Return an error when the OCI UPST has no exp claim instead of panicking
• Pin golangci-lint action to a commit SHA and set persist-credentials: false on checkout

Fixes riptideslabs/issues#695
Fixes riptideslabs/issues#696
Fixes riptideslabs/issues#698
Fixes riptideslabs/issues#699

[bonifaido]

Deps, GCP and CI changes look good. Two things before merging:

1. x/net and grpc are still vulnerable. govulncheck on this branch reports 6 reachable vulns; Aikido's target versions were stale:

• golang.org/x/net 0.55.0 → needs 0.60.0 (GO-2026-6603, 6610, 6611, 6612, 6617)
• google.golang.org/grpc 1.82.1 → needs 1.83.1 (GO-2026-6348, reachable via SPIFFE FetchJWTSVID)

go get golang.org/x/net@v0.60.0 google.golang.org/grpc@v1.83.1 builds, tests pass, and govulncheck is clean afterwards (it also pulls google.golang.org/api to 0.264).

2. DecodeJWTClaims doesn't change the security posture. It's still unverified decoding, just no longer matched by the rule. riptideslabs/issues#697 was a false positive: all four call sites only read exp or telemetry claims from tokens fetched from the issuer over TLS, nothing authz-related. I'd revert to ParseUnverified and mark the finding as a false positive in Aikido. If we keep the helper, see the inline comment, and rename it to something like UnverifiedJWTClaims with a doc comment saying it never verifies, ideally under internal/. As an exported pkg/util func it's easy to misuse later, and Aikido won't catch that. I'd skip the bot's suggested fix, it just calls ParseUnverified again.

Good: CredentialsFromJSONWithType(..., google.ServiceAccount, ...) closes off external_account credential sources, the nil-exp check in OCI fixes a panic on main, and the action SHA is the upstream v7.0.1 tag (a # v7.0.1 comment next to it would help).

[bonifaido]

strings.Split here reintroduces CVE-2025-30204 (fixed in golang-jwt v5.2.2): 1 MiB of dots allocates ~16 MiB, vs 384 B for ParseUnverified. strings.SplitN(token, ".", 4) keeps the len != 3 check working.

[pbalogh-sa]

Moot now: the helper was reverted in 3816545, so pkg/util/jwt.go is gone and the call sites are back on ParseUnverified.

[pbalogh-sa]

Thanks, addressed:

1. Bumped golang.org/x/net to 0.60.0 and grpc to 1.83.1 (f6b93e7). govulncheck is clean; this also pulled x/crypto 0.57.0, x/text 0.42.0 and google.golang.org/api 0.264.
2. Reverted DecodeJWTClaims back to ParseUnverified (3816545) and kept the OCI nil-exp fix as its own commit (808e28f). riptideslabs/issues#697 is no longer linked to this PR.
3. Added # v7.0.1 next to the pinned golangci-lint action SHA (fa0801d).

[bonifaido]

LGTM, thanks. govulncheck is clean on the new head and tests pass.

riptideslabs/issues#697 is still open though. Can you mark it as a false positive in Aikido and close it? The four ParseUnverified sites only read exp or telemetry claims from tokens fetched from the issuer over TLS, so there are no authz decisions on unverified claims.