Using LLMs to secure source code｜LLM を活用したソースコードのセキュリティ強化

モデルの能力は急速に、かつ不均一に進化しています。私たちはセキュリティチームと協力し、彼ら自身のコードやオープンソースソフトウェアにおける脆弱性の発見と修正に取り組んできましたが、その経験から、モデルを使ってソースコードを保護する方法についてより深い理解を得ることができました。**私たちの主な結論：脆弱性の発見は現在容易に並列処理が可能であり、ボトルネックは検証、選別、およびパッチ適用へと移行しています**。 この乖離を示す一例として、オープンソースソフトウェアに対する[独自のスキャン](https://www.anthropic.com/research/glasswing-initial-update)の一環として、2026 年 5 月 22 日時点で 1,596 の脆弱性を開示しました。そのうち 97 がパッチ適用済みであることが確認されています（私どもの知る限り）。 このガイドでは、Claude Opus を活用して脅威モデルを構築し、コードベース内の脆弱性を発見した上で、それらを検証・選別・パッチ適用する方法について解説します。すべての答えを持っているわけではありませんが、チームがいかにして発見プロセスをスケールさせたか、そして後工程で何が役立ったかをお伝えします。*今日から始めるには、インタラクティブワークフロー用のスキルと自律型スキャンのためのデモハーンチを含む*[関連リポジトリ](https://github.com/anthropics/defending-code-reference-harness)をご利用ください。読み進める中で、各ステップを実装するスキルについても言及していきます。 ## 発見と修正のループ 最も多くの脆弱性を発見・修正しているチームは、既存のベストプラクティスの変種に収束しました。これらを 6 つのステップからなる一連の手順として要約しました： - 脅威モデル：スキャンを開始する前に、何が脆弱性としてカウントされるかを決定してください。 - サンドボックス：エージェントを隔離し、エクスプロイトを実証するためのサンドボックス環境を構築します。 - 発見：モデルにソースコード内の脆弱性を探索させます。 - 検証：どの発見が実際にエクスプロイト可能であるかを独立して確認します。 - トリアージ：発見された事象の重複を排除し、深刻度を割り当てて、修正が必要なものを優先順位付けします。 - パッチ適用：修正を適用し、脆弱性が無効化されたことを確認し、関連するバリエーションも検索します。 ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a17340b26b22fa10e3ed68e_image1.png) 脅威モデリングとサンドボックス化への一度きりの投資が、ディフェンダーのループを駆動します。これは発見、検証、トリアージ、パッチ適用という繰り返しのサイクルであり、ボトルネックは脆弱性の発見ではなく、その後のすべての工程にあります。最初の 2 つのステップ—脅威モデルとサンドボックスの構築—は、残りのループのためのセットアップです。これらは通常、コードベースごとに一度行われ、基盤となるシステムに変更が生じた際に再検討されます。次の 4 つのステップが、ソースに対して実行するループです：発見、検証、トリアージ、そしてパッチ適用。 コードベースに対する最初のスキャンでは、通常、最も多くの脆弱性が見つかります。その後の実行では、単純なものは以前のランで修正されているため、脆弱性の数は減る傾向がありますが、しばしばより複雑なものになります。ただし、*n 回目*の実行で新しい発見がゼロになるとは期待しないでください。モデルは確率的であり、コードが変更されていない場合でも、長いテールにわたって脆弱性が継続して流入することがあります。 コードベースとの最初のイテレーションでは、ループを複数回実行し、ネット新規の発見数とそのシステムに対するリスク許容度に基づいて停止タイミングを判断してください。その最初のイテレーションの後、(1) 定期的に、または (2) コードが意味のある変更を加えたたびにスキャンを継続してください。 次に、各ステップを詳しく解説します。なぜそれが重要なのか、何を生み出すのか、そしてどのように実装するのかについて説明します。 ## 1.脅威モデル：何が脆弱性とみなされるかを定義する 偽陽性の最も一般的な原因は、モデルが信頼境界（trust boundaries）をよく理解していないことです。モデルは、クライアントが破損した値を送信できる、または攻撃者が設定を制御できる可能性があるとしてコードを脆弱とフラグ付けすることがありますが、これらの入力はあなたの環境では*信頼されている*場合があります。逆に、インターネットに公開されたサービスが内部のみのものであると仮定し、真の脆弱性を過少報告することもあります。どちらの場合も、モデルはコードではなく脅威モデルについて誤っています。 あるチームは、発見された事象に共通するパターンに気づきました：モデルは、脅威モデル、システム設計ドキュメント、要件、制約が十分に文書化されているシステムにおいて最も高い性能を発揮します。脅威モデルが明確に定義されている場合、モデルによる発見事項の「90% が実際に悪用可能である」という結果が出ました。 Claude を活用して脅威モデルを構築するには、2 つのステップで行います。 まず、コード、ドキュメント、脆弱性の履歴から基礎を築きます。新しいセキュリティエンジニアに初日に手渡すような情報をモデルに提供します：アーキテクチャドキュメント、ウィキ、エントリーポイント、Git の履歴、過去の脆弱性です。これにより、コードのみから暗黙の知識、トレードオフ、設計決定を推測するという課題を克服できます。次に、システムコンテキスト、資産、エントリーポイント、信頼境界を含む脅威モデルを作成するようモデルに依頼します。最後に、過去のバグをクラスタリングし、関連する脆弱性クラスをリストアップさせます。脅威モデルには、どのような脆弱性に注目すべきか、またどの脆弱性に関心がないのか、そしてその理由も明記させるようにしてください。 あるチームは、過去数百件の CVE およびセキュリティ修正コミットを検証し、それらを「バグの形状」を示すヒントに要約しました。そしてモデルに対して 2 つの質問を行いました：「修正は完全だったか」「他の箇所にも適用されたか」。その結果、1 時間以内に 3 つの悪用可能な問題を見つけ出しました。彼らの言葉では、「過去に何が悪用されてきたか」を問うことは、「このコードベース内の脆弱性を見つけてくれ」と求めることよりも、成功へのはるかに簡単なチートコードになり得ると述べています。 ***One team noticed a pattern across their findings: the model performed best on systems with well-documented threat models, system design docs, requirements, and constraints. When the threat model was well-defined, the model's findings "were exploitable 90 percent of the time."* You can work with Claude to build a threat model in two steps: First, bootstrap from the code, docs, and vulnerability history.** Feed the model what you would hand a new security engineer on day one: architecture docs, wikis, entry points, git history, and past vulnerabilities. This helps overcome the challenge of inferring implicit knowledge, trade-offs, and design decisions from code alone. Then, ask the model to create a threat model that includes the system context, assets, entry points, and trust boundaries. Finally, have the model cluster past bugs and list the relevant vulnerability classes. Make sure the threat model documents what vulnerabilities you do and don't care about, and why. ***One team reviewed hundreds of past CVE and security-fix commits, distilled them into "bug-shape" hints, and asked the model two questions: was the fix complete, and was it applied everywhere else? They found three exploitable issues in an hour. As they put it: "'What have people exploited in the past' is sometimes a much easier cheat-code towards success than 'find me vulnerabilities in this codebase.'"* 第二に、システムをよく知る人物に対してモデルがインタビューを行うようにしてください。**Shostack の 4 つの質問**（https://github.com/adamshostack/4QuestionFrame）を検討しましょう：*何を作っているのか？何が失敗する可能性があるか？それに対して何をしているのか？うまくいっているか？*。まずブートストラップステップを実行して、インタビュー対象者がゼロから始めることがないようにします。これにより、脅威モデルをゼロから調査・構築するために数時間を費やすのではなく、草案から開始できます。また、インタビューステップは必須ではありませんが、コードやドキュメントからは得られない文脈を追加することで、脅威モデルの質が向上します。 いくつかの実践手法が大きな違いを生む可能性があります： - 依存関係のセキュリティポリシーを検討してください。多くのオープンソースプロジェクトは独自のポリシーを公開しています。例えば、vLLM の security.md、SQLite の「暗黒芸術への対抗策」、ImageMagick のセキュリティポリシーなどです。脅威モデルでは、これらを直接考慮し、ゼロからポリシーを再構築する必要はありません。 - 何を信頼するかを明確にしてください。設定ファイルや認証済みクライアントを信頼する場合は、その前提を脅威モデルに明記します。これらの仮定は、悪用不可能なバグと実際の脆弱性を区別するのに役立ちます。 - コードと共に THREAT_MODEL.md を含めてください。リポジトリ内に配置し、コードの変更に応じて更新してください。これにより、探索エージェントが検索前にこの文書を読み、既知の非問題点をスキップできるようになります。 脅威モデルは 2 つの場所で使用されます。1 つ目は「発見」フェーズでのスコープ定義です。コードを分割し、優先順位をつけた上で、対象外となる部分をスキップします。これは、すべてをスキャンすることができない大規模なコードベースにおいて特に有効です。2 つ目は「選別」フェーズでのフィルタリングです。広範囲にスキャンした後、脅威モデルを用いて、システムや環境に応じた深刻度のより適切な評価を行います。 ***あるチームが大規模プロジェクトのスキャンを行い、40% の偽陽性率を記録した際、その原因を調査しました。発見された事象は再現可能で、PoC（Proof of Concept）も悪用可能性を示していました。しかし、コードの責任者である開発チームは、これらのバグがプロジェクトの脅威モデルに適合しないとして、すべて偽陽性と却下しました。別のチームの CISO はこれを簡潔にこう述べています：「[このモデルは] コードの文脈については良好だが、我々自身の文脈については不十分だ」*** **[脅威モデルスキル](https://github.com/anthropics/defending-code-reference-harness/tree/main/.claude/skills/threat-model) をお試しください。** これは、本セクションで説明されている 2 つのステップを順に案内します。ブートストラップ（bootstrap）では、コード、CVE（Common Vulnerabilities and Exposures）、および git の履歴から草案を導出し、インタビューでは Shostack の 4 つの質問を通じてシステム所有者がそれを洗練させていきます。出力は THREAT_MODEL.md ファイルとなり、これは発見（Discovery）と選別（Triage）のステップで使用されます。 ## 2. サンクボックス：エージェントを安全に実行し、悪用可能性を検証する **サンクボックスの目的の一つは、システムを保護することです。** モデルが安全かつ自律的に実行できるようにするには、強力な分離層が必要です。これがなければ、エージェントがターゲットを超えてしまい、予期せぬ行動をとる可能性があります。 ***あるチームはモデルに対してネットワークアクセスがないと伝えていましたが、実際にはアクセス可能でした。その結果、モデルは GitHub からデータを取得できることを発見しました。別のチームでは、スキャン中にエージェントが GitHub のイシューに回答しているのを観察しました。** どちらの行為も悪意のあるものではありませんでしたが、コードや設定を通じて制約を強制する必要性を示すものでした。 分離レベルは脅威モデルに合わせて調整してください。コードを読み取る発見用エージェントにはコンテナで十分ですが、ターゲットとその PoC（Proof of Concept）はマイクロ VM（Firecracker など）または完全な VM で実行し、外部への通信（egress）をロックダウンして、何らかの形でプロダクションシステムに到達できないようにしてください。また、エージェントに対して認証情報（~/.aws, ~/.ssh, .env 等）が利用可能になることは決してあってはいけません。 サンドボックスへのネットワークアクセスは、セットアップ中のみ許可してください。依存関係をプルし、ビルドし、ツールをインストールし、ターゲットを展開し、既存のテストを実行してすべてが正常に動作することを確認します。その後、環境のスナップショットを取得し、ネットワークアクセスを削除します。スキャン中は、ローカルプロキシを経由してモデル API へのトラフィックのみを許可してください。各実行の開始時にスナップロードを読み込み、すべてのスキャンが同じクリーンな状態から始まるようにします。 サンドボックスのもう一つの目的は、悪用可能性を実証することです。**静的スキャン中、モデルはコードを読み、何が壊れる可能性があるかを仮説立てますが、パスが到達可能かどうかや、補完的な制御が存在するかどうかをテストすることはできません。その結果、モデルは実際には気にする必要のない、悪用不可能なコードの正しさに関するバグを警告する可能性があります。チームがエージェントにコードのコンパイル、テストの実行、概念実証（PoC）の起動を可能にするサンドボックスを構築したところ、悪用不可能な発見は大幅に減少しました。 ***ある攻撃的セキュリティチームは、エージェントにテストベッドを与えるハネスを構築しました。その単純な検証ルールとは、「エージェントが概念実証を構築し、テストベッドで実行できる場合にのみ、それは真の陽性結果である」というものです。** 6 週間後の評価では、「最大の効果向上要因は、モデルにテストベッドとライブシステムを与え、PoC を実行させることだった」と結論付けられました。 サンドボックスを構築する際は、可能な限りすべての要素を固定し、各実行が同じ環境で同じコードを使用するようにしてください。具体的には、イメージタグ、コミット SHA、依存関係、ビルドコマンドなどを固定します。ローカルコピーをキャッシュしてネットワーク接続不要とし、コンテナを耐久性のあるものにして、複数のテストループで読み込むだけで済むように目指しましょう。 *あるチームのスキャンが脆弱性を検出しましたが、これは実際にはエージェントがデプロイされたバージョンではなく古いバージョンのライブラリをダウンロードしたことが原因でした。この問題は、エンジニアがトランスクリプトを読み込み、異なる依存関係がダウンロードされていることに気づいたことで発見されました。現在は、本番環境と一致するように依存関係を固定した Docker コンテナをビルドしており、検出エージェントと検証エージェントはどちらも攻撃者が利用する可能性のある同じアーティファクト上で動作しています。 サンドボックスは本番環境に忠実であることが重要です。依存関係（キューやデータストアなど）を除外すると、本番環境に存在するバグが過少報告される可能性があります。逆に、本番環境の防御策（WAF や認証ゲートウェイなど）を無視すると、モデルが本番環境ですでに対処済みの攻撃不可能な発見結果を報告することになります。 ただし、クラウド依存関係やデータストア、その他の現実世界の複雑さのために代表例のサンドボックスを構築することが実用的でない場合は、代わりに発見フェーズ（以下）から始めてください。PoC を必ずしもサンドボックスで実行する必要はありません。最先端モデルはソースコードを分析するだけで脆弱性を発見するのが得意です。私たち自身を含むいくつかのチームが、この手法の有効性を見出しています。その代償として検証フェーズに現れます。実行中のターゲットがないため、PoC で発見事項を実証できないからです。そのため、検証にはより多くの時間を割り当ててください。また、発見された件数がそれを正当化するようになった時点で、後からサンドボックスへの投資を行うことも可能です。 参照用サンドボックスについては、**[harness README.md](https://github.com/anthropics/defending-code-reference-harness/tree/main/harness)** をご参照ください。**この実装では、エージェントとターゲットは gVisor で隔離されたコンテナ内で実行され、出口トラフィックはモデル API にロックされています。ターゲットは特定のコミットに固定された Dockerfile からビルドされ、[setup_sandbox.sh](https://github.com/anthropics/defending-code-reference-harness/blob/main/scripts/setup_sandbox.sh) がセットアップフェーズを処理します。 ## 3. 発見：豊富なコンテキスト、短いプロンプト、有用なツールを提供する 発見エージェントに、必要に応じて読み込めるコンテキスト（脅威モデル、アーキテクチャドキュメント、過去のスキャン結果など）へのアクセス権を与えてください。エージェントがあなたの信頼境界とシステムが実際にどのようにデプロイされているかを理解すれば、そのシステム固有の脆弱性をより適切に特定できるようになります。 私たちは、発見フェーズにおいて、より単純なプロンプトを用いることで最先端モデルの性能が向上することを発見しました。直感に反するようですが、より指示的なプロンプトは発見を悪化させます。長いチェックリストはモデルの創造性を低下させ、新規のバグを fewer 生じさせる傾向があります。以下に、発見フェーズで役立ったいくつかのプロンプティングのヒントを示します： - 目的と文脈を提示してください。「なぜ」スキャンするのか、「何を」目指しているのか、どのような発見が重要なのか、どのシステムを対象としているのかを明確にし、「脆弱性をどのようにスキャンするか」という手法についてはモデルに任せてください。最先端のモデルはセキュリティタスクにおいてますます優秀になっており、過度に具体的な指示を出すことで、モデルが取り組む範囲が狭まってしまう可能性があります。 - 特定の脆弱性クラスについて問い合わせることを試みてください。特定の種類の脆弱性に焦点を当てたい場合、過去の CVE やコードベースで使用されている言語に基づいてガイドしてほしい場合は、その旨を述べてください。脆弱性クラスの定義、その動作、およびそれが発生しやすい場所を説明することで、モデルがコードベース内でそれを認識できるようになります。 - 出力形式を定義してください。事前定義されたフィールドを持つ構造化レポートを求め、モデルの推論が各フィールドに基づいて積み重えられるように順序付けてください。例として、根拠（rationale）、発見内容（finding）、影響度（impact）、深刻度（severity）などのフィールドがあります。弱い発見に対しては早期に終了できる「脱出経路」も設けてください。 - モデルにコードベースを検索・閲覧するためのツールを提供してください。grep や glob などが該当します。また、チームが使用するセキュリティ特化型のツール、例えば静的解析スキャナ（SAST scanners）やファズャー（fuzzers）の利用も許可してください。特定のタスクに必要なツールをモデルに問いかけ、それらを利用可能にしてください。最後に、必要に応じてモデル自身がツールを作成できるようにしてください。最近の最先端モデルは、必要なツールを自ら作成する能力がますます高まっています。 ***ソースコードに加えて、あるペネトレーションテストチームは、発見エージェントにリクエストの送信、レスポンスの確認、トラフィックログの照会を行うツールを提供しました。その結果、エージェントはパスが到達可能かどうかを推測する必要がなくなり、実行中のアプリケーションに対して各候補を順次テストできるようになり、真陽性率をほぼ 100 パーセントまで向上させることができました。 モデルにシステム全体を一度走査させ、攻撃対象領域、エンドポイント、またはコンポーネントなどによって探索空間を分割してください。その後、これらの分割された領域を並列発見エージェントに供給して、同じ浅いバグに収束しないようにします。最後に、分割レベルでの発見結果を文脈として取り込み、脆弱性を検索するシステムレベルの走査を実行します。 ブルートフォースによる探索を試みたチームはすぐにリターンの逓減に直面しました。あるチームからは「当初は単に水平方向のスケーリングを行い、より多くのエージェントを送信しましたが、限定的な結果しか得られませんでした」という声がありました。別のチームは注力領域と並列エージェントの数を増やして「多数の問題」を発見しましたが、それらの多くは互いに重複するものでした。 ターゲットを実行できるサンドボックスがある場合は、発見エージェントに対して発見内容の PoC（Proof of Concept）を構築させるよう依頼してください。例えば、スクリプト、クラッシュを引き起こす入力、または失敗するテストなどです。PoC を構築することで、エージェントは反復して発見内容を特定しやすくになり、その成果物は検証エージェントが評価するための具体的な証拠となります。ただし、エージェントが再現できない発見についても報告可能であり、「未証明」とフラグを立てておくことで、リコール（検出率）を高く維持できます。 **[vuln-scan skill](https://github.com/anthropics/defending-code-reference-harness/tree/main/.claude/skills/vuln-scan)** は、この段階で役立ちます。これはあなたの THREAT_MODEL.md を読み込み、対象を焦点領域に分割し、各領域ごとに並列レビューエージェントを展開します。出力は構造化された発見事項であり、次のステップで直接消費されます。 ## 4. 検証：非実装可能な発見事項のフィルタリング 発見（Discovery）は再現率（recall）の最適化を目指しますが、検証（Verification）は精度（precision）の最適化を目指します。つまり、発見では可能な限り多くの脆弱性、たとえ可能性が低いものでも見つけるべきであり、検証では実際に悪用できない発見事項を除外すべきです。エージェントが同じステップでこの両方を行おうとすると、自己検閲を起こし、実装可能な真陽性（true positives）を除外してしまう可能性があります。私たちはこれを苦い経験から学びました。発見エージェントに発見事項の検証も依頼したところ、それらは別の検証ステップであれば確認されたはずの実装可能な真陽性をフィルタリングしてしまいました。 検証者エージェントは発見者エージェントとは独立している必要があります。検証者は共有ファイルシステムや会話履歴を持たない新しいコンテナで実行してください。もし検証者が発見者エージェントの推論に晒されると、単に主張をテストするのではなく、同意してしまう可能性があります。したがって、検証者には（1）概念実証または書かれた発見事項と、（2）コードベースのみを与え、発見者が見落とした緩和策（例えば、上位層でのバリデーション、認証ゲート、型制約、または到達不能なコードなど）を検索できるようにしてください。 単一の検証パスでも非悪用可能な発見が多すぎる場合は、複数の独立した検証器を実行してみてください。これらは異なる角度から検討したり、異なるモデルで実行したりできます。その後、多数決を採用します。また、発見エージェントと検証エージェントの結果の間を決定する別の審判者を設けることも検討してください。 検証エージェントに対して、発見エージェントの発見を反証するようプロンプトしてください。検証者は各発見が偽陽性であると仮定し、その発見が誤りである理由を検索します。検証エージェントが発見が真陽性かどうかを判断するために使用できる明確な基準を含めてください。これは、発見エージェントの出力に PoC（Proof of Concept：概念実証）が含まれていない場合に特に重要です。手動レビューにかかる負担を減らすために、非悪用可能な発見をできるだけ多く除外することを目標とします。 ***私たちが協力してきたチーム全体において、敵対的検証器を追加することで、発見フェーズからの非悪用発見の割合がおよそ半分になりました。その検証器に、悪用の証明となる概念実証（PoC）も構築するよう要求したことで、偽陽性率はほぼゼロまで低下しました。これら 2 つのステップを組み合わせることで、下流のトリアージとパッチ適用の負荷が大幅に軽減されました。 サンドボックス内で本番環境を十分に再現できる場合（手順 2 を参照）、検証エージェントに対して再現可能な概念実証（PoC）を構築・実行するようプロンプトしてください。PoC が機能すれば、その発見は悪用可能であると結論付けられます。ただし、逆は成り立ちません。動作する PoC を作成できないことが、偽陽性であることの証明にはなりません。 あるチームは、オープンソースパッケージをスキャンする際に、ループを閉じるための検証ステップを構築しました。具体的には、パッケージのスキャンを行い、概念実証（PoC）を生成した上で、そのパッケージを使用して PoC をトリガーするモックアプリケーションを展開します。彼らの見解は以下の通りです：「検証が最大のボトルネックであり、PoC がその検証である」。 ## 5. トリアージ：根本原因による重複排除と、前提条件および影響度に基づく優先順位付け 検証が発見が実際に悪用可能であることを確認する一方で、トリアージはパッチ適用の優先度を評価します。以前は発見に多くの労力が必要だったため、バグを発見したエンジニア自身がトリアージを行っていました。しかし現在では、昼食前にモデルが数百件の候補を見つけられるようになったことで、トリアージがボトルネックとなっています。 適切なトリアージはアラート疲労を防ぐために役立ちます。重複しているものや深刻度が過大評価されたバグを多数提出すると、製品エンジニアたちはそれらを読み続けるのをやめてしまう可能性があります。即時パッチが必要なものさえも例外ではありません。オープンソースのメンテナは特に、自社のソフトウェアに依存する多くの異なるユーザーから報告が寄せられるため、トリアージされていない発見によって圧倒される可能性が高いです。 複数のチームが同じ教訓を共有しました：「非悪用可能なものが大半を占める発見の山を製品エンジニアに送れば、彼らはレポートへの信頼を失い、あきらめてしまう」。また、下流のエンジニアたちを圧倒しないよう、重要度が高く深刻な発見を優先しています。他のチームは、既存のバックログ（過去のスキャナやモデルからの未解決項目、バグ報奨金プログラムでの受付分など）に対してモデルを活用することで成功を収め、数日で数百件の古くなったアイテムを解消しました。 発見事項の重複排除には、根本原因を検討してください。スキャナは、1 つのバグを複数の呼び出しサイトでフラグ付けしたり、単一の根本原因の複数の症状を報告したりすることがよくあります。ここに実用的なアプローチを示します：まず、安価で決定論的なパスを実行します。同じファイル、同じカテゴリ、脆弱性のある行番号が互いに 10 行以内にあるものを対象とします。次に、残った事項に対してモデルが定性的ルールを適用させます。 - 重複として扱う：根本原因は同じだが表現が異なるもの；複数の呼び出しサイトで報告された同一の脆弱性；エンドポイントごとに報告されるグローバル保護（認証チェックなど）の欠如；または、同じパス内で原因とその結果が両方フラグ付けされているもの。 - 個別の事項として扱う：同じファイル内の異なる脆弱性クラス；異なる変数が異なるシンクに到達するもの；1 つのヘルパー関数内に存在する 2 つの独立したバグ；2 つのエンドポイントで同一のチェックが欠落しているが、それぞれに独自の修正が必要となる場合。 もしあなたのハーン（検証環境）が各発見事項に対して PoC（Proof of Concept：概念実証）とパッチを生成する場合、もう一つの重複排除のアプローチとして、ある発見事項に対するパッチが他の発見事項の PoC も無力化するかを確認する方法があります。 重複排除後、以下の基準に基づいて各発見事項の重大度を評価してください： - リーチアビリティ。攻撃者は実際のエントリーポイントからこのコードに到達できるのか、それとも内部コードやエンドポイントからのみ到達可能なのか。 - 攻撃者の制御。信頼できない入力がシンク（終点）まで無傷で到達するのか、それともその上流で何らかのサニタイズや制約が加えられるのか。 - 事前条件。バグが発動するために何が整っている必要があるのか：デフォルトではない設定、特定の特徴フラグ、攻撃者が狙うべき限られた時間窓など。 - 認証。未認証の攻撃者でもこれを発動できるのか、それともログイン済みユーザーや管理者権限が必要なのか。 - 読み取り vs 書き込み。攻撃者はデータを閲覧するだけか、それとも変更も可能か。 - ブラストレイディアス（影響範囲）。PoC が実行された場合、誰が影響を受けるのか？一人のユーザーか全ユーザーか、一つのテナントかプラットフォーム全体か、ユーザランドかカーネルか。 この評価基準をスコアに変換するには、モデルに severity を割り当てる前に各質問への回答を書き出させること。証拠を先に確認させることで、モデルがバグクラス（「SQL インジェクションだからクリティカル」など）にアンカーしてしまい、それに合わせて severity を過大評価するのを防ぐことができる。出発点として：事前条件ゼロで未認証の遠隔アクセスが可能ならクリティカルまたは高リスク、事前条件が一つまたは二つ、あるいは認証が必要なパスなら中リスク、三つ以上、またはローカルのみなら低リスクとする。これらの閾値は自社のシステムに合わせて調整すること。 モデルは文脈が不十分なために深刻度を過大評価する可能性があります。攻撃者が実際に制御できる入力や、それを補う対策が見えない場合があります。前者の例として、認証されていないリクエストによってトリガーされる SQL インジェクションは重大ですが、管理者のみがアクセス可能な設定ファイルからトリガーされる場合は問題にならないことがあります。後者の例では、ソースコードだけでは見えないアップストリームの WAF や認証機能が攻撃を防いでいる場合もあります。 解決策は、トリアージ段階で脅威モデルを提供し、システム内でどの種類の脆弱性に注目すべきか、あるいは気にする必要がないかをモデルに伝えることです。例えば、「認証されたクライアントを信頼している」と明確化することで、重大な問題のクラス全体を簡略化したり除外したりできます。 *あるチームでは、検証できる根拠や脅威モデルの一部として何が期待されるかという文脈がなければ、モデルは過度に自信を持っていることが多く、その対策として発見エージェントと同じ脅威モデルをトリアージエージェントにも提供しました。* **[トリアージスキル](https://github.com/anthropics/defending-code-reference-harness/tree/main/.claude/skills/triage) をお試しください。** これは検証とトリアジの両方を行います：各発見事項に対する複数投票による検証、実行間での重複排除、派生する攻撃可能性に基づく再ランク付け。出力は生のデータダンプではなく、短く、ランク付けされ、責任者が明確なリストとなります。 *One team found the model is often overconfident unless grounded in something to verify, or has more context on whether something is expected as part of the threat model. Their fix was to give the triage agent the same threat model the discovery agent gets.* Try the **[triage skill](https://github.com/anthropics/defending-code-reference-harness/tree/main/.claude/skills/triage)**. **It does both verification and triage: multi-vote verification per finding, deduplication across runs, and re-ranking by derived exploitability.** The output is a short, ranked, owned list instead of a raw dump. ## 6. パッチ適用：ループを閉じ、次のサイクルのための文脈を改善する パッチ適用は脆弱性を修正し、ループを完了させる段階です。また、検証された発見結果に基づいて脅威モデルを改善し、信頼境界やより厳重な検討が必要なコンポーネントを更新するとともに、過去の発見結果を次のスキャンの文脈にフィードバックします。各サイクルを通じてコードベースが強化され、次回のスキャンはより情報に基づいたものになります。 パッチ適用の前には、既存のコードで失敗する新しいテストを作成してください。その後、修正を実装し、その同じテストが他の機能を壊さずに成功することを確認します。（はい、これはテスト駆動開発です）もしテストを追加しなければ、修正が静かに後退（レグレス）し、バグが実際に存在したことを事後に証明するのが困難になる可能性があります。 ***あるペネトレーションテスターは、生成されたパッチが不整合であることを見つけました—一部は良好で、一部は不良でした。しかし、ハーン（枠組み）がモデルに対して、修正済みコードに対して概念実証を再実行することでパッチを検証するよう指示したことで状況が変わりました。モデルに反復するためのフィードバックを与えることで、パッチの品質が飛躍的に向上し、人間のレビューにかかる時間を節約できました。*** モデルは、根本原因ではなく特定の呼び出し箇所でのみ発見された問題に狭く対応する可能性があります。単純にモデルに対して根本原因の特定と修正を指示するだけで効果的な場合があります。その後、モデルには 2 つのレベルでバリエーションを検出させます：(1) 同じパターン——同じ不具合コードのコピーや他の呼び出し箇所が他にある場合、(2) 同じクラス——SQL インジェクション脆弱性が 1 つあるコードベースは、より多くの SQL インジェクション脆弱性を抱えている傾向があるというものです。検証された発見結果とパッチを適用して脅威モデルを更新し、ループを閉じます。 パッチをリリースする前に、敵対的チェックを実行してください。新しい発見エージェントに攻撃者としてパッチを検査させ、パッチが包括的であることを確認します。その後、生成されたパッチが過度に侵入的すぎる場合に備えて簡素化します。最小限のパッチはレビューが容易で、新たなバグを導入する可能性も低くなります。根本原因を修正するための最小限の変更を指示してください——リファクタリングも、ついでに行うクリーンアップも、書式変更も不要です。 *あるチームが最も一般的なパッチの失敗について語ったこと：「推奨されるパッチは可能な限り制限的になりがちで、他のサービスとの接続を切断するほどになることがあります。問題は解決しますが、そのサービスが最初に動作するために必要な依存関係を壊してしまいます。」* 各パッチは、最も安価なものから順にチェックの階段（ladder of checks）に対して検証できます： - Build. パッチのコンパイルに成功し、新しいテストもパスします。 - Try to reproduce. 元の PoC が動作しなくなることを確認します。これにより、効果のないパッチを検出できます。 - Check for regressions. 既存のテストスイートが依然としてパスすることを確認します。これにより、破損したパッチや過度に制限的なパッチを検出できます。 - Re-attack. 新しい発見エージェントが敵対的チェックを実行します。これにより、不完全なパッチを検出できます。 最後に、モデルがパッチを記述できる一方で、人間がその責任を負う必要があります。生成されたパッチは予測可能な方法で失敗する可能性があります—例えば、根本原因ではなく症状のみを修正したり、正当な入力をブロックしたり、依存サービスへのアクセスを削除したりすることです。目標は、各パッチを可能な限り検証し、人間のレビューに必要な労力を最小限に抑えることです。また、モデルが気づいていない微妙な点（例：新しい変更の導入、コードスタイル）に開発チームが集中できるよう支援し、パッチに対するレビューと更新を最小限に抑えることも目標です。 **[patch skill](https://github.com/anthropics/defending-code-reference-harness/tree/main/.claude/skills/patch)** をお試しください。これはトリアージ出力を受け取り、各発見に対して候補となる diff を生成し、独立したレビューエージェントがそれぞれをチェックします。 ## Getting started Try running the loop yourself. Clone [defending-code-reference-harness](https://github.com/anthropics/defending-code-reference-harness) and run /quickstart in Claude Code. It walks you through an interactive workflow, from threat modeling to scanning to triage, on a demo target. The repo also includes an autonomous harness and a /customize skill to update the harness for your environment. Then, run it on your own code. Pick a service or package. Bootstrap a threat model from the code and docs, and go through the interview. Invest in building a sandbox of your environment. Scan. Verify the findings with an independent agent. Triage based on your criteria and review everything rated high and above. Patch. Then re-scan periodically. Your first scan will surface more findings than you'd expect. Most will require verification and triage. Budget for the pipeline *after* the scan before you budget for more scanning. Some resources you might find helpful: - Claude Security：エージェント型脆弱性検出とパッチ適用を担う Anthropic の管理型製品。 - defending-code-reference-harness：対話型ワークフロー用のスキルや、自律実行向けのデモハーンチを提供するコンパニオンリポジトリ。 - claude-code-security-review action：プルリクエストごとに Claude をセキュリティレビュアーとして機能させる GitHub アクション。 - Threat Intelligence Enrichment Agent：脅威インテリジェンスフィードに対して、侵害指標（IOC）を強化するエージェントを構築するためのクックブック。 - Vulnerability Detection Agent：脅威モデルの構築、脆弱性のスキャン、および構造化レポートへの発見事項のトリアージを行うエージェントを構築するためのクックブック。 ## 今後の展望 モデルがコード内の [脆弱性を発見し、悪用する](https://red.anthropic.com/2026/exploit-evals) ことが容易になってきていると考えています。したがって、防衛者としての私たちの役割は、敵対者がそれらを悪用する前に、自社のコード内の脆弱性を発見して修正することです。一部のチームでは、ハーンチをイベントに接続するところまで進んでいます。具体的には、バグ報奨金レポートが自動的な変異解析トリガーとなり、セキュリティレビューがスキャンと候補となる発見事項の添付をトリガーしたり、確認された脆弱性が静的解析ツールを更新して将来の再発を防いだりしています。 この取り組みは極めて重要で、 stakes（賭け事）も高いものです。しかし、適切に行われれば、これはより大きく、より希望に満ちた転換の始まりとなります。そこでは、攻撃者が脆弱性を悪用する前に、それを発見して修正することが可能になるのです。 サイバーセキュリティに関する私たちの取り組みに引き続き関心をお持ちいただける場合は、[こちら](https://claude.com/form/cybersecurity-mailing-list)からメールマガジンの購読をご登録ください。 ## 謝辞 本稿はユージン・ヤンとヘナ・ダッタニが執筆し、マイケル・モラッシュ、アベル・リビンク、ジャスティン・ヤング、ベン・モリス、デビッド・ドワーケン、ハスナン・ラクァニーの各氏からの寄稿を含んでいます。本取り組みは、Anthropic においてセキュリティ分野でモデルを活用してきた私たちの経験と、パートナーおよび顧客の皆様から共有いただいた貴重な知見に基づいており、これらに対して深く感謝申し上げます。

LLM を活用したソースコードのセキュリティ強化

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト