Claude CodeがMarketplaceの組織単位ワイルドカード制御を追加——1つのルールでGitHub組織全体を許可・ブロック可能に

オーナーワイルドカードというマッチング方式は、従来の個別にリポジトリ名を列挙する方法と比べて、セキュリティ上実質的な違いがあるのか？

この機能が変えるのは「維持コスト」であり、「個々のルールそのもののセキュリティ強度」ではない。リポジトリを個別に列挙する方法は、ルール自体の精度という点では実はより高い——それぞれのルールが明確で具体的な1つのリポジトリに対応しているからである。一方オーナーワイルドカードは、個々のリポジトリに対する信頼判断を、組織というより大きな信頼単位に置き換えるものである。その組織配下のどのリポジトリであれ、内容に問題が生じた場合（侵害された、あるいは協力者の権限が悪用されたなど）、ワイルドカードルールはその問題を、すでに許可されている範囲内に自動的に含めてしまい、追加でブロックされることはない。

これは、オーナーワイルドカードの利用が、実質的に信頼のレベルを「リポジトリ」から「組織」へと引き上げることを意味し、セキュリティが十分かどうかは、その組織自身のアクセス制御とガバナンスがどれだけ厳格であるかにかかっている。だからこそ、この機能は自分の組織内部で確実に管理できる状況に最も適しており、外部の第三者組織に対してワイルドカードで許可を選ぶ場合、リスク判断の粒度を粗くすることになり、その組織全体に対する相応の信頼の基盤がなければ合理的とは言えない。

なぜ今回SHA-256による完全性検証まで一緒に追加されたのか、これはオーナーワイルドカードと同じ文脈にある機能なのか？

この2つの機能は異なる層の問題を解決するものだが、確かに同じ文脈の中で理解することができる。オーナーワイルドカードが扱うのは「どのソースを信頼できるか」であり、SHA-256検証が扱うのは「たとえソースが信頼されていても、実際にダウンロードされた内容が転送過程で改ざんされていないか」である。この2つが揃って初めて、比較的完全なサプライチェーン信頼の仕組みが構成される。ある組織を信頼しているというだけでは、その組織が公開するすべてのファイルが転送過程で改ざんされないことは保証されない（中間者攻撃や、配布用サーバー自体が侵害されるケースなど）。逆に、ファイルのハッシュ値を検証するだけでも、そもそも信頼できないソースからダウンロードしていれば意味がない。検証しているのは「これは攻撃者が本来渡そうとしていたそのファイルである」ということだけである。

この2つの機能を同じ一連の更新にまとめたことは、ある程度、Pluginエコシステムの規模拡大に伴い、Anthropicが「ソースのガバナンス」と「コンテンツの完全性」という2つの角度から同時にサプライチェーンセキュリティを強化していることを反映している。これは、最近のサードパーティ製Skillのアップロードスキャンや、GitHub repoのSkill信頼境界をめぐる一連の動きと、方向性として一致している。

もし自分の組織がすでにstrictKnownMarketplacesの許可リストを設定しており、その後もともと許可されていたリポジトリがハッキングされた場合、このルールは自動的にブロックしてくれるのか？

いいえ、ブロックしません。strictKnownMarketplacesがチェックしているのは「このmarketplaceソース自体が許可リストに含まれているかどうか」であり、これはソースレベルの静的な照合であって、コンテンツレベルの継続的な監視ではない。つまり、リポジトリの所在地（例えば acme-corp/approved-plugins）が変わらない限り、たとえ中身が攻撃者によって改ざんされたとしても、このルールは依然として「これは許可されたソースだ」と判断して通してしまう。ルールが照合しているのは「これは自分が認識しているアドレスかどうか」であって、「このアドレスに現在置かれているものが今も安全かどうか」ではないからである。

まさにこの部分を補うのがSHA-256による完全性検証である。marketplace内の個々のPluginエントリにsha256フィールドが設定されていれば、たとえソース自体が信頼されていても、実際にダウンロードされたファイルのハッシュ値が事前に設定された値と一致しない限り、インストールは拒否される。ただしこれはarchiveソース経由のPluginにしか適用されない。git系のソース（github、url、git-subdir）経由のPluginには現時点で同様のハッシュ照合の仕組みはなく、それに近い保護策としては、shaフィールドで特定のコミットを固定し、知らないうちに別のバージョンに差し替えられることを防ぐ方法があるが、これも当初固定したそのコミットがクリーンであったという前提に依然として立っている。

もし自分が組織のためにPlugin marketplaceのガバナンスポリシーを設計するとしたら、この2つの機能を実際にどう組み合わせて使うべきか？

より堅実な方法は、この2つの機能を異なる層に分担させることである。オーナーワイルドカードは「組織範囲での粗い粒度の信頼判断」に使う——例えば自社のGitHub組織（your-org/*）を許可したり、既知の問題がある外部組織をブロックしたりするのに用いる。個々の重要なPlugin（特により高い権限に関わるものや、広く導入されるもの）については、さらに公開者にSHA-256ハッシュ値の提供を求めるか、git系ソースを経由させたうえで明確なコミットshaを固定するよう求め、「ソースが信頼できるかどうか」とは独立したコンテンツの完全性の保護層を持たせるとよい。

実務上見落とされがちな細部もある。オーナーワイルドカードは完全一致によるマッチングであり、acme-corp/* はそのオーナー配下のリポジトリのみをカバーし、名前が似ているが別のオーナーに属するリポジトリを誤ってカバーすることはない。また、strictKnownMarketplacesはmarketplaceの追加時、そしてインストール・更新・リフレッシュ・自動更新のたびにチェックされる。あるmarketplaceがポリシー設定より前にすでに追加されており、そのソースが許可リストに一致しなくなった場合、ルールが発効すると、そのソースからの以降のインストールや更新は単純に拒否される。これは、ポリシー変更後には、現在インストール済みのmarketplaceリストを能動的に棚卸しし、必要なソースが意図せずブロックされていないか確認する価値があることを意味する。