利益:
- 人工知能を第二の目として使用し、コンテキストを与えることでコード内の OWASP クラスの脆弱性 (インジェクション、ハード シークレット、アクセス制御) にフラグを立てる機能
- コンテキストに基づいて人工知能によって生成された誤検知を排除し、各発見結果を検証せずに実際の脆弱性として扱うことを防ぐ機能
- 人工知能によって提案された修正によって新しい脆弱性やバグが導入される可能性があることを認識し、各パッチをレビューおよびテストのゲートに通過させる能力
ソフトウェア内の脆弱性は、最初から製品に組み込まれ、何百万ものユーザーに配布されるため、最も高価な脆弱性の 1 つです。安全なコード レビューは、ソース コードを 1 行ずつ読み取り、本番環境に入る前に脆弱性 (SQL インジェクション、認証の脆弱性、ハードコードされたパスワード、不正な認証) を検出するプロセスです。手作業で行うと時間がかかり、疲れます。大規模なコードベースの脆弱性は見落とされがちです。
AI がコード レビューに強力な理由は 2 つあります。コードも言語であることと、AI がパターン認識に優れていることです。 AI は、コード内の危険なパターン (クエリへのユーザー入力の直接入力、暗号化されていないデータ ストレージ、入力検証の欠如など) に迅速にフラグを立て、それぞれが危険である理由を説明し、修正を提案します。しかし、AI はコードの動作コンテキスト全体を認識しているわけではなく (入力が別のレイヤーでクリアされている可能性があります)、存在しない脆弱性をでっち上げたり (偽陽性)、実際の脆弱性を見落としたり (偽陰性) する可能性があり、最も重要なことに、AI が提案する「修正」によって新しい脆弱性やバグが導入される可能性があります。 AI はコードレビューにおける第二の目であり指針です。開発者とセキュリティの専門家は、発見されたものが実際の脆弱性であるかどうか、また修正が正しく安全であるかどうかを判断します。
コードレビューの手順
- 範囲とコンテキストを与えます。どの言語、どのフレームワーク、このコードはどこで入力を受け取り、どこで出力を行い、どの層で機能しますか?コンテキストのないコードレビューでは誤検知が発生します。
- 危険なパターンをスキャンします。既知の AI 脆弱性クラス (OWASP Top 10 など) を検索します: インジェクション、認証、機密データの開示、アクセス制御。
- それぞれの発見を正当化してください。各フラグについて、どの行、どの脆弱性クラス、どのように悪用される可能性があるか、証拠は何か。不当な発見は真剣に受け止められません。
- 誤検知を排除します。入力は実際にクリアされているのか、そのパスは本当にアクセス可能なのか、コンテキストを確認してください。
- 修正を確認します。 AI が推奨するパッチが実際に脆弱性を解消し、新たな脆弱性やバグが導入されておらず、テストに合格していることを確認します。
- 人間の承認。開発者とセキュリティの専門家が発見と修正をレビューします。これがコード リポジトリに入る方法です。
用語: SAST (静的アプリケーション セキュリティ テスト — ソース コードを実行せずに分析する静的セキュリティ テスト)。 DAST (動的 - 実行中のアプリケーションを外部でテストする動的テスト)。 OWASP Top 10 は、最も一般的な Web アプリケーションの脆弱性の標準リストです。インジェクションは、ユーザー入力をコマンド/クエリとして解釈することによって引き起こされる脆弱性です (SQL インジェクションなど)。パラメーター化されたクエリは、コードから入力を分離することでインジェクションを防ぐ正しい方法です。
一般的な脆弱性クラスの表
脆弱性クラス
症状 (コード内)
正しい解決策
AIの罠
SQLインジェクション
入力をクエリに結合する
パラメータ化されたクエリ
サニタイズを無視できる
ハードコードされた秘密
パスワード/コードのキー入力
秘密の金庫 (金庫)、環境
偽陽性 (サンプル/テスト)
弱い認証
欠落または不正なコントロール
強力な集中管理
コンテキストを見逃しています
アクセス制御の欠陥
認可チェックなし
サーバー側の認証
複雑な流れが分からない
機密データの開示
パスワード不要のストレージ/ロギング
暗号化、マスキング
臨界度が分からない
安全でないシリアル化
信頼性の低いデータを逆シリアル化する
安全な解析
レアパターンを逃す
ミニケース3個
ケース 1 — 実際の噴射をキャッチする。開発者はAIにデータアクセス機能を検査させます。 AI は、ユーザーからの userId 値が SQL テキストに直接連結される行をマークし、「これは古典的な SQL インジェクションです。パラメータ化されたクエリに変換します」と指示します。サンプル補正を提供します。開発者は、入力が他の場所でサニタイズされていないことを確認し、それが実際の脆弱性であることを検証し、提案されたパラメータ化されたクエリを実装して、テストを作成します。 AI は脆弱性を強調しました。検証と修正テストは開発者によって行われました。
ケース 2 — 誤検知の固定シークレット。 AI はファイル内のpassword = "test1234" 行を見て、「重大: ハードコードされたパスワード」と表示します。開発者はコンテキストをチェックします。これは単体テスト ファイル、ダミー テスト データであり、運用環境にリリースされておらず、実際のシステムにも移植されていません。この結果は偽陽性です。開発者はこれを文書化しましたが、実際の機密ではないため、行動を起こしませんでした。教訓: AI の「絶対的な秘密」の兆候は文脈によって排除する必要があります。すべての文字列が秘密であるわけではありません。
ケース 3 — 新しい脆弱性の修正。 AI は XSS (クロスサイト スクリプティング) の脆弱性の修正を提案します。しかし、彼が提案するコードは、間違った場所の入力をクリアし、別の領域での出力エンコードをスキップします。その結果、ギャップは完全には縮まりません。セキュリティ専門家は修正をレビューし、コーディングの欠落に気づき、正しい層で修正します。教訓: AI が推奨するパッチは自動的に安全になるわけではありません。すべての修正はレビューされ、テストされます。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
このコードに抜け穴があるので修正してください: [コード]
このプロンプトはコンテキスト (言語、フレームワーク、入力ソース) を提供せず、正当化を求めず、誤検知についても質問せず、AI によって生成された修正を盲目的に受け入れる可能性があります。 AI には、実際の脆弱性と存在しない脆弱性の両方の兆候が混在していました。
強力なプロンプト:
あなたの役割: 安全なコードレビューにおいて開発者の第二の目となるアシスタント。意思決定。修正を直接適用することを検討してください。コード: [言語/フレームワークを指定]。コンテキスト: この関数 [入力ソース: 例: [外部HTTPリクエスト]を受信し、[出力先]に書き込みます。あなたのタスク: (1) OWASP クラスで可能性のある脆弱性にフラグを立て、行番号 + リスクがある理由 + 悪用方法 + それぞれの証拠を与える、(2) 検出結果ごとに少なくとも 1 つの誤検知シナリオを書きます (入力が別のレイヤーでサニタイズされている場合など)、(3) 「[レビュー + テストの書き込み]」記号を付けて修正を提案します。また、修正によって新しい脆弱性やバグが導入されているかどうかも評価します。偽の脆弱性を追加します。[コード]
強力なプロンプトによりコンテキストが提供され、OWASP クラスと証拠が求められ、誤検知と修復のリスクが質問され、人間によるレビューが強制されます。
コピー可能なプロンプトテンプレート
脆弱性スキャン テンプレート OWASP トップ 10 の [言語/フレームワーク] コードを調べます。考えられる各結果について: 行番号、脆弱性クラス、危険性の理由、エクスプロイトのサンプル、証拠の強度 (確実/可能性/弱い)。コンテキスト: 入力 [ソース]、出力 [ターゲット]。捏造された調査結果を追加する。よくわからない場合は、「[検証が必要]」と入力してください。コード: [貼り付け]
誤検知の除去パターン 次のコードの検出について、実際の脆弱性が存在しないシナリオをリストします。入力は別のレイヤーでクリアできるか、このパスはアクセス可能か、この値はテスト/サンプルか、フレームワークは自動的に保護されているか。それぞれの確認方法を書きます。検索結果: [貼り付け]
修正評価テンプレート次の脆弱性に対する修正を推奨します。次に、独自の修正を批判します: (1) 本当に脆弱性を解決するのか、(2) 新しい脆弱性/バグを導入するのか、(3) どのようなテストを作成する必要があるか (肯定的な場合と否定的な場合)、(4) パフォーマンス/機能への影響。修正を確認してテストします。脆弱性 + コード: [貼り付け]
脆弱性クラスの安全なパターン指導テンプレート [例: SQL インジェクション] は、この言語/フレームワークにおける安全な型付けパターンと一般的な誤ったパターンを比較して示しています。一般規則 + コード例を示します。ただし、コードに実装する前にコンテキストを尋ねてください。言語/フレームワーク: [書く]
よくある間違い
- 文脈なしでレビューします。言語、フレームワーク、入出力コンテキストがないと、AI は実際の結果と偽の結果の両方を混乱させます。必ずコンテキストを提供してください。
- あらゆる兆候を本当の弱さだと勘違いしてしまう。 AI は誤検知 (テスト データ、別のレイヤーでクリーンアップされた入力) を生成します。それぞれの結果をコンテキストに基づいて選別します。
- AIの補正を闇雲に適用する。推奨されるパッチにより、新たな脆弱性やバグが発生する可能性があります。テストをレビューして作成します。
- 偽陰性を信頼する。 AI が「脆弱性なし」と言っていたとしても、クリティカル パスは自分で調べてください。静的スキャンではすべての脆弱性が検出されるわけではありません。
- 外部ツールにコード/シークレットを与える。プライベート コードと実際の秘密 (キー、パスワード) は知的財産であり、脆弱性です。匿名化するか、企業の独立したツールを使用します。
ヒント: AI にコードをレビューさせる場合、最も効率的なフィルターは、各結果の「証拠の強さ」(確実/可能性/弱い) を尋ねることです。 「弱い」とマークされた検出結果のほとんどは偽陽性です。あなたは自分のエネルギーを「確かな」ものに割り当てます。
注意: AI が提案したセキュリティ修正は、テストせずに倉庫に入れないでください。不適切な「修正」は、脆弱性を残したままにし、運用環境で機能エラーを引き起こす可能性があります。すべてのパッチはレビューとテストのゲートを通過します。
要約すれば
安全なコード レビューは、本番環境に入る前に脆弱性を発見する最も安価な方法です。コードは言語であるため、ここでは AI が強力な第 2 の目となり、危険なパターンにフラグを立て、リスクを説明し、修正を提案します。しかし、AI は動作コンテキスト全体を認識しているわけではなく、誤検知や誤検知が発生し、推奨するパッチによって新たな脆弱性が導入される可能性があります。したがって、レビューには 6 つのステップ (コンテキスト、スクリーニング、正当化、誤検知の除去、修正の検証、人間による承認) があり、決定は開発者とセキュリティの専門家にあります。 3 つの原則: コンテキストなしで解釈される検出結果はありません。すべての兆候はコンテキストとともに削除されます。テストされずに保存される修正はありません。また、コード/シークレットは匿名化されずに外部ツールに提供されることはありません。
アプリケーションタスク
サンプル コード スニペットを取得します (独自のコードから機密部分を削除するか、脆弱性のあるサンプル コードから削除します)。 「脆弱性スキャン」テンプレートを使用して AI に検査させます。各検出結果に「誤検知の除去」テンプレートを適用し、実際の検出結果を除去します。 「修復評価」テンプレートを使用して最も重大な発見を修正し、自分でレビューして、肯定的なテスト ケースを 1 つと否定的なテスト ケースを 1 つ作成します。偽陽性の検出結果が何件あるかに注目してください。
チェックリスト
- [ ] コードをレビューする前に、言語、フレームワーク、および入出力コンテキストを指定しました。
- [ ] 私は、行番号、脆弱性クラス、エクスプロイト パス、および各発見事項の証拠を尋ねました。
- [ ] コンテキストを使用して、各検出結果の誤検出をスクリーニングしました。
- [ ] AI の補正をやみくもに適用したわけではありません。見直してテストを書きました。
- [ ] 「脆弱性なし」という出力にもかかわらず、私はクリティカル パスを自分で調べました。
- [ ] コード/シークレットを匿名化するか、企業内で分離されたツールを使用しました。
- [ ] 開発者とセキュリティの承認を通じて検出と修正を完了しました。