ソースコードや機密情報を漏らさずに、AIでソフトウェアの脆弱性をトリアージする方法

ソフトウェアセキュリティ上の問題をAIで調査する際、リポジトリ全体や有効な認証情報を送る必要はありません。関連する動作を維持した、許可済みの最小限の例を用意し、シークレットや無関係な個人データを削除して、承認された処理環境を選び、提案を適用する前に必ず一つひとつ検証してください。

主なリスクは、APIキーをチャットに貼り付けることだけではありません。ソースファイル、ログ、添付ファイル、ツール連携、実行環境のいずれも、個人情報を漏らしたり、意図しないアクセスを生じさせたりする可能性があります。このガイドでは、何をマスキングし、どのようなコンテキストを残し、提案された修正が正しいかを判断する際にどのような証拠を保持すべきかを含む、開発者向けの再現可能なトリアージ手順を紹介します。

AIチャットに貼り付けてはいけないデータとは？

通常のモデルとの会話に、実際に有効なパスワード、秘密鍵、セッションCookie、アクセストークン、リカバリーコード、本番環境の接続文字列を貼り付けないでください。認証チェックやデータベース呼び出しの仕組みを説明するのに、これらは必要ありません。分析に必要な構造上の特徴だけを残し、明らかなダミー値に置き換えてください。

非公開コードや脆弱性の詳細にも、取り扱いの許可が必要です。リポジトリの閲覧を許可されていても、外部サービスへの送信が許可されているとは限りません。顧客のログには、バグに関係のない識別子、プライベートメッセージ、リクエストパラメーターが含まれている場合があります。スクリーンショットや添付ファイルも含め、共有する前に資料を確認してください。

OWASPのシークレット管理ガイダンスは、シークレットのライフサイクルとアクセス制御に関する有用な参考資料です。シークレットの露出は、単なる書式上のミスではなく、アクセス上の問題として扱ってください。漏えいが発生した場合は、プロンプトを編集すれば露出が解消されると考えず、組織の失効手順とインシデント対応手順に従ってください。

この記事は、自分が所有するコードまたは許可されたプロジェクトの防御的レビューを対象としています。公開リポジトリや閲覧可能なウェブサイトであることだけでは、他者が運用するシステムに対してテストを実施する許可にはなりません。最初からレビューの範囲と処理の許可を明確にしてください。

共有前にコードと脆弱性データをどのように分類すべきか？

提案するレビュー用パッケージの内容を簡潔に一覧化します。コード、設定、ログ、サンプル入力、依存関係の情報、モデルに与えるツールアクセスを含めます。ファイルのディレクトリ名だけに頼らず、内容から何が明らかになるか、誰が処理を許可されているかに基づいて分類してください。

判明していること、疑われていること、意図的に省いたことを明示してください。たとえば、エンドポイント名は架空のものだが、ロールチェックと呼び出し順序は変更していない、と説明します。これにより、モデルが伏せ字による置き換えをアプリケーション設計の一部と誤認するのを防げます。

当社のAI修正ライフサイクルの解説では、この準備をトリアージとパッチ検証より前に行います。関連するHy4分析では、開発者がモデルの安全性を主張しても、非公開コードをアップロードしてよいかどうかは決まらない理由を説明しています。データを使う権限の確認は、別途必要です。

表紙：GitHub Docsのコードスキャンアラートのスクリーンショット。CC BY 4.0に基づき、改変せずに転載；出典とコンテキスト。

ホスト型サービスではなくローカルモデルを使うべきなのはどんなときですか？

データポリシーと技術的な制約で許可された環境を使ってください。関連する取り扱い条件、保持管理、リージョン、組織内の承認がタスクに適していれば、ホスト型サービスが適している場合があります。コンテキストを管理下の環境内にとどめる必要があり、モデルが範囲を限定したレビューを十分に実行できるなら、ローカルモデルが役立つ場合があります。

どちらのラベルも、セキュリティ評価の結論にはなりません。ローカルランタイムでも、ネットワークAPIを公開したり、プロンプトをログに書き込んだり、サードパーティ製拡張機能を読み込んだり、ツールから外部サービスにアクセスできるようにしたりする場合があります。ホスト型コーディングツールは、貼り付けたテキストより多くのリポジトリコンテキストを取得することがあります。「ローカル」なら隔離されている、「エンタープライズ」ならあらゆる利用が承認されていると決めつけず、データと操作の経路全体をたどってください。

小さな実験では、サニタイズしたコード抜粋を用意し、書き込みツールは使わずに始めましょう。モデルの説明を、コードに対するメンテナーの理解と比較します。より広いコンテキストが必要な場合は、意図的に対象を広げ、その理由を記録してください。コンテキスト不足の問題を、リポジトリやファイルシステムへの無制限アクセスを一度に許可して解決しようとしてはいけません。

