この記事の途中に、以下の記事の引用を含んでいます。
Hacking with AI SASTs: An Overview of ‘AI Security Engineers’ / ‘LLM Security S
登場：「AIによる脆弱性診断」本当に現場で使えるのか？
AI、特に大規模言語モデル（LLM）がセキュリティ分野に本格的に進出しつつある現状。
しかし、現実には「AIによる自動脆弱性診断ツール（AI SAST）」が実務の中でどこまで活躍できるのか、半信半疑な人も多いのではないでしょうか。
今回紹介するHacking with AI SASTs: An Overview of ‘AI Security Engineers’ / ‘LLM Security Sは、著者自身が複数のAIネイティブなセキュリティ診断ツールを自ら手を動かして検証した結果と、現状の課題・実用性・今後のセキュリティエンジニア像に踏み込んでいる非常に示唆に富んだレビューです。
一体何ができて、何ができないのか。そして、今後人間のペンテスターやセキュリティチームの仕事はどう変わるのか？
この記事をベースに、解説と考察を加えていきます。
AI SASTは従来型診断を一変させうるか？ ― 主張と印象的な例
まず、記事の印象的な主張を引用します。
“My main takeaway from this whole journey is that these systems are extremely cool, are amazing at finding real vulnerabilities (and bugs!) in extremely complex code, and these types of systems are probably going to be the most influential, if not interesting and effective technology for finding vulnerabilities in the near future, of the kind that has not been seen since around 2013 when fuzzing became popular again with afl-fuzz.”
(出典：Hacking with AI SASTs: An Overview of ‘AI Security Engineers’ / ‘LLM Security S)
この一文から読み取れるのは、「AI SASTは従来の静的解析と一線を画す実用レベルに到達しつつある」という力強い評価です。
とくに膨大かつ複雑なコードにも真正面から挑み、しかも「ビジネスロジックの不整合」や「開発者の意図とのミスマッチ」といった従来型診断では気付きにくい、より本質的なバグ検出力に注目しています。
また、著者はさまざまなAI SAST製品を実際に触った上で、
“Multiple AI-native SASTs are already on the market, ready to use today.
They work extremely well. They find real vulnerabilities and logic bugs in minutes.
They can “think”/”reason” about business logic issues.
They can match developer intent with actual code.
They aren’t based on static rule-sets and queries.
They have low false positive rates.
They’re cheap (for now).”
(同上)
とし、明確に「既に実務投入できる水準」と断言しています。
【解説】AI SASTの中身 ― 従来型SASTとの決定的な違い
1. LLM搭載SASTの基本アーキテクチャ
AI SASTのコアはLLM（大規模言語モデル）です。
従来のSAST（Static Application Security Testing）は「静的なルールセット（例えば、正規表現などによる検知）」に依存していました。
一方LLMベースのSASTは、ソースコード全体を取り込み（AST生成・インデックス化）、ファイルや関数単位で意味を解釈し、ビジネスロジック・コメント・仕様書まで文脈として理解しながら「何が問題か」を推論します。
また二次的なエンジンやルールベースのスキャナ（例えばopengrepやCodeQL）などとも連携し、幅広い異常値パターンを拾い上げ、LLMがそれを精査する流れです。
2. 検知能力 ― 本物のペンテスター顔負け
最大の特徴は、型にはまったルールに縛られず、むしろ「発想の飛躍」までやってのける点です。
本記事も
“It’s like having a schizophrenic auditor that is able to find connections between things that may or may not be there, and find issues that you would never have even thought of in the first place when auditing code.”
(同上)
と形容するほど。
たとえば“想定外の使い方でバグが露呈する経路”や、“文書化されていない仕様ミス”など、今までは優秀な人間が何日もかけないと見つからなかった複雑なミスを“自動で”炙り出せる可能性があります。
3. 「ビジネスロジックの矛盾」や「意図 vs 実装 の乖離」も浮き彫りに
従来のSASTは、入力値の検証漏れや危険なAPI利用など、比較的典型的な“技術的脆弱性”が守備範囲でした。
しかしAI SASTは、「このプログラムは設計意図通り動いているだろうか？」という、“設計ミス”や“人的コミュニケーション不全”に起因する根本バグにも手を伸ばします。
著者がZeroPathで体験した実例―「RFCに違反しているSMTPコマンドの大文字小文字チェック」や、「意図通りのバッファサイズが使われていない初期化処理」―などは、その典型例です。
4. 運用性・開発者体験
こうしたAI SAST製品は、CI/CDパイプラインとの連携や自動PR作成、「テイント分析」や「関数間フロー分析」など、従来製品の長所も網羅しつつ、レポーティングや自動修正案提示、ポリシー（ルール）を自然言語でカスタマイズできる柔軟さも備えています。
また「リポジトリ内ポリシー定義（Policy as Code）」を推進する傾向も強まっています。
5. 有力製品と検出実績
著者が高く評価したZeroPathは、OSSや商用ソフトの実コードに適用し、sudo, curl, Next.js, libwebm, Avahiなど主要OSSでも「実在する本物のバグ・脆弱性」を数百件検知。
単なる脆弱性検知だけでなく、バグの自動発見・設計ミスの追及・ビジネスロジック診断まで幅広く機能していると指摘します。
実用上の課題・限界点と評価
1. 発見されること/されないこと
AI SASTは“万能”ではありません。
一部の難解なバグ（たとえば「入力次第でループが終わらない無限ループバグ」は、著者がルールを明示しても発見できなかった）や、複雑な依存関係・微妙なフローの抜け穴は、人間と同様に見逃すことがあります。
“None of the products were able to find the image-size infinite loop.”
(引用元記事より)
これは現時点でのAI SASTの“限界”を示すと同時に、製品間での検出精度やアルゴリズムの違い、言語ごとの強み・弱みを如実に物語る一例でしょう。
2. 偽陽性・偽陰性と現場運用
偽陽性（False Positive）は、従来のSASTに比べれば著しく減ったものの、“ゼロ”ではありません。
とくにC/C++のマクロ解釈や複数ファイルにまたがる流れ、テストコードと誤認した誤検出などは製品ごとにばらつきがあります。
一方で著者は
“False positives aren’t the worst thing in the world: they allow us to be informed of fragile code which can be hardened, however some of the false positives were .. really obvious. Result quality really depended on the language, too.”
(同上)
と述べ、技術的なミスや設計の脆さを知るための“警告サイン”として偽陽性を捉えるスタンスも見せています。
3. 値段・導入障壁
意外なメリットとして「現在はまだ安い（だが今後値上げは必至）」点も挙げられており、先行導入の恩恵は十分期待できます。
一方、「情報がネット上で極めて見つけづらい」「SEOや広告戦略が追いついていない」といった、エコシステム・情報流通面での未成熟さも指摘されています。
4. 自動修正（オートフィックス）の限界
多くのAI SASTは自動で修正パッチ（PR）も生成可能ですが、以下のような課題も。
“Patches focused too much on immediate consequences of issues, and generally failed to put the whole application and codepath into perspective, and ‘understand’ the real source of the problem, and where an engineer with a clue would actually solve the problem rather than mitigate it.”
(同上)
つまり、「現象レベルでは直してくれるが、設計全体の根本原因にまで踏み込まず場当たり的になりがち」という実態です。
【考察】AI SASTが職人技を“置き換える”未来は来るか？
いまAI SASTが一気に話題になっている理由は、単に検出精度やスピードだけではありません。
むしろ「今まで超一流の”目”を持った一部の人間だけが発見できたバグや矛盾」を、比較的幅広いレベルのエンジニアに“可視化”させる可能性がある点にインパクトがあります。
1. 人間ペンテスターやセキュリティエンジニアは不要になるのか？
結論から言うと、「完全に不要」にはなりません。
“Will they replace pentesters? Not completely; but they will replace a lot of the work they do…. the talented people will continue to do what they do, and identify holes in a system rather than a simply codebase; the hardest part of hacking is not the hacking or technology; it’s knowing what to hack, and understanding what you can actually do with what you’ve hacked.”
(同上)
つまり、「個別コードのバグ発見」の仕事は大幅自動化可能ですが、「システム全体のコンテキストに即したリスク発見」「仕様上想定されていない攻撃ベクトル構築」「社会的責任をふまえた運用提案」など、本質的な“人間主導”の役割は今後も続くという展望です。
2. 組織での活用方法・運用上の注意点
著者は現実的な運用方法として
- 定期的な全体フルスキャン
- ポリシー活用とカスタムルールで戦略的診断
- PR単位での差分スキャン（高深刻度ならマージブロックなどCI/CD連携）
- エンジニアやレビュー担当による「人の目の最終確認」は必須
- 自動修正コードはあくまでヒントやドキュメントとして使い、責任者判断で導入
―などを推奨しています。
運用負荷を下げつつ、誤検知対応や重大バグ発見の担保を両立する、モダンな利用法の一例として参考になるでしょう。
3. AI SASTへの「仕込み」「脱法」技術も考慮すべき
「検査から意図的に逃れるコード（例：テストファイルや無害ファイルを装う、LLMへのプロンプトインジェクション、難読化など）」についても、既存ルール型SAST同様に完全防御はできません。
今後これら“回避策”競争の激化と、それに対応するAI SAST側の進化が繰り返される構図は十分考えられます。
【まとめ】AI SASTの今 ― 導入の価値と注意点
この記事全体から浮かび上がるのは、「AI SASTはもう机上の空論ではなく、アーリーアダプター向けから現実的な選択肢へと進化しつつある」という事実です。
とくに「実際のソースコードレビューや脆弱性発見作業」の領域においては、既存人材の能力に大きな格差があった部分を補完・平準化し得る強力なIT資産となりつつあります。
その一方で、
- 複雑なバグ、全体設計までに踏み込んだ診断はまだ「人間の目」が必須
- 人間側の知見・システム文脈を入力（ポリシー・ドキュメント連携）すればするほど効果は増す
- 誤検知・検知漏れはゼロではない。リスクマネジメントは変わらず必要
という「冷静な期待値コントロール」が重要だと言えるでしょう。
また、「セキュリティ人材の新たな価値は、“システムに何をチェックさせるか”“設計思想から何を守るか”という“問いの良さ”“設計力”にシフトしていく」ことも、プロフェッショナル人材にとって本質的なメッセージとなっています。
あなたの現場では今、どう使えるか？
- 新規プロジェクトや古いレガシーコードベース、セキュリティレビューに自信がない箇所など、気軽に「まず一度回してみる」ことで得られる発見は多い
- セキュリティチームやペンテスターも「標準装備」として活用し、“人力レビュー”を本来必要な“全体設計やリスク評価”部分に振り向けるのが賢い戦法
- 「修正提案の自動化」は開発効率化へ前向き利用。ただし最終マージ判断は責任者が握るべき
という「地に足のついた活用スタンス」が、今後のセキュリティ開発の新常識といえるかもしれません。
参考元
本記事の検討・引用に含まれる検証、具体的な検出例やレビュー・批評内容についてはHacking with AI SASTs: An Overview of ‘AI Security Engineers’ / ‘LLM Security S を参照しています。
categories:[security]
コメント