Proposal: Incorporate Secure Software Supply Chain Principles #526

MCP has quickly become prominent within the generative AI community. As the project scales and engages with external integrations, the risks inherent in complex software supply chains become more pronounced. Integrating secure software supply chain principles is not only a proactive measure against threats like dependency tampering, malicious code injection, and compromised integrations, but also a differentiator that instills trust with end users and stakeholders.

This proposal recommends embedding these principles into both the internal workflow and external server integration specifications to ensure a resilient and trustworthy ecosystem.

Proposal

There are two things I am proposing and they are:

• Changes to how MCP server and all its various sdk artifacts are built and published
• Changes to the MCP specification to enforce routing to verifiable tools/servers

Internal Workflow Changes

Following SLSA guidance, the MCP team could update existing release pipelines to include things like:

• Artifact signing using tools like notation and cosign. This would help ensure integrity, prove the provenance and the authenticity of the artifacts
  • I recommend using both to give the end users the option
• Dependency scanning to check for known vulnerabilities
• Publishing Software Bill of Materials (SBOMs) to help with understanding the dependencies used by the software and to help the end user conduct vulnerability scanning in their own environment
• Enforcing signed commits for anyone contributing to any MCP project and prevent PRs from merging until all commits are signed by the contributor
• Provide an in-toto attestation to prove each task in the chain were carried out as planned

A good example of the above implemented in action is most, if not all, CNCF projects. flux2 comes to mind.

Integrating with 3rd Party Tools/Servers

When it comes to running your own MCP server, either local or externally, you may or may not want to integrate with other tools/servers created by other users. If you are running your own MCP server in a Kubernetes cluster for example, you can rely of 3rd party tools like flux2 and gatekeeper to ensure the trustworthiness of the platform. However, a problem arises when running these servers locally.

When running these servers locally you don't have an underlining platform you can rely on to ensure only signed and verifiable servers are used by the end client.

I propose an update to the specification highlighting that clients consuming a server running locally (either as a docker container or as a package) has the option to verify the authenticity and integrity of these servers before allowing the client to consume the underlining tools. The specification could be extended to verifying external servers as well in a future revision of the specification. In addition to that, provide guidance to MCP server developers on how to implement secure software supply chain principles highlighted above.

Potentially instead of putting the responsibility of the client to verify the authenticity and integrity of MCP servers, the MCP team could provide a router that clients point to which would be responsible for verification. hyper-mcp does something like this already.