AI を活用した脆弱性検出ハーネス (パート 1 構築編): 3 層パイプラインによる検出結果の絞り込み

本ブログは 2026 年 10 月 7 日に公開された AWS Blog “Building your AI vulnerability harness, Part 1” を翻訳したものです。

脆弱性スキャナーが検出結果を生成するペースは、手動のトリアージで処理できる速度を上回っています。開発者が多くの依存関係を伴うコードをより多くリリースするにつれて、検出結果の候補も増え続けます。

スキャナーが生成する検出結果の多くは、悪用される可能性が低いものです。重要な検出結果は、エンジニアが分析をやり直さずに直ちに対応できるだけの証拠を添えて、すばやく届ける必要があります。課題は、パイプラインが求めるスピードでシグナルとノイズを見分けることです。

この記事では、検出から対応までのギャップを埋める方法を紹介します。スキャナーが出力した未加工の検出結果を、悪用可能性の証拠が文書化された、優先順位付きの少数の検出結果に絞り込む 3 層のパイプラインを構築しました。関連記事「ステアリングファイルで実現する証拠ベースの脆弱性トリアージ」では、このパイプライン内でモデルの動作を制御するステアリングファイルについて取り上げます。この記事では、そのステアリングファイルを取り巻く各層について説明します。

パイプラインの価値は、特定のツールではなく、フィルタリングロジックと証拠の基準から生まれます。そのため、アーキテクチャを変えずに、お使いのスキャナーやモデルに置き換えることができます。お使いの AI プロバイダー、インフラストラクチャスタック、スキャナーの組み合わせは、この記事で使用したものとは異なるでしょう。しかし、各層で何をフィルタリングするか、何を証拠とみなすか、どこでモデルを信頼するのをやめるかといったアーキテクチャ上の判断は、環境にかかわらず応用できます。

テストハーネスとは、制御された入力をシステムに与え、出力が期待される動作と一致するかどうかを観察する自動化されたフレームワークです。脆弱性検出に適用する場合、ハーネスは検出結果の候補ごとに悪用可能性を評価するテストを作成し、そのテストを制御された環境で実行して、証拠を記録します。ハーネスはテストのためのインフラストラクチャであり、それが生成する結果そのものではありません。

従来の静的アプリケーションセキュリティテスト (SAST) ツールはパターンマッチングに依存しており、データフロー分析の能力はツールや言語によって異なります。既知のパターンに当てはまるシンクの検出は得意ですが、マルチホップのチェーン、ビジネスロジックの欠陥、コンテキストに依存するサニタイズ、そしてシンクが攻撃者の制御する入力から到達可能かどうかの判断は苦手です。AI で強化した分析は、こうした推論のギャップを補います。具体的には、ファイルをまたいでデータを追跡し、意図を推測し、デプロイコンテキストを考慮します。

概念上の重要な違いは、モデルをコードベースに対して実行するわけではないという点です。コードベースは、特定のプロンプトと共にモデルに渡すコンテキストです。モデルはコードを受け取り、データがどのように流れるか、信頼境界がどこにあるか、セキュリティに関連するパターンが存在するかどうかを推論します。

コンテキストのスコーピングは、このアーキテクチャの中でも難しい部分の 1 つです。コンテキストが多すぎるとモデルの推論ウィンドウを圧迫するおそれがあり、少なすぎると分析に抜けが生じて検出漏れ (false negative) を招くおそれがあるためです。基本的な AWS Lambda 関数であれば、関連するコンテキストは単一のファイルとその AWS Identity and Access Management (IAM) ロールだけで済むかもしれません。一方、共有ライブラリと階層化されたインフラストラクチャを備えた複雑なマイクロサービスの場合、何を含めるかを判断するには、アプリケーションの依存関係グラフを理解する必要があります。デプロイトポロジーをモデルに提供すれば、モデルはそれについても推論できます。例えば、AWS Cloud Development Kit (AWS CDK) のコンストラクトや AWS CloudFormation テンプレートを追加のコンテキストとして渡す方法があります。一般に、すべてを一度に渡すよりも、まず範囲を狭くして始め、モデルの初期評価で結論が出ない場合にだけ範囲を広げる方が、良い結果が得られます。

セキュリティスキャナーは、実行するたびに大量の検出結果を生成することがあります。その多くは、脆弱性のように見えて実際には問題ではない誤検知 (false positive) です。本当の問題とノイズを区別するために、パイプラインは 3 つの層で検出結果をフィルタリングします。各層では、それぞれ異なる種類の証拠を用います。最終的には、文書化された証拠に裏付けられた、優先順位付きの少数の問題が残ります。

最初に確認するのは妥当性です。同じコードベースに対して複数のスキャナーをそれぞれ独立して実行します。2 つ以上のスキャナーが同じ検出結果を示した場合、信頼度が高まります。1 つのスキャナーだけが問題を報告し、他のツールがいずれも同じ検出結果を示さない場合は、パイプラインがその検出結果に追加の精査が必要であることを示すフラグを付けます。

