MCP package供給経路: lock、artifact、provenanceを別々に確認
同じpackage名や正しいprovenanceでも、実行artifact、依存tree、build内容が同じとは限りません。MCP接続前にversion、digest、発行identity、変更差分を別々に確認する受入条件です。
Read in Englishpackage managerから起動するMCP serverは、設定ファイルに同じpackage名が残っていても、同じcodeを実行し続けるとは限りません。version range、配布artifact、transitive dependency、registry、build workflowのどれかが変われば、端末上で動く権限主体も変わります。lock、artifact digest、provenanceはそれぞれ別の問いに答える証拠であり、どれか1つで供給経路全体の安全を保証するものではありません。
4種類の証拠と限界
| 証拠 | 確認できること | 単独では確認できないこと |
|---|---|---|
| exact version / lock | 解決されたdirect・transitive dependency | 配布artifactが承認済みbuildと同一か |
| artifact digest | 取得したbytesが記録値と一致 | そのbytesが安全なcodeか |
| provenance / attestation | source、workflow、publisher identityとの結び付き | sourceやbuild手順に悪意・脆弱性がないこと |
| sourceとrelease差分のreview | 意図した変更と権限差 | 実際に展開されたbytesとの一致 |
npmは、lockfileがpackage.jsonのrangeを満たす場合にはexact versionを使うと説明しています。ただし、MCP clientの起動設定が毎回registryからmoving tagやversion rangeを直接解決する場合、別projectのlockfileはその起動を固定しません。たとえば承認時に@example/search-mcp 1.4.2を確認していても、^1.4を再解決すれば1.4.3が選ばれる可能性があります。名前が同じでも、受入れたartifactは別物です。
Python packageでも、version pinと配布fileのidentityは別です。versionを固定すると解決範囲は狭まりますが、hashは許可したdistribution fileを固定します。同じreleaseでもplatform別wheelがあれば、2台の端末が異なるfileを取得し得るため、versionだけでなく配布file名とdigestを受入れ記録に含めます。
provenanceが証明するidentity
npm provenanceは、packageをsource codeとbuild instructionsへ結び付けます。PyPI attestationは、release fileが特定のTrusted Publisher identityから公開されたことを示します。GitHub artifact attestationもrepository、workflow、commitなどとの結び付きを検証可能にします。
これらは改ざん検知とpublisher変更の発見に役立ちますが、発行identityの所有者が安全な変更だけを入れたことまでは証明しません。npm、PyPI、GitHubはいずれも、attestationの存在をartifactの安全保証として扱わないよう明記しています。検証に成功した新releaseでも、依存追加、install script、network destination、file access、tool authorityの差分reviewが残ります。
MCP接続前の受入条件
MCPの現行Security Best Practicesは、local serverがclientと同じ端末でbinaryとして実行され、filesystem、credential、networkへ到達し得る境界を示しています。MCP仕様自体は、特定package managerのlockfileやprovenance書式を必須にしていません。次はMCP Guardの実務推奨です。
- package registry、package名、exact version、配布file名、artifact digestの固定
- direct・transitive dependencyを含むlockまたはhash付き解決記録
- provenanceのsource repository、workflow、commit、publisher identityの検証
- 前回承認artifactからのdependency、install hook、権限、外部接続の変更差分
- test環境で確認したartifact digestと、本番起動時に取得したartifact digestの一致
同じsource identityの正しいprovenanceがあっても、digestや変更差分が未確認なら自動承認しません。moving tag、無制限のversion range、起動時の毎回再解決しかない構成は、artifactを固定できる実行環境へ変更するまで接続を見送ります。変更後は、旧判定を新artifactへ転用せず、変更範囲に応じて再確認します。
確認範囲と出典
2026年9月22日に、MCP 2026-07-28 Security Best Practices、npm provenance、PyPI attestation、GitHub artifact attestationの公開資料を確認した設計分析です。特定packageの改ざん、malware、CVE、またはMCP Guardによる個別artifact検査を報告するものではありません。表と受入条件は一次資料の限界から導いたMCP Guardの実務推奨です。