Replies: 1 comment
-
|
I once considered implementing this, but when I actually started, it turned out to be more difficult than I had expected, so I suspended it. As far as I know, go-containerregistry does not have a platform fallback feature, so if we want to align the behavior with Docker, we need to implement it ourselves. Also, since I thought that although my local environment is often darwin/arm64, production environments are often linux/amd64, scanning linux/amd64 by default is not necessarily a bad thing. For that reason, I decided to leave it as is until we receive requests from the community. That said, there is some logic in the argument that the behavior should be consistent with scanning images locally. If it’s causing confusion, I think it would be better to implement it — has there already been any real negative impact? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
Current behavior:
docker), the container engine (docker) will detect the local platform and pull the relevant image.remote), we defer to go-container registry to decide, which defaults to linux/amd64.--image-srcisn't specified (which is the common case), Trivy automatically tries local and then remote, so the result will be determined by the presence of the the image in the local container engine. This might be confusing as the user will get different results for the same command.Suggestion:
Auto detect the local platform in remote source to match the behavior in local source.
The downside is that now the same scan on different machines might result in different outcome. But this might be more understandable since this behavior is similar to how local source (and docker pull) would have behaved.
Target
Container Image
Scanner
None
Beta Was this translation helpful? Give feedback.
All reactions