fix(scanner): scan Docker-image servers in Trivy image mode (MCP-2398)#666
Merged
Conversation
Servers wired as `docker run <image>` (e.g. `command: docker`,
`args: [run, -i, --rm, mcp/fetch]`) were not mcpproxy-managed
containers, so the source resolver found no `mcpproxy-<name>-*`
container and fell through to source_method=tool_definitions_only.
Trivy then ran `fs /scan/source` on an empty temp dir (0 results) —
Docker-image servers got effectively zero scanning.
Detect the image reference from a `docker`/`podman run` command and
resolve it as a new `container_image` source method. Scanners that
declare the `container_image` input and provide an `ImageCommand`
template (Trivy) now run in image mode (`trivy image <ref>`) with
`{{IMAGE}}` substituted at runtime. Trivy resolves the image via the
local daemon/containerd/podman and falls back to pulling from the
remote registry, so no Docker socket mount is required.
- source_resolver: ResolvedSource.ContainerImage + dockerImageFromCommand,
wired into both Resolve (Pass 1) and ResolveFullSource (Pass 2)
- types/registry: ScannerPlugin.ImageCommand; Trivy image-mode template
- engine: ScanRequest.ContainerImage + effectiveScannerCommand selection
- service: carry the image, preserve the container_image method past the
tool-definitions temp dir, and don't abort image scans with 0 tools
Related MCP-2398
Deploying mcpproxy-docs with
|
| Latest commit: |
9043db0
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a3ccb216.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://fix-mcp-2398-docker-image-tr.mcpproxy-docs.pages.dev |
|
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 27501680978 --repo smart-mcp-proxy/mcpproxy-go
|
![mcpproxy-gatekeeper[bot]](https://avatars.githubusercontent.com/u/216428285?s=60&v=4){kind=small}
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
2 participants
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.
Problem
A server wired as a direct Docker invocation — e.g.
{ "name": "fetch", "command": "docker", "args": ["run", "-i", "--rm", "mcp/fetch"] }is not an mcpproxy-managed container. The source resolver only looks for
mcpproxy-<name>-*containers, found none, and fell through tosource_method=tool_definitions_only. Trivy then ranfs /scan/sourceagainstan empty temp dir → 0 results. Docker-image MCP servers got effectively
zero vulnerability scanning.
Fix
Detect the image reference from a
docker/podman runcommand and resolve itas a new
container_imagesource method. Scanners that declare thecontainer_imageinput and provide anImageCommandtemplate (Trivy) now runin image mode (
trivy image <ref>), with{{IMAGE}}substituted at runtime.Trivy resolves the image via the local daemon/containerd/podman and falls back
to pulling from the remote registry (network is already enabled for Trivy), so
no Docker socket mount is required — registry images like
mcp/fetchworkout of the box.
Changes (all in
internal/security/scanner/, backend lane)ResolvedSource.ContainerImage+dockerImageFromCommand(docker CLI arg grammar: value-flags,--flag=value/ attached forms, combined short booleans,docker container run). Wired into bothResolve(Pass 1) andResolveFullSource(Pass 2).ScannerPlugin.ImageCommand; Trivy getsimage --format sarif {{IMAGE}}.ScanRequest.ContainerImage+effectiveScannerCommandselects image-mode vs source-mode per scanner.container_imagemethod past the tool-definitions temp dir, and don't abort image scans even with 0 tools exported.Non-image scanners (Semgrep, Cisco) are unchanged — they keep scanning the
exported tool definitions. The Web UI already renders
source_methodand acontainer_imagebadge generically, so no frontend change is required.Tests (TDD)
New
image_scan_test.go:TestDockerImageFromCommand— 11 cases (docker/podman, value flags, attached=, combined booleans,container run, negatives).TestResolveDockerRunImage—Resolvereturnscontainer_image+ image ref.TestScannerCommandForImage— Trivy → image command w/ substitution; no image → source command; non-image scanner unchanged.Verification
Note:
go build -tags server ./...fails ininternal/teams/broker(undefinedCredentialStore/UpstreamCredential) — pre-existing on origin/main (PR #602 dependency), unrelated to this change and outside this lane.Related MCP-2398