{"id":2971,"date":"2025-12-03T13:52:38","date_gmt":"2025-12-03T13:52:38","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/12\/03\/securing-the-docker-mcp-catalog-commit-pinning-agentic-auditing-and-publisher-trust-levels\/"},"modified":"2025-12-03T13:52:38","modified_gmt":"2025-12-03T13:52:38","slug":"securing-the-docker-mcp-catalog-commit-pinning-agentic-auditing-and-publisher-trust-levels","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/12\/03\/securing-the-docker-mcp-catalog-commit-pinning-agentic-auditing-and-publisher-trust-levels\/","title":{"rendered":"Securing the Docker MCP Catalog: Commit Pinning, Agentic Auditing, and Publisher Trust Levels"},"content":{"rendered":"

Trust is the most important consideration when you connect AI assistants to real tools. While MCP containerization<\/a> provides strong isolation and limits the blast radius of malfunctioning or compromised servers, we\u2019re continuously strengthening trust and security across the Docker MCP solutions to further reduce exposure to malicious code. As the MCP ecosystem scales from hundreds to tens of thousands of servers (and beyond), we need stronger mechanisms to prove what code is running, how it was built, and why it\u2019s trusted.<\/p>\n

To strengthen trust across the entire MCP lifecycle, from submission to maintenance to daily use, we\u2019ve introduced three key enhancements:<\/p>\n

    \n
  1. Commit Pinning<\/strong>: Every Docker-built MCP server in the Docker MCP Registry<\/a> (the source of truth for the MCP Catalog<\/a>) is now tied to a specific Git commit, making each release precisely attributable and verifiable.<\/li>\n
  2. Automated, AI-Audited Updates<\/strong>: A new update workflow keeps submitted MCP servers current, while agentic reviews of incoming changes make vigilance scalable and traceable.<\/li>\n
  3. Publisher Trust Levels<\/strong>: We\u2019ve introduced clearer trust indicators in the MCP Catalog, so developers can easily distinguish between official, verified servers and community-contributed entries.<\/li>\n<\/ol>\n

    These updates raise the bar on transparency and security for everyone building with and using MCP at scale with Docker.<\/p>\n\n

    Commit pins for local MCP servers<\/h2>\n

    Local MCP servers in the Docker MCP Registry are now tied to a specific Git commit with source.commit<\/strong>. That commit hash is a cryptographic fingerprint for the exact revision of the server code that we build and publish. Without this pinning, a reference like latest<\/strong> or a branch name would build whatever happens to be at that reference right now, making builds non-deterministic and vulnerable to supply chain attacks if an upstream repository is compromised. Even Git tags aren\u2019t really immutable since they can be deleted and recreated to point to another commit. By contrast, commit hashes are cryptographically linked to the content they address, making the outcome of an audit of that commit a persistent result.<\/p>\n

    To make things easier, we\u2019ve updated our authoring tools (like the handy MCP Registry Wizard<\/a>) to automatically add this commit pin when creating a new server entry, and we now enforce the presence of a commit pin in our CI pipeline<\/a> (missing or malformed pins will fail validation). This enforcement is deliberate: it\u2019s impossible to accidentally publish a server without establishing clear provenance for the code being distributed. We also propagate the pin into the MCP server image metadata via the org.opencontainers.image.revision<\/strong> label for traceability.<\/p>\n

    Here\u2019s an example of what this looks like in the registry:<\/p>\n

    \n
    \n# servers\/aws-cdk-mcp-server\/server.yaml\nname: aws-cdk-mcp-server\nimage: mcp\/aws-cdk-mcp-server\ntype: server\nmeta:\n  category: devops\n  tags:\n    - aws-cdk-mcp-server\n    - devops\nabout:\n  title: AWS CDK\n  description: AWS Cloud Development Kit (CDK) best practices, infrastructure as code patterns, and security compliance with CDK Nag.\n  icon: https:\/\/avatars.githubusercontent.com\/u\/3299148?v=4\nsource:\n  project: https:\/\/github.com\/awslabs\/mcp\n  commit: 7bace1f81455088b6690a44e99cabb602259ddf7\n  directory: src\/cdk-mcp-server\n\n<\/pre>\n<\/div>\n
    And here\u2019s an example of how you can verify the commit pin for a published MCP server image:<\/p>\n
    \n
    \n$ docker image inspect mcp\/aws-core-mcp-server:latest \n    --format '{{index .Config.Labels \"org.opencontainers.image.revision\"}}'\n7bace1f81455088b6690a44e99cabb602259ddf7\n\n<\/pre>\n<\/div>\n
    In fact, if you have the cosign<\/strong> and jq<\/strong> commands available, you can perform additional verifications:<\/p>\n
    \n
    \n$ COSIGN_REPOSITORY=mcp\/signatures cosign verify mcp\/aws-cdk-mcp-server --key https:\/\/raw.githubusercontent.com\/docker\/keyring\/refs\/heads\/main\/public\/mcp\/latest.pub | jq -r ' .[].optional[\"org.opencontainers.image.revision\"] '\n\nVerification for index.docker.io\/mcp\/aws-cdk-mcp-server:latest --\nThe following checks were performed on each of these signatures:\n  - The cosign claims were validated\n  - Existence of the claims in the transparency log was verified offline\n  - The signatures were verified against the specified public key\n7bace1f81455088b6690a44e99cabb602259ddf7\n\n<\/pre>\n<\/div>\n
    Keeping in sync<\/h3>\n
    Once a server is in the registry, we don\u2019t want maintainers needing to hand\u2011edit pins every time they merge something into their upstream repos (they have better things to do with their time), so a new automated workflow<\/a> scans upstreams nightly, bumping source.commit<\/strong> when there\u2019s a newer revision, and opening an auditable PR in the registry to track the incoming upstream changes.\u00a0 This gives you the security benefits of pinning (immutable references to reviewed code) without the maintenance toil. Updates still flow through pull requests, so you get a review gate and approval trail showing exactly what new code is entering your supply chain. The update workflow operates on a per-server basis, with each server update getting its own branch and pull request.<\/p>\n
    This raises the question, though: how do we know that the incoming changes are safe?<\/p>\n
    AI in the review loop, humans in charge<\/h2>\n
    Every proposed commit pin bump (and any new local server) will now be subject to an agentic AI security review<\/strong> of the incoming upstream changes. The reviewers (Claude Code<\/a> and OpenAI Codex<\/a>) analyze MCP server behavior, flagging risky or malicious code, adding structured reports to the PR, and offering standardized labels such as security-risk:high<\/strong> or security-blocked<\/strong>. Humans remain in the loop for final judgment, but the agents are relentless and scalable.<\/p>\n
    The challenge: untrusted code means untrusted agents<\/h3>\n
    When you run AI agents in CI to analyze untrusted code, you face a fundamental problem: the agents themselves become attack vectors. They\u2019re susceptible to prompt injection<\/a> through carefully crafted code comments, file names, or repository structure. A malicious PR could attempt to manipulate the reviewing agent into approving dangerous changes, exfiltrating secrets, or modifying the review process itself.<\/p>\n
    We can\u2019t trust the code under review, but we also can\u2019t fully trust the agents reviewing it.<\/p>\n
    Isolated agents<\/h3>\n
    Our Compose<\/a>-based security reviewer architecture<\/a> addresses this trust problem by treating the AI agents as untrusted components. The agents run inside heavily isolated Docker containers with tightly controlled inputs and outputs:<\/p>\n