非公開ドキュメントのワークフローから外部に出る情報を管理するガイドでは、関連するデータ経路の観点を紹介しています。コードのトリアージでも、同じ問いが当てはまります。どのコンテンツが読み取られ、どこで処理され、何が記録され、どの連携先が結果を受け取れるのでしょうか？

有用なコンテキストを残しつつ、シークレットをマスキングするには？

機密値ではなく、関係性を残してください。認可の例では、所有者が異なる2人のユーザーが必要な場合がありますが、実名やアカウント識別子は不要です。設定上の問題を示すには、認証が有効かどうかを示す必要があるかもしれませんが、実際のパスワードや署名鍵を含める必要はありません。

パッケージ内では、一貫した架空の名前を使ってください。コード例でユーザーがtest_user_aとして登場するなら、サンプルレコードや期待される結果でも同じ名前を使い続けてください。マスキングに一貫性がないと、実際にはないバグが生じたり、レビューで調べるべき関係性が見えなくなったりするおそれがあります。

見落としやすい場所も確認してください。クエリパラメーター付きのURL、認証ヘッダー、例外メッセージ、コメント、フィクスチャファイル、ノートブックの出力、アーカイブ、スクリーンショットなどです。シークレットスキャナーは役立ちますが、ビジネス上の機密事項をすべて特定したり、独自形式のトークンが検出されると保証したりはできません。GitHubのシークレットスキャンに関するドキュメントでは、自動検出の仕組みの一つが説明されています。

サニタイズした後、次の2点を担当者に確認してもらいましょう。パッケージから不要な情報が漏れる可能性があるか、そして関連する挙動を再現できるか。アプリケーションを表さなくなったマスキング済みの例には、「不完全」と明記してください。再現が壊れている状態から、確定的なセキュリティ上の結論を導かないでください。

AIツールに必要最小限のアクセス権を付与するには？

コンテキストを読み取る権限と、システムを変更する権限を分けてください。初期トリアージでは、書き込み権限もネットワーク接続可能なシェルも必要ないことがよくあります。ツールでリポジトリを調べる必要がある場合は、専用のサニタイズ済みチェックアウトを用意するか、プラットフォームが対応していれば、対象を厳しく限定した読み取り権限を付与してください。本番環境の認証情報は、その環境の外に保管してください。

GitHubの個人用アクセストークンに関するガイダンスでは、トークンの種類と権限管理について説明しています。実際のタスクとリポジトリに合った認証情報を選び、適切な有効期限を設定し、承認済みのシークレット保管場所を利用してください。プロンプト、コマンド例、コミット、共有するレビュー添付ファイルにトークンを記載しないでください。

エージェントに非公開ディレクトリを無視するよう指示することと、それを強制することも区別しましょう。指示するだけでは、そのディレクトリを読み取る能力はなくなりません。マウントの制限、別アカウント、または隔離された実行環境を使えば、文章だけでは実現できない境界を強制できます。選んだ方法が、ツールの実際の実行権限に適合することを確認してください。

外部の資料には、タスクと矛盾する指示が含まれていることがあります。OWASPのプロンプトインジェクション解説では、取得したコンテンツがセキュリティ上の懸念となる理由を説明しています。リポジトリのコメント、課題のテキスト、ログは分析対象の証拠として扱い、エージェントがアクセスできる秘密情報やシステムの範囲を、それらによって変更させないでください。

AIの推奨事項を安全に検証するには？

合成データと既知の開始リビジョンを使った、使い捨ての環境を用意します。モデルには、提案されたセキュリティ特性と、推奨事項を裏付ける証拠の説明を求めます。設定の変更やチェックの削除を提案された場合は、セキュリティ関連の回答に含まれているというだけで受け入れず、ソフトウェアの変更として評価します。

次の準備から検証までの手順に従います。

1. リポジトリとレビュー作業が自組織の管理下にあるか、明示的な承認を得ていることを確認します。
2. 最小限の再現環境を用意し、手を加えていないソースのコピーを別に保管します。
3. 認証情報、個人情報、無関係な機密情報を削除します。
4. 承認済みのモデル環境を選び、実行可能な場合は読み取り専用の限定的なアクセスから開始します。
5. 説明をレビューし、コードの参照先と前提を独立して確認します。
6. 候補となるパッチは、隔離されたテスト環境でのみ適用します。
7. 禁止されている動作と、引き続き可能でなければならない正当な動作の両方をテストします。
8. 判断、必要な修正、統合を承認できる担当者を記録します。