複数スキャナー間の一致と呼ばれるこのアプローチは、低コストで信頼度を高められる方法です。既存のツールをそのまま利用でき、新たなインフラストラクチャも必要ありません。

第 2 層では構造を検証します。AI を活用したスキャナーは、脆弱性がどのような仕組みで成立するかについての自らの推論を説明します。例えば、データがある関数から入り、別の関数を経由して、害を及ぼし得る箇所に到達する、といった説明です。ただし、こうした説明が誤っている場合もあります。

検出結果を次の層に進める前に、パイプラインは実際のコードと照合して検証します。スキャナーが言及した関数やファイルが存在するかどうか、そしてスキャナーが説明した経路に沿ってデータが流れ得るかどうかを確認します。確認できない場合、パイプラインはその検出結果を却下します。

この検証ステップでは、コードの抽象構文木 (AST) を使用します。AST とは、コードベース内の関数、ファイル、データフローのつながりを表す構造化されたマップです。このステップは、パイプラインの出力の信頼性を保つのに役立ちます。検証されていない検出結果がレビュー担当者に届くと、チームはすぐに結果を信用しなくなり、ツールのセキュリティ上の価値が損なわれます。

最後の層では、デプロイコンテキストを加味します。脆弱性はアーキテクチャというコンテキストの中に存在し、そのアーキテクチャには保護コントロールが含まれている場合があります。こうしたコントロールには、AWS WAF ルール、ネットワーク分離、認証要件、入力検証などがあります。

この層では、アプリケーションのソースコードと併せて、Infrastructure as Code (IaC) テンプレート (クラウドアーキテクチャを定義する CloudFormation や Terraform のファイルなど) を読み込みます。そのうえで、攻撃者が既存のコントロールを回避して脆弱性を悪用できるかどうかを確認します。

コントロールによって保護のレベルは異なります。該当する攻撃手法を直接ブロックするウェブアプリケーションファイアウォールのルールは、別の種類の脆弱性を対象とするルールよりも強力な緩和策になります。パイプラインは、コントロールの有効性を「はい」か「いいえ」の二択ではなく、段階的な尺度として扱います。

最終的に得られるのは、少数に絞り込まれた検出結果のリストです。各検出結果は 3 つの層をすべて通過しています。つまり、妥当性チェックに合格し、構造がコードと一致し、デプロイコンテキストから悪用可能であることが示されています。層を経るごとに検出結果の数は減り、残った検出結果に対する信頼度は高まります。

このパイプラインを構築する中で、4 つの原則が見えてきました。

• 証拠の要件を高めながら進める段階的なフィルタリング – 各層では、それぞれ異なる種類の証拠が求められます。第 1 層では検出結果が妥当であることを確認し、第 2 層では構造的に実在するかどうかを判断し、第 3 層ではコンテキストにおいて悪用可能かどうかを分析します。包括的な 1 つの層よりも、焦点を絞った 3 つの層の方が効果的です。層ごとに異なる種類のエラーをとらえられるためです。
• インフラストラクチャのコンテキストが優先順位付けを変える – デプロイコンテキストがなければ、重大度がクリティカルな検出結果は、重大度が中程度の検出結果よりも緊急性が高いと考えがちです。しかし、強力な保護コントロールの背後にあるクリティカルな検出結果の方が、インターネットに直接公開されている中程度の検出結果よりも緊急性が低い場合があります。この評価を行うには、パイプラインがアプリケーションのソースコードだけでなく、IaC テンプレートにもアクセスできる必要があります。
• 独立したツール間の一致は単一ツールの信頼度に勝る – あらゆる種類の脆弱性を確実に検出できるスキャナーは 1 つもありません。あらゆる状況で正しい結果を出せるモデルも存在しません。独立した複数のツールが同じ検出結果で一致した場合、その一致は、1 つのツールが自己申告する信頼度スコアよりも強いシグナルになります。この原則は、どのツールを選んでも概ね当てはまります。
• AI が生成した主張は人によるレビューの前に検証が必要 – 言語モデルは、もっともらしく聞こえても正しいとは限らない出力を生成することがあります。AI が生成した検出結果を、人がレビューする前に実際のコード構造と照合して検証することが、有用なシステムと、自信ありげな誤りで信頼を損なうシステムの分かれ目です。

すべてを一度に構築する必要はありません。すぐに効果が得られるものから順に導入してください。

• インデックス作成から始める – エントリポイント、シンク、認証設定を洗い出せる、AST ベースのコードベースのインデックスを構築 (または既存のものを利用) します。実行コストはかからず、AI を使う前の段階でアタックサーフェスのマップが得られます。
• 複数スキャナーによるトリアージを追加する – 既に利用している Semgrep、CodeQL、または同等のツールの出力を AST ゲートに通し、さらに大規模言語モデル (LLM) で悪用可能性を分類します。既に実行しているツールの出力をフィルタリングするだけなので、わずかな投資で大幅なノイズ削減を実現できます。
• 仮説生成を追加する – トリアージが安定したら、スキャナーが見逃す脆弱性 (マルチホップのチェーン、ビジネスロジックの欠陥、パッケージをまたぐデータフロー) を AI 主導で発見する仕組みを追加します。このステップでは、ステアリングの品質が結果を大きく左右します。詳細については、関連記事「ステアリングファイルで実現する証拠ベースの脆弱性トリアージ」を参照してください。
• インフラストラクチャのコンテキストを追加する – CDK または CloudFormation を解析し、コントロールを脆弱性クラスにマッピングして、乗数を適用します。これにより、優先順位付けの精度が高まります。
• ライブ検証を追加する – デプロイ済みの本番前環境のターゲットに対して、構造化された成功基準を設けて、脆弱性の悪用可能性を示す概念実証 (PoC) を実行します。このステップは運用上のオーバーヘッドが最も大きいため、最後のステップとして、信頼度のしきい値を既に満たした検出結果に対してのみ実行してください。

パイプラインは、時間をかけて調整していくものととらえてください。既知の正しい検出結果と誤検知を使って検証し、重みを調整して再実行します。結果は変わっていきます。

ハーネスは検出のためのインフラストラクチャです。どの検出結果が実際の問題である可能性が高く、どれに優先して対応すべきかを把握するのに役立ちます。ただし、ハーネスでは次のことはできません。

• コードを修正すること – 修正は別の課題です。ハーネスは、人またはエージェントが対応できるだけの証拠を備えた検出結果を生成しますが、修正作業そのものには専用のツールとプロセスが必要です。
• 最終的な対応に向けた人によるレビューを代替すること – 3 層のフィルタリングを経た後でも、出力されるのは悪用可能と考えられる検出結果の優先順位付きリストであり、実証済みのエクスプロイトではありません。優先度 0 (P0) の検出結果であっても、コード変更に着手する前にエンジニアがレビューする必要があります。
• スキャナーの組み合わせの検出範囲外にある脆弱性クラスを検出すること – 特定の脆弱性カテゴリを対象とするスキャナーが 1 つもなければ、ハーネスがその脆弱性を検出することはありません。AI で強化した仮説生成によってこのギャップの一部は埋められますが、新しい種類の欠陥やビジネスロジックの欠陥を検出できるかどうかは、依然としてモデルがコードだけからどこまで推論できるかに左右されます。
• 稼働中のインフラストラクチャの状態をデフォルトで検証すること – IaC を解析すれば、何が定義されたかはわかります。しかし、先週 WAF ルールが無効化されたかどうかや、デプロイ後にセキュリティグループが変更されたかどうかはわかりません。ライブ検証は追加で統合するものであり、各層そのものが備える特性ではありません。

これらの制限はいずれも、アーキテクチャが破綻する箇所ではなく、拡張できる箇所を示しています。ハーネスは複数階建てのシステムの 1 階部分にすぎず、建物全体ではありません。

この記事では、複数スキャナー間の一致、構造検証、デプロイコンテキストの 3 層からなるパイプラインによって、スキャナーの出力を、チームが対応できる信頼度のより高い少数の検出結果に絞り込む方法を紹介しました。このアーキテクチャは特定のツールに依存しません。応用できるのは、どこでフィルタリングするか、何を証拠とみなすか、どの時点でモデルを信頼するのをやめるか、という考え方です。

モデルが一貫した指示を受け取れば、このアーキテクチャは一貫した結果を生み出します。関連記事「ステアリングファイルで実現する証拠ベースの脆弱性トリアージ」では、この手法を機械で実行可能な指示としてまとめたステアリングファイルについて説明します。ステアリングファイルには、信頼度の計算式、インフラストラクチャコントロールの乗数、ハルシネーションによる検出結果がエンジニアに届くのを防ぐのに役立つ検証ゲートが含まれます。適切に作成された指示があれば厳密で証拠に基づいた評価を行うモデルでも、そうした指示がなければ、重大度を過大に評価したり、存在しない攻撃チェーンを作り出したりする可能性があります。能力を判断力へと変えるのは、設定なのです。

脆弱性が公開されてから悪用されるまでの期間は短くなっています。開発ワークフローに自動検出を組み込むことは、チームがそのスピードに遅れずに対応するのに役立ちます。このパイプラインは試行錯誤を重ねて構築したものです。その過程で経験した失敗の一部を避けられるよう、ここで共有します。

この記事で紹介したサービスの詳細については、AWS Lambda、AWS WAF、AWS CloudFormation のドキュメントを参照してください。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。