-
Notifications
You must be signed in to change notification settings - Fork 51
Add MCP (Model Context Protocol) security rule #97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
13afd84
Add MCP (Model Context Protocol) security rule
santosomar 457fdf8
Update sources/core/codeguard-0-mcp-security.md
santosomar dcd21e4
Add better concistency to the MCP rule
thomas-bartlett 2c7150f
chore: enhancing mcp rule
c841c14
chore: updating skills with latest mcp changes
d3a5012
chore: bump version to 1.2.0 in project files
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
102 changes: 102 additions & 0 deletions
102
skills/software-security/rules/codeguard-0-mcp-security.md
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,102 @@ | ||
| --- | ||
| description: MCP (Model Context Protocol) Security based on CoSAI MCP Security guidelines | ||
| languages: | ||
| - python | ||
| - javascript | ||
| - typescript | ||
| - go | ||
| - rust | ||
| - java | ||
| alwaysApply: false | ||
| --- | ||
|
|
||
| rule_id: codeguard-0-mcp-security | ||
|
|
||
| # MCP (Model Context Protocol) Security Guidelines | ||
|
|
||
| NEVER deploy MCP servers or clients without implementing proper security controls. | ||
|
|
||
| ### Workload Identity and Authentication | ||
| - Use SPIFFE/SPIRE for cryptographic workload identities | ||
| - SPIFFE (Secure Production Identity Framework For Everyone) provides a standard for service identity | ||
| - SPIRE (SPIFFE Runtime Environment) issues and rotates short-lived cryptographic identities (SVIDs) | ||
|
|
||
| ### Input and Data Sanitization | ||
| - Validate ALL inputs using allowlists at every trust boundary | ||
| - Sanitize file paths through canonicalization | ||
| - Use parameterized queries for database operations | ||
| - Apply context-aware output encoding (SQL, shell, HTML) | ||
| - Sanitize tool outputs: return only minimum fields, redact all PII and sensitive data | ||
| - Treat ALL inputs, tool schemas, metadata, prompts, and resource content as untrusted input | ||
| - Deploy prompt injection detection systems | ||
| - Use strict JSON schemas to maintain boundaries between instructions and data | ||
|
|
||
| ### Sandboxing and Isolation | ||
| - Design MCP servers to execute with least privilege | ||
| - MCP servers interacting with host environment (files, commands, network) MUST implement sandboxing controls | ||
| - LLM-generated code MUST NOT run with full user privileges | ||
| - Implement additional sandboxing layers: gVisor, Kata Containers, SELinux sandboxes | ||
|
|
||
| ### Cryptographic Verification of Resources | ||
| - Provide cryptographic signatures and SBOMs for all server code | ||
| - Implement signature verification in your MCP client before loading servers | ||
| - Use TLS for ALL data in transit | ||
| - Implement remote attestation capabilities to verify servers are running expected code | ||
|
|
||
| ### Transport Layer Security | ||
|
|
||
| #### stdio Transport (Local Servers) | ||
| - STRONGLY RECOMMENDED for local MCP to eliminate DNS rebinding risks | ||
| - Direct pipe-based stream communication | ||
| - Implement sandbox to prevent privilege escalation | ||
|
|
||
| #### HTTP Streaming Transport (Remote Servers) | ||
| Required security controls to implement: | ||
| - Payload Limits (prevent large payload and recursive payload DoS) | ||
| - Rate limiting for tool calls and transport requests | ||
| - Client-Server Authentication/Authorization | ||
| - Mutual TLS Authentication | ||
| - TLS Encryption | ||
| - CORS Protection | ||
| - CSRF Protection | ||
| - Integrity Checks (prevent replay, spoofing, poisoned responses) | ||
|
|
||
| ### Secure Tool and UX Design | ||
| - Create single-purpose tools with explicit boundaries; avoid "do anything" tools | ||
| - Do not rely on the LLM for validation or authorization decisions | ||
| - Use two-stage commit for high-impact actions: draft/preview first, explicit commit with confirmation second | ||
| - Provide rollback/undo paths (draft IDs, snapshots, reversible actions) and time-bound commits when possible | ||
|
|
||
| ### Human-in-the-Loop | ||
| - Implement confirmation prompts for risky operations in your MCP server | ||
| - Use elicitation on MCP server side to request user confirmation of risky actions | ||
| - Security-relevant messages MUST clearly indicate implications | ||
| - Do NOT rely solely on human approval (users can become fatigued) | ||
|
|
||
| ### Logging and Observability | ||
| - Implement logging in your MCP servers and clients | ||
| - Log: tools that were used, parameters, originating prompt | ||
| - Use OpenTelemetry for end-to-end linkability of actions | ||
| - Maintain immutable records of actions and authorizations | ||
|
|
||
| --- | ||
|
|
||
| ## Deployment Pattern Security | ||
|
|
||
| ### All-Local (stdio or http) | ||
| - Security depends entirely on host system posture | ||
| - Use `stdio` transport to avoid DNS rebinding risks | ||
| - Use sandboxing to limit privilege escalation attacks | ||
| - Appropriate for development and personal use | ||
|
|
||
| ### Single-Tenant Remote (http) | ||
| - Authentication between client and server is REQUIRED | ||
| - Use secure credential storage (OS keychains, secret managers) | ||
| - Communication MUST be authenticated and encrypted | ||
| - Enterprise clients should enforce authenticated server discovery with explicit allowlists | ||
|
|
||
| ### Multi-Tenant Remote (http) | ||
| - Require robust tenant isolation, identity, and access control | ||
| - Implement strong multi-tenancy controls (per-tenant encryption, role-based access control) | ||
| - Prefer MCP servers hosted directly by service provider | ||
| - Provide remote attestation when possible |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
| --- | ||
| description: MCP (Model Context Protocol) Security based on CoSAI MCP Security guidelines | ||
| languages: | ||
| - python | ||
| - javascript | ||
| - typescript | ||
| - go | ||
| - rust | ||
| - java | ||
| alwaysApply: false | ||
| --- | ||
|
|
||
| # MCP (Model Context Protocol) Security Guidelines | ||
|
|
||
| NEVER deploy MCP servers or clients without implementing proper security controls. | ||
|
|
||
| ### Workload Identity and Authentication | ||
| - Use SPIFFE/SPIRE for cryptographic workload identities | ||
| - SPIFFE (Secure Production Identity Framework For Everyone) provides a standard for service identity | ||
| - SPIRE (SPIFFE Runtime Environment) issues and rotates short-lived cryptographic identities (SVIDs) | ||
|
|
||
| ### Input and Data Sanitization | ||
| - Validate ALL inputs using allowlists at every trust boundary | ||
| - Sanitize file paths through canonicalization | ||
| - Use parameterized queries for database operations | ||
| - Apply context-aware output encoding (SQL, shell, HTML) | ||
| - Sanitize tool outputs: return only minimum fields, redact all PII and sensitive data | ||
| - Treat ALL inputs, tool schemas, metadata, prompts, and resource content as untrusted input | ||
| - Deploy prompt injection detection systems | ||
| - Use strict JSON schemas to maintain boundaries between instructions and data | ||
|
|
||
| ### Sandboxing and Isolation | ||
| - Design MCP servers to execute with least privilege | ||
| - MCP servers interacting with host environment (files, commands, network) MUST implement sandboxing controls | ||
| - LLM-generated code MUST NOT run with full user privileges | ||
| - Implement additional sandboxing layers: gVisor, Kata Containers, SELinux sandboxes | ||
|
|
||
| ### Cryptographic Verification of Resources | ||
| - Provide cryptographic signatures and SBOMs for all server code | ||
| - Implement signature verification in your MCP client before loading servers | ||
| - Use TLS for ALL data in transit | ||
| - Implement remote attestation capabilities to verify servers are running expected code | ||
|
|
||
| ### Transport Layer Security | ||
|
|
||
| #### stdio Transport (Local Servers) | ||
| - STRONGLY RECOMMENDED for local MCP to eliminate DNS rebinding risks | ||
| - Direct pipe-based stream communication | ||
| - Implement sandbox to prevent privilege escalation | ||
|
|
||
| #### HTTP Streaming Transport (Remote Servers) | ||
| Required security controls to implement: | ||
| - Payload Limits (prevent large payload and recursive payload DoS) | ||
| - Rate limiting for tool calls and transport requests | ||
| - Client-Server Authentication/Authorization | ||
| - Mutual TLS Authentication | ||
| - TLS Encryption | ||
| - CORS Protection | ||
| - CSRF Protection | ||
| - Integrity Checks (prevent replay, spoofing, poisoned responses) | ||
|
|
||
| ### Secure Tool and UX Design | ||
| - Create single-purpose tools with explicit boundaries; avoid "do anything" tools | ||
| - Do not rely on the LLM for validation or authorization decisions | ||
| - Use two-stage commit for high-impact actions: draft/preview first, explicit commit with confirmation second | ||
| - Provide rollback/undo paths (draft IDs, snapshots, reversible actions) and time-bound commits when possible | ||
|
|
||
| ### Human-in-the-Loop | ||
| - Implement confirmation prompts for risky operations in your MCP server | ||
| - Use elicitation on MCP server side to request user confirmation of risky actions | ||
| - Security-relevant messages MUST clearly indicate implications | ||
| - Do NOT rely solely on human approval (users can become fatigued) | ||
|
|
||
| ### Logging and Observability | ||
| - Implement logging in your MCP servers and clients | ||
| - Log: tools that were used, parameters, originating prompt | ||
| - Use OpenTelemetry for end-to-end linkability of actions | ||
| - Maintain immutable records of actions and authorizations | ||
|
|
||
| --- | ||
|
|
||
| ## Deployment Pattern Security | ||
|
|
||
| ### All-Local (stdio or http) | ||
| - Security depends entirely on host system posture | ||
| - Use `stdio` transport to avoid DNS rebinding risks | ||
| - Use sandboxing to limit privilege escalation attacks | ||
| - Appropriate for development and personal use | ||
|
|
||
| ### Single-Tenant Remote (http) | ||
| - Authentication between client and server is REQUIRED | ||
| - Use secure credential storage (OS keychains, secret managers) | ||
| - Communication MUST be authenticated and encrypted | ||
| - Enterprise clients should enforce authenticated server discovery with explicit allowlists | ||
|
|
||
| ### Multi-Tenant Remote (http) | ||
| - Require robust tenant isolation, identity, and access control | ||
| - Implement strong multi-tenancy controls (per-tenant encryption, role-based access control) | ||
| - Prefer MCP servers hosted directly by service provider | ||
| - Provide remote attestation when possible | ||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.