テストを現実的に見せるために、本番データをモデルに渡してはなりません。重要なのは、入力、制御、結果の関係です。合成フィクスチャを使えば、実際の顧客の記録を公開せずに、所有権、ロールの違い、欠損値を再現できます。

次の受け入れ手順については、agentic-autofixレビュガイドをご覧ください。再現もレビューもできない推奨事項は、未解決のままにしてください。元のアラートが緊急に思えたというだけで、本番環境向けの修正として黙って採用してはなりません。

監査とインシデント対応のために、チームは何を記録すべきですか？

不要な秘密情報を保持せずに、判断を理解するのに十分な証拠を残します。有用な項目には、検出事項の識別子、ソースのリビジョン、処理環境、サニタイズ済みのコンテキストの説明、入手可能な場合はモデルまたはサービスのバージョン、推奨事項、テスト、レビュー担当者、最終判断が含まれます。機密性の高い脆弱性の記録は、適切なアクセス制御が設定された承認済みの場所に保管します。

モデルが確認できなかった内容を記録します。ヘルパー関数1つだけに基づく分析と、その呼び出し元や設定も確認したレビューでは、対象範囲が異なります。結果が前提に依存する場合は、その前提を判断記録に残します。そうしないと、後から読む人が、限定的な結論をアプリケーション全体に対する保証と誤解するおそれがあります。

実用的な完了チェックリストは次のとおりです。

• コンテキストパッケージに、有効な認証情報や無関係な個人情報は含まれていません。
• 処理環境と連携機能は、この資料の取り扱いについて承認されています。
• 推奨事項は、架空の参照情報に頼らず、証拠を示している。
• パッチの範囲が絞られ、レビューされ、意味のあるテストに結び付けられている。
• 未解決の制約と運用上のフォローアップに担当者が割り当てられている。
• 一時的な権限と保持された成果物について、明確な削除または保持ポリシーが定められている。

シークレットを誤って開示した場合は、秘密情報を含まないインシデント記録を残し、適切な対応手順に従ってください。影響を受けた認証情報と露出経路は、承認済みの社内チャネルを通じて特定し、失効またはローテーションを行い、関連するアクティビティを確認してください。機密情報かどうかを尋ねるために、そのシークレットを別のAIチャットにコピーしないでください。

最終記録には、検出事項が検証済み、却下、または未解決のいずれであるかを明記してください。「AIがレビュー済み」だけでは、意味のあるステータスとは言えません。ステータスには、エンジニアリング上の判断と、その判断に責任を持つ人が根拠とした証拠を記載する必要があります。

追加のツールを接続する前に、パーソナルエージェントの権限チェックリストを確認してください。コンテキストウィンドウが大きくなったからといって、ファイルシステムやアカウントへのアクセス範囲を広げる理由にはなりません。

よくある質問

APIキーをアスタリスクに置き換えるだけで十分ですか？

必ずしもそうとは限りません。他のファイル、ログ、URL、スクリーンショット、会話履歴にも機密情報が含まれている可能性があります。レビュー用パッケージ全体と、ツールが自動取得するコンテキストを確認してください。

ローカルモデルから情報が漏れることはありますか？

ローカルモデルであっても、プロンプトを記録したり、エンドポイントを公開したり、ツール経由でデータを送信したりするシステムの一部である可能性があります。推論場所だけに頼らず、実行環境、連携機能、権限を確認してください。

マスキングによって、問題の理解に必要な詳細まで失われる場合はどうすればよいですか？

関連する関係性を保った合成例を作るか、必要なコンテキストを扱える承認済み環境にレビューを移してください。不確かな点が残る場合は、その旨を明記します。

シークレットスキャンをすれば、パッケージを安全に共有できると証明できますか？

いいえ。検出範囲には限界があり、業務上機密性の高い情報が必ずしも認証情報とは限りません。自動スキャンは、状況や権限のレビューを補完するものであるべきです。

AIが自分でセキュリティパッチをマージできるようにすべきですか？

初期のワークフローでは、連携は人によるレビューとリポジトリの管理下に置いてください。それ以降の自動化には、明示的な承認、意味のあるテスト、明確に定義された範囲が必要です。

結論

安全なAIによる脆弱性トリアージは、必要最小限の承認済み証拠一式から始まり、文書化されたエンジニアリング上の判断で終わります。秘密情報を保護するには、目に見えるプロンプトだけでなく、ファイル、ツール、ログ、権限にも注意を払う必要があります。

可能であれば合成データを使い、推奨事項は隔離環境で検証し、レビューとデプロイの権限は分けてください。そうすれば、限定的なセキュリティ上の疑問を不必要なアクセスや情報開示につなげることなく、AIを調査の補助に活用できます。