Skip to content

fix: remediate Go dep + docs vulns + bump Go 1.26.7 - #207

Merged
kycheng merged 5 commits into
AlaudaDevops:alauda-v0.68.2from
kycheng:fix/vuln-remediation-2026-08
Aug 28, 2026
Merged

kycheng merged 5 commits into
AlaudaDevops:alauda-v0.68.2from
kycheng:fix/vuln-remediation-2026-08

Conversation

@kycheng

@kycheng kycheng commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Bumps vulnerable Go modules and docs Python packages to their fixed versions (trivy fs scan, all severities with a fix version).

Go toolchain

  • go directive 1.26.4 -> 1.26.7 (stdlib CVE baseline; GOEXPERIMENT=jsonv2 preserved via magefile)

Go dependencies

Force-pinned indirect deps via require because the upstream chain still resolves to lower versions.

Not fixable now: github.com/docker/docker (installed pseudo-version; trivy DB advises 29.3.1 but no v29.x tag exists on moby/moby yet).

docs/build/requirements.txt (mkdocs, docs-only)

  • idna 3.10 -> 3.15
  • jinja2 3.1.4 -> 3.1.6
  • markdown 3.7 -> 3.8.1
  • pygments 2.19.2 -> 2.20.0
  • pymdown-extensions 10.12 -> 11.0.1
  • requests 2.32.3 -> 2.33.0
  • urllib3 2.2.3 -> 2.7.0

Verification

  • go build ./cmd/trivy clean
  • go mod tidy clean
  • trivy fs post-fix rescan: 0 Go vulns / 0 docs Python vulns with a fix version

Part of harbor Wave-1 vuln remediation. Related:

Bumps vulnerable Go modules and docs Python packages to their fixed
versions (trivy fs scan, all severities with a fix version).

## Go toolchain

- go directive 1.26.4 -> 1.26.7 (stdlib CVE baseline;
  GOEXPERIMENT=jsonv2 preserved via magefile)

## Go dependencies

Direct + transitive bumps:
- github.com/moby/buildkit -> v0.31.1 (CVE-2026-61711 MED, CVE-2026-61712 LOW)
- golang.org/x/mod -> v0.40.0 (CVE-2026-56864, CVE-2026-56865 HIGH)

Force-pinned indirect via require (upstream chain still exposes lower):
- github.com/go-git/go-git/v5 -> v5.19.2 (CVE-2026-71556 HIGH, CVE-2026-71557 MED)
- github.com/google/cel-go -> v0.29.0 (GHSA-gcjh-h69q-9w9g MED)
- github.com/moby/go-archive -> v0.3.0 (CVE-2026-17106 HIGH)
- github.com/sigstore/sigstore-go -> v1.2.1 (CVE-2026-49834 MED, CVE-2026-54787 LOW)
- google.golang.org/grpc -> v1.82.1 (GHSA-hrxh-6v49-42gf HIGH)
- oras.land/oras-go/v2 -> v2.6.2 (CVE-2026-50163 HIGH)

Not fixable now: github.com/docker/docker (installed pseudo-version;
trivy DB advises 29.3.1 but no v29.x tag exists on moby/moby yet).

## docs/build/requirements.txt (mkdocs deps, docs-only)

- idna 3.10 -> 3.15
- jinja2 3.1.4 -> 3.1.6
- markdown 3.7 -> 3.8.1
- pygments 2.19.2 -> 2.20.0
- pymdown-extensions 10.12 -> 11.0.1
- requests 2.32.3 -> 2.33.0
- urllib3 2.2.3 -> 2.7.0

## Verification

- 'go build ./cmd/trivy' clean
- 'go mod tidy' clean
- 'trivy fs' post-fix rescan: 0 Go vulns / 0 docs Python vulns with a fix version
## Documentation Test — mkdocs-material vs pymdown-extensions conflict

mkdocs-material 9.5.44 pins pymdown-extensions ~=10.2, so bumping
pymdown to 11.0.1 broke pip's resolver. Advance mkdocs-material to
9.7.7 which accepts pymdown >=10.2 (so 11.x is allowed), and pin
pymdown-extensions to the newest 11.x (11.0.2) for maximum coverage.

- docs/build/requirements.in: mkdocs-material 9.5.44 -> 9.7.7
- docs/build/requirements.txt: mkdocs-material 9.5.44 -> 9.7.7;
  pymdown-extensions 11.0.1 -> 11.0.2

## Test (ubuntu-latest) — remote image ArtifactType check regression

Bumping moby/buildkit -> v0.31.1 (CVE-2026-61711 / -61712) transitively
pulled go-containerregistry v0.20.7 -> v0.21.6. As of v0.21,
remote.Get() populates Descriptor.ArtifactType with the config media
type for standard Docker v2 / OCI 1.1 container images (previously
empty). pkg/fanal/image/remote.go rejected ANY non-empty ArtifactType
as 'unsupported artifact type', so TestNewDockerImage and
TestNewDockerImageWithPrivateRegistry started failing for regular
alpine:3.10 pulls.

Relax the check to still reject helm charts, WASM, and other real OCI
artifacts, but treat the two standard container-image config media
types as regular images:
  - application/vnd.docker.container.image.v1+json
  - application/vnd.oci.image.config.v1+json

The existing TestTryRemote/helm chart config media type case (which
uses application/vnd.cncf.helm.chart) still exercises the reject path
and continues to pass.

Verification:
- 'go test ./pkg/fanal/image/...' clean
## Symptom
Integration Test + Module Integration Test hung indefinitely (>2h)
in the FixtureContainerImages step, specifically at:
  Downloading ghcr.io/aquasecurity/trivy-test-images:spring4shell-jre11...

## Root cause
The moby/buildkit v0.28 -> v0.31.1 bump (CVE-2026-61711/-61712)
transitively pulled go-containerregistry from v0.20.7 to v0.21.6.
crane.Pull() in v0.21.x hangs (never times out, never errors) on
that particular GHCR manifest — reproducible across two runs.
v0.21.3 migrated the module to github.com/moby/moby modules and
changed manifest/artifact handling; no upstream fix in v0.21.7-v0.22
addresses this.

## Fix
Use a 'replace' directive to pin go-containerregistry to v0.20.7
(the baseline version) while keeping moby/buildkit at v0.31.1 so
the CVE fixes stay in place. buildkit's own use of go-containerregistry
is limited and works fine at v0.20.7 (v0.30 shipped with that pin).

Verified:
- trivy fs rescan: 0 Go vulns with a fix version
- go build ./... clean
Replace the hard-coded config media-type allowlist added in the previous
commit with the canonical upstream approach, backported from
aquasecurity/trivy commit 3ea80c0 ("chore(deps): bump
github.com/google/go-containerregistry to v0.21.6", #10741).

The upstream form is more robust:
- no hard-coded media-type strings
- IsConfig() covers Docker v1, Docker v2 and OCI config media types
- future config media types are handled without further changes

Behavior is equivalent: helm chart / WASM / other real OCI artifact
types still fall through to the reject path (verified by existing
TestTryRemote/helm chart config media type case).

Note: the 'replace github.com/google/go-containerregistry => v0.20.7'
directive is kept because it addresses a separate problem — the
crane.Pull() hang in fixtureContainerImages() on GHCR spring4shell-jre11
(FixtureContainerImages step). That is a different code path from
tryRemote() and is not fixed by IsConfig().
Experiment to verify whether the go-containerregistry v0.21.6 crane.Pull
hang on ghcr.io/aquasecurity/trivy-test-images:spring4shell-jre11 is a
persistent regression or was environmental (e.g. cold GHCR cache on
fork PR runs). Upstream aquasecurity/trivy runs on v0.21.6 without a
replace, so this may work here too now that IsConfig() is in place.

If CI passes: revert the previous replace commit, keep this drop.
If Integration Test hangs again (>30m in FixtureContainerImages): revert
this commit and keep the pin as permanent.
@kycheng
kycheng merged commit b81f375 into AlaudaDevops:alauda-v0.68.2 Aug 28, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants