sec(deps): bump go.opentelemetry.io/otel to v1.44.0 for GO-2026-5158

[cristim]

Closes #1837

Read this first: this PR clears one of the two advisories, not both

GO-2026-5932 has no fixed version and cannot be cleared by any dependency bump. The shipped binary still reports it after this change, and govulncheck -mode=binary still exits 3. Nothing here is suppressed; see "The one that cannot be fixed" below for the options. If you want #1837 to stay open to track that decision, drop the Closes keyword before merging.

The three advisories, confirmed against the live database

Each was fetched from https://vuln.go.dev/ID/<id>.json directly, not read from govulncheck's bundled copy.

Advisory	Module	Affected	Fixed	Direct or transitive	In the shipped binary?
GO-2026-5158 (CVE-2026-41178, GHSA-5wrp-cwcj-q835)	go.opentelemetry.io/otel	1.41.0-1.42.0, 1.43.0-1.44.0; we were on v1.43.0	v1.44.0	Transitive, via cloud.google.com/go/storage from providers/gcp/services/cloudstorage	Yes, before this PR
GO-2026-5932	golang.org/x/crypto	introduced: "0", no fixed event	none exists	Direct in root (internal/auth uses x/crypto/bcrypt), indirect elsewhere	Yes, still
GO-2026-5841 (GHSA-259r-337f-4rfw)	github.com/klauspost/compress	1.16.0-1.18.7; we are on v1.18.5	v1.18.7	Transitive, via testcontainers-go -> moby/go-archive from internal/database/postgres/testhelpers	No

GO-2026-5841 is not mentioned in #1837 and is not in the shipped binary; it is left alone here rather than bundled in as a drive-by. See "Left deliberately undone".

What this PR changes

go.opentelemetry.io/otel v1.43.0 -> v1.44.0 on the indirect require in the root and providers/gcp go.mod. Because otel arrives transitively, the correct fix is the indirect bump, not a new direct require. otel/metric and otel/trace move with it since the three release in lockstep. Per-module go mod tidy across all six workspace modules plus go work sync keep the checksum files consistent.

Seven files, +26/-19, no source changes.

The added go.sum / go.work.sum lines for non-otel modules (spf13/afero, lyft/protoc-gen-star/v2, stretchr/objx, two aws-sdk-go-v2 internals, proto/otlp) are module-graph checksums added by tidy/sync, not version changes. Diffing the fully resolved build list (go list -m all) across all six modules, before against after, shows exactly three modules changed selected version, all otel:

< go.opentelemetry.io/otel        v1.43.0    > go.opentelemetry.io/otel        v1.44.0
< go.opentelemetry.io/otel/metric v1.43.0    > go.opentelemetry.io/otel/metric v1.44.0
< go.opentelemetry.io/otel/trace  v1.43.0    > go.opentelemetry.io/otel/trace  v1.44.0

Zero unrelated dependencies moved. go work sync is idempotent afterwards and go mod verify passes in all six modules.

Reachability

Neither advisory is reachable in the shipped artifact. This changes urgency, not whether to fix.

• Source mode builds a real call graph from our entry points and reports Your code is affected by 0 vulnerabilities for every module, both before and after. The findings sit at "packages you import" and "modules you require" level.
• The binary's own symbol table agrees. The Dockerfile builds with -ldflags="-s -w", but the Go linker still retains function names in the pclntab. Method validated against a known-called symbol first: bcrypt.CompareHashAndPassword and bcrypt.GenerateFromPassword both resolve at function level in the binary, so absence is meaningful.
  • GO-2026-5158's vulnerable symbols are baggage.New, baggage.Parse, propagation.Baggage.Extract. The string baggage appears 0 times in the binary. propagation is linked (17 refs) but only compositeTextMapPropagator, HeaderCarrier, init and NewCompositeTextMapPropagator; the Baggage type is absent. The linker dead-code-eliminated the vulnerable path.
  • GO-2026-5932's packages are the openpgp tree. openpgp appears 0 times in the binary, and go list -deps finds no openpgp package anywhere in the workspace. We use x/crypto for bcrypt, chacha20poly1305, cryptobyte, hkdf and pkcs12.

Binary mode reports them anyway because govulncheck v1.1.4 cannot do call-graph analysis on a stripped binary and falls back to matching the advisory's declared symbol list against modules and packages it believes are present.

Why CI is green today

This answers the question #1837 raises. CI runs govulncheck in source mode, and source mode exits 0 when findings exist only at the import/require level. Every module returned text_exit=0 before this PR while GO-2026-5158, GO-2026-5932 and GO-2026-5841 were all being reported. The gate is not broken and is not misconfigured; it is scoped to "your code calls this", and no such finding exists. Binary mode on the same tree exits 3. That gap is exactly #1836, and nothing in this PR closes it.

Verification

Everything below was run locally at the CI-pinned versions. Exit codes captured into variables, never inferred from empty output. No grep -c 'Module: stdlib'; assertions are on the summary line and on a JSON OSV count.

govulncheck v1.1.4, source mode, per module

Module	Before: exit / distinct finding OSVs	After: exit / distinct finding OSVs
.	0 / 3: 5158, 5841, 5932	0 / 2: 5841, 5932
pkg	0 / 0	0 / 0
providers/aws	0 / 0	0 / 0
providers/azure	0 / 1: 5932	0 / 1: 5932
providers/gcp	0 / 2: 5158, 5932	0 / 1: 5932
tests/e2e	0 / 0	0 / 0

The root module also moves from "1 vulnerability in packages you import" to "0 in packages you import", which is the substantive change: the otel baggage and propagation packages are no longer an affected import.

govulncheck v1.1.4, binary mode, against /app/cudly from the built image

The image was built with the repo's own Dockerfile and the binary extracted from the builder stage, which is the exact file the runtime stage COPYs to /app/cudly.

before (linux/arm64):  Your code is affected by 2 vulnerabilities from 2 modules.   exit=3
                       OSV count = 2: GO-2026-5158, GO-2026-5932
                       stdlib finding OSVs = 0

after  (linux/arm64):  Your code is affected by 1 vulnerability from 1 module.      exit=3
                       OSV count = 1: GO-2026-5932
                       stdlib finding OSVs = 0

after  (linux/amd64):  Your code is affected by 1 vulnerability from 1 module.      exit=3
                       OSV count = 1: GO-2026-5932
                       stdlib finding OSVs = 0

The before-scan reproduces #1837's reported number exactly. The stdlib count is asserted on the finding's trace[0].module == "stdlib" in the JSON output, not on a text pattern. Before and after binaries confirmed distinct by sha256.

The amd64 baseline was not rebuilt locally: three attempts were killed mid-compile in this environment, and I am not going to claim a figure I did not observe. The arm64 baseline reproduces #1837's number exactly, the amd64 post-fix scan is above, and the advisory set is a property of the module graph, which is architecture-independent.

CI

All four workflow runs on 02e31db concluded success: pre-commit, CI - Build & Test, AWS Sanity, Azure Sanity.

Build, test and collateral

• go build ./...: exit 0 in all six modules.
• go test ./...: exit 0 in five modules. tests/e2e exits 1 with "./..." matched no packages, identical on the base commit; its only test file is behind //go:build e2e, and ci.yml already documents and special-cases this.
• golangci-lint v2.10.1 (CI pin, installed fresh; a newer local version has a different bundled ruleset): exit 0, 0 issues.
• gosec v2.28.0 (CI pin): exit 0 in all six modules. Confirmed it actually scanned rather than no-opping: root reports Files: 198, Lines: 72489, Issues: 0.
• go vet ./...: exit 0 in five modules, tests/e2e the same pre-existing no-packages exit 1.

The one that cannot be fixed

GO-2026-5932 is not a CVE in a specific version. It is a standing advisory that golang.org/x/crypto/openpgp is unmaintained and unsafe by design. Its affected range is introduced: "0" with no fixed event, so every version of golang.org/x/crypto that will ever exist matches. Bumping to the newest x/crypto changes nothing.

Options, none of which are taken here:

1. Accept it. We do not import openpgp at all; it is absent from the binary. The finding is module-level noise from an advisory that has no version to move to.
2. Drop golang.org/x/crypto. Not viable at proportionate cost: internal/auth uses bcrypt, and the module also arrives through the Azure and AWS SDKs for pkcs12 and chacha20poly1305.
3. Stop stripping the binary (-ldflags without -s -w), which would let binary-mode govulncheck do real symbol analysis and report 0. This is not suppression, it is giving the scanner the information it currently lacks, but it changes the shipped artifact and its size, so it is a deliberate call rather than something to slip into a dependency-bump PR.

Per the instruction not to mask anything, no ignore list, -scan narrowing, continue-on-error or allowlist was added.

Left deliberately undone

GO-2026-5841, github.com/klauspost/compress v1.18.5 -> v1.18.7. It has a fix available and would be a one-line indirect bump, but it is not one of the two advisories in #1837, it is not in the shipped binary, and the vulnerable package compress/s2 is not imported anywhere in the workspace (we reach compress/zstd through testcontainers in test helpers only). Held back rather than bundled in as drive-by scope. Say the word and it is a separate one-line PR.

Not verified

• The linux/amd64 baseline binary scan, as noted above.
• Binary-mode scanning of the final runtime image rather than the builder stage. The runtime stage only COPYs the identical file, but the full image was not assembled because the frontend stage is unrelated to this change.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 71354796-01da-4adc-9850-674f6c4aa19e

📥 Commits

Reviewing files that changed from the base of the PR and between 5501419 and 02e31db.

⛔ Files ignored due to path filters (5)

• go.sum is excluded by !**/*.sum
• go.work.sum is excluded by !**/*.sum
• pkg/go.sum is excluded by !**/*.sum
• providers/aws/go.sum is excluded by !**/*.sum
• providers/gcp/go.sum is excluded by !**/*.sum

📒 Files selected for processing (2)

• go.mod
• providers/gcp/go.mod

Included review availability: 1 review is currently available. Based on recent review activity, included reviews refill at 2 per hour.

---

📝 Walkthrough

Walkthrough

The root and GCP Go modules update indirect OpenTelemetry core, metric, and trace dependencies from v1.43.0 to v1.44.0. GCP OpenTelemetry SDK dependencies remain at v1.43.0.

Changes

OpenTelemetry dependency update

Layer / File(s)	Summary
Update indirect OpenTelemetry modules go.mod, providers/gcp/go.mod	The root and GCP modules update indirect OpenTelemetry core, metric, and trace dependencies to v1.44.0. GCP SDK dependencies remain at v1.43.0.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 02e31

This PR makes a localized dependency update to address the OpenTelemetry advisory without changing application source behavior; no actionable merge-blocking risk remains beyond normal checks and review.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Linked Issues check	❓ Inconclusive	The shown files support the dependency fix, but the summary does not verify all six modules, binary rescanning, or checksum synchronization.	Provide evidence that all affected workspace modules were updated and binary-mode govulncheck assertions pass; checksum files are excluded by the stated filters.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Out of Scope Changes check	✅ Passed	The reviewed changes are limited to OpenTelemetry dependency updates that directly support the linked security issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the OpenTelemetry dependency update and the vulnerability advisory it addresses.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch sec/1837-dependency-advisories

---

_{Comment @coderabbitai help to get the list of available commands.}