Repository navigation
fix: remediate Go dep + docs vulns + bump Go 1.26.7 - #207
Merged
kycheng merged 5 commits intoAug 28, 2026
Merged
Conversation
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
yuzichen12123
approved these changes
Aug 28, 2026
## 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps vulnerable Go modules and docs Python packages to their fixed versions (
trivy fsscan, all severities with a fix version).Go toolchain
godirective 1.26.4 -> 1.26.7 (stdlib CVE baseline;GOEXPERIMENT=jsonv2preserved via magefile)Go dependencies
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)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)Force-pinned indirect deps via
requirebecause 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)
idna3.10 -> 3.15jinja23.1.4 -> 3.1.6markdown3.7 -> 3.8.1pygments2.19.2 -> 2.20.0pymdown-extensions10.12 -> 11.0.1requests2.32.3 -> 2.33.0urllib32.2.3 -> 2.7.0Verification
go build ./cmd/trivycleango mod tidycleantrivy fspost-fix rescan: 0 Go vulns / 0 docs Python vulns with a fix versionPart of harbor Wave-1 vuln remediation. Related: