5分のセキュリティチェック
AIツールの基本的なセキュリティ評価をするのに、セキュリティの専門家である必要はありません。5分間の構造的なチェックで、最もよくある問題を見つけ、情報に基づいた判断ができる程度の材料を得られます。
まずは集約プラットフォームでツールのセキュリティ評価を確認しましょう。ツールが評価済みなら、その評価が即座のシグナルとなります。AまたはBの評価は、依存関係の健全性、メンテナンス活動、コード品質に関する自動チェックを通過したことを意味します。DまたはFの評価は、重大な問題が見つかったことを意味します。
ステップ1: 依存関係を確認する
ツールをインストールした後(あるいは依存関係ファイルを確認できるなら事前)に、依存関係の監査を実行しましょう。npmパッケージならnpm auditが既知の脆弱性を確認します。Pythonパッケージならpip-auditが同じことをしてくれます。
見つかった事項の重大度に注意してください。推移的依存関係の低重大度の問題は、直接依存関係の致命的脆弱性とは別物です。特にツールが処理するデータを扱う依存関係について、致命的および高重大度の問題に注意を集中させましょう。
ステップ2: メンテナンス活動を確認する
ツールのGitHubリポジトリ(または同等のもの)を訪れて、コミット履歴を見てみましょう。最後のコミットはいつですか? Issueには返答がついていますか? 貢献者は1人以上いますか?
過去6ヶ月間にコミットがないツールは、おそらくセキュリティパッチを受け取れていません。これは今日時点で安全でないということではありませんが、もし明日脆弱性が発見されたとしても、迅速に修正される可能性は低いということです。
ステップ3: 権限を確認する
ツールのドキュメントを読んで、何の権限を要求しているかを把握しましょう。MCPサーバーのツール説明は、それがどんな操作を行えるかを教えてくれます。ツールが本来の目的に必要なものより広い権限を要求している場合、それは問うべき点です。
ファイル読み取りだけでよいはずのファイルシステムサーバーが書き込みアクセスを要求しているなら、過剰な権限です。クエリアクセスだけが必要なのにテーブル削除権限を要求するデータベースサーバーは、より制約された代替を見つけることで回避できるリスクです。
ステップ4: 作者を確認する
ツールを誰がメンテナンスしているかを見ましょう。他に評判の良いプロジェクトをメンテナンスしているでしょうか? 評判を守る理由のある組織を代表していますか? Issueやセキュリティ報告に応答していますか?
他にプロジェクトがない匿名の作者であっても、自動的に信頼できないわけではありません。しかしそれは、頼れる信頼シグナルが少ないということです。質の高いオープンソースソフトウェアをメンテナンスしてきた実績のある作者は、より大きな安心感をもたらしてくれます。
ステップ5: 影響範囲を考える
最後に、このツールが侵害されたり予期せぬ挙動を取ったりしたら何が起きるかを考えてみましょう。特定のディレクトリのファイルを読むだけのツールなら、影響範囲は限定的です。メール、データベース、クラウドインフラへのアクセスを持つツールなら、影響範囲ははるかに大きくなります。
評価の厳しさを影響範囲に合わせましょう。公開データを読むことしかできないツールは、本番データベースを変更できるツールより精査の必要が少ないものです。リスクが最も高いところに評価の労力を割り当てましょう。