chore(deps): upgrade trivy#64
Conversation
Kimchi Code Review
Summary📊 Review Score: 62/100 (overall code quality — 0 lowest, 100 highest) 🧪 Tests: no — No test files or source code changes are visible in the provided diff to validate compatibility with the upgraded 📝 Found 6 issue(s). See inline comments for details. What to expectKimchi will analyze the changes in this pull request and post:
The review typically completes within a few minutes. This comment will be updated once the review is ready. Interact with Kimchi
ConfigurationReviews are configured by your organization admin. Powered by Kimchi — AI-powered code review by CAST AI |
![kimchi-review[bot]](https://avatars.githubusercontent.com/in/3223788?s=60&v=4){kind=small}
There was a problem hiding this comment.
📊 Review Score: 62/100 (overall code quality — 0 lowest, 100 highest)
⏱️ Estimated effort to review: 4/5 (1 = trivial, 5 = very complex)
🧪 Tests: no — No test files or source code changes are visible in the provided diff to validate compatibility with the upgraded trivy, docker, and containerd versions. The PR contains only go.mod and go.sum changes, so test coverage for the dependency bump cannot be assessed.
📝 Found 6 issue(s). See inline comments for details.
| toolchain go1.24.2 | ||
| go 1.25.8 | ||
|
|
||
| require ( |
There was a problem hiding this comment.
🚨🐛 Bug
The PR upgrades github.com/docker/docker from v27.5.1 to v28.5.2 (an +incompatible major version bump) and github.com/aquasecurity/trivy from v0.61.1 to v0.70.0 (spanning nine minor versions) without any visible changes to .go source files. Both ecosystems frequently introduce breaking Go API changes in these ranges. Because these are direct dependencies, the application almost certainly imports their packages, so the build will likely fail due to moved or renamed types.
💡 Suggestion: Run go build ./... to identify compilation errors, then update all direct consumers of github.com/docker/docker and github.com/aquasecurity/trivy packages to match the new APIs. Add or update integration tests covering image analysis before merging.
| github.com/cenkalti/backoff/v5 v5.0.3 // indirect | ||
| github.com/cespare/xxhash/v2 v2.3.0 // indirect | ||
| github.com/chai2010/gettext-go v1.0.2 // indirect | ||
| github.com/cheggaaa/pb/v3 v3.1.7 // indirect |
There was a problem hiding this comment.
The module directly requires github.com/containerd/containerd at v1.7.30 while transitively pulling in github.com/containerd/containerd/v2 at v2.2.2. Linking both major versions of the containerd client into the same binary bloats the artifact and risks runtime type confusion or panics if packages accidentally mix v1 and v2 APIs.
💡 Suggestion: Audit imports to ensure the codebase and its dependencies consistently use either containerd v1 or v2. If the ecosystem has migrated, upgrade the direct dependency to github.com/containerd/containerd/v2; otherwise, use exclude directives to force a unified version.
| github.com/distribution/reference v0.6.0 // indirect | ||
| github.com/dlclark/regexp2 v1.4.0 // indirect | ||
| github.com/docker/cli v27.5.0+incompatible // indirect | ||
| github.com/dlclark/regexp2 v1.11.0 // indirect |
There was a problem hiding this comment.
The dependency graph now transitively includes github.com/docker/cli at v29.4.0 while github.com/docker/docker is pinned at v28.5.2. Docker CLI and Engine shared libraries are typically released in lockstep; a one-major-version skew increases the risk of API mismatches in underlying types (e.g., api/types, registry).
💡 Suggestion: Align the docker/cli transitive dependency with the docker/docker major version by adding a replace directive or upgrading the direct docker/docker dependency to v29.x.
| github.com/moby/moby/api v1.54.1 // indirect | ||
| github.com/moby/moby/client v0.4.0 // indirect | ||
| github.com/moby/sys/atomicwriter v0.1.0 // indirect | ||
| github.com/moby/sys/mountinfo v0.7.2 // indirect |
There was a problem hiding this comment.
The upgrade transitively introduces github.com/moby/moby/api and github.com/moby/moby/client alongside the legacy github.com/docker/docker module. This indicates Docker SDK types are migrating to new moby/moby module paths, which can cause identifier collisions or incompatible type identities if both module trees define the same primitives.
💡 Suggestion: Verify that no package imports the same Docker type from both github.com/docker/docker/... and github.com/moby/moby/... paths. Pin moby/moby submodules via replace if the project has not yet migrated away from github.com/docker/docker types.
| go.opentelemetry.io/otel/trace v1.34.0 // indirect | ||
| go.opentelemetry.io/auto/sdk v1.2.1 // indirect | ||
| go.opentelemetry.io/contrib/detectors/gcp v1.39.0 // indirect | ||
| go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.63.0 // indirect |
There was a problem hiding this comment.
The upgrade replaces oras.land/oras-go v1.2.5 with oras.land/oras-go/v2 v2.6.0. ORAS v2 is a major rewrite with breaking changes for OCI artifact push/pull and authentication. Indirect consumers such as go-containerregistry or trivy may fail if they expect ORAS v1 types.
💡 Suggestion: Confirm that all indirect consumers in the module graph are compatible with ORAS v2. If a direct dependency still requires ORAS v1, upgrade it to an ORAS-v2-compatible release before merging.
| go 1.24 | ||
|
|
||
| toolchain go1.24.2 | ||
| go 1.25.8 |
There was a problem hiding this comment.
The go directive was bumped from 1.24 to 1.25.8 and the explicit toolchain go1.24.2 pin was removed. This forces automatic toolchain resolution, which may fail in air-gapped CI environments or where GOTOOLCHAIN is restricted. It also requires all developers and build nodes to support Go 1.25.
💡 Suggestion: Re-add an explicit toolchain directive for reproducible builds (e.g., toolchain go1.25.8) and ensure CI images and local development environments are pre-installed with the target Go version or have network access for automatic toolchain download.
- Migrate containerd v1 to v2 (fixes runtime-spec v1.3.0 incompatibility where LinuxPids.Limit changed from int64 to *int64) - Update Docker API types: container.Config -> dockerspec.DockerOCIImageConfig - Wrap Docker client ImageSave to match imageSave type signature - Pin trivy to v0.66.0 to avoid encoding/json/v2 GOEXPERIMENT requirement - Bump go directive to 1.26.2
1 participant
Kimchi Summary
What changed
Upgrades core dependencies including Trivy to
v0.66.0, containerd tov2.2.2, Docker Engine tov28.5.2, and Go to1.26.2. Adapts containerd and Docker daemon integrations to new major-version APIs and replaces legacycontainer.Configtypes with the OCI Docker image spec.Why
Keeps the image analyzer current with upstream vulnerability scanning improvements, security patches, and breaking API changes in the container runtime ecosystem.
Key changes
go.mod: Bump Go to1.26.2,github.com/aquasecurity/trivytov0.66.0,github.com/containerd/containerd/v2tov2.2.2,github.com/docker/dockertov28.5.2, andgithub.com/google/go-containerregistrytov0.21.2.image/daemon/containerd.go: Migrate containerd imports to v2 module paths (client,core/content,core/images/archive,pkg/namespaces). Replacegithub.com/containerd/containerd/reference/dockerwithgithub.com/distribution/reference. Updateinspectto useclient.Imageandreference.Named, and switch the returned config todockerspec.DockerOCIImageConfig.image/daemon/docker.go: Wrapc.ImageSavein an inline adapter to match thefunc(context.Context, []string) (io.ReadCloser, error)signature expected byimageOpener.image/daemon/image.go: UpdateimageConfigto accept*dockerspec.DockerOCIImageConfig, dropping obsolete Docker runtime fields (AttachStderr,Tty,Hostname, etc.) and mapping only OCI-relevant fields.image/daemon/image.go: Fix exposed-ports copy loop to iterate overconfig.ExposedPortsinstead of the empty destination map.Impact