AIが書いたコードはSASTが捉えるべきものを変えた

AIコーディングアシスタントが数秒で動作する機能を生成するのを見ていると、ブレークスルーに感じられるかもしれない。コードはコンパイルされ、テストはパスし、プルリクエストはきれいに見える。納期に追われる開発チームにとって、それは進歩のように感じられるかもしれない。

しかし、機能的なコードとセキュアなコードは同じものではない。

AI生成コードはソフトウェアリスクの形を変えた。問題は、大規模言語モデルが「悪い」コードを書くことではない。多くの場合、それらはポリッシュされたコードを書き、フレームワークパターンに従い、要求されたタスクを解決する。問題はより繊細なものである。コードは機能的に正しくても、依然としてセキュアではない、古い、過度の権限を持つ、またはコンテキストが間違っている可能性がある。

その違いは重要である。静的アプリケーションセキュリティテスト（SAST）は、開発者が人間の速度でコードを書き、セキュリティチームが予測可能なリスクパターンをレビューする世界のために作られた。AIは、その方程式の両側を変えた。コードの量は増加し、コミットは小さくなり、セキュリティパターンは今や大規模に生成される可能性がある。

結果は、ソフトウェアチームに新しい質問をもたらした。コードの著者が人間でない場合、SASTは何を捉えるべきか?

動作するコードはもはや強いシグナルではない

数年間、ソフトウェアチームは粗い信頼の階層を使用してきた。コードがコンパイルされ、テストにパスし、ピアレビューに耐えた場合、それはプロダクションに近づく。セキュリティスキャンが追加のレイヤーを提供したが、機能性は最初のゲートであった。

AIコーディングアシスタントは、その階層を混乱させる。なぜなら、それらは特に完成したコードを生成するのが得意だからである。ボイラープレートを推測し、APIを接続し、エラーハンドリングを生成し、リポジトリのスタイルに合う。そうすることで、それらは便利になるが、同時にそのミスを発見するのが難しくなる。

人間のレビュアーは、AI書きの関数を見て、「これは正常に見える」と思うかもしれない。那が正確にリスクである。多くのAI生成の脆弱性は、エキゾチックなものではない。インジェクションフロー、弱い検証、セキュアでないデフォルト、安全でないデシリアライゼーション、ログの問題、古い依存関係の選択などの、よくある問題である。

最近の研究は、この緊張を無視するのが難しくしている。VeracodeのSpring 2026 GenAI Code Security Updateは、例えば、AIコーディングモデルが、シンタックス的に正しいコードを生成するよりも、セキュアなコードを生成するのがはるかに強くなったことを発見した。言い換えれば、AIは動作するソフトウェアを書くのが非常にうまくなっているが、それが信頼できるソフトウェアを書くのが同じくらいうまくなっているわけではない。

古いSASTモデルは人間のボトルネックのために作られた

従来のSASTは、常に難しい仕事をしていた。ソースコードをスキャンし、パターンを既知の弱点にマッピングし、チームに脆弱なコードを出荷する前に警告する。従来の開発サイクルでは、それがすでに摩擦を生み出す。警告が多すぎる、偽陽性が多すぎる、そしてすべてを修復する時間が十分ではない。

AIは、開発における隠れた制約の1つ、人間のタイピングの速度を取り除くことで、それをより困難にしている。

AIアシスタントが1回のセッションでサービス、テストファイル、API統合、設定スニペットを生成できる場合、セキュリティレビューは同じ仮定に頼ることができない。リスクは、1行のコードのミスではない。チームの代わりにモデルが行った小さな決定を含む、数十のファイルにわたる妥当なコードの乗算である。

ここで、現代のSASTツールが進化する必要がある。プルリクエストがほぼ完了した後に、既知の脆弱性シグネチャをスキャンするだけで済まさない。開発ワークフローに近いところで動作し、AIアシストの変更パターンを理解し、チームが無害な自動化とリスクのある自動化を区別するのに役立つ必要がある。

AIはマシンスピードでセキュリティデットを導入する

テクニカルデットは新しいものではない。セキュリティデットは、より危険な従兄弟である。脆弱性、弱い仮定、リスクのあるショートカットがコードベースに残るのは、それらを修復するのが今日修復するのに十分な緊急性がないからである。

AIはこのプロセスを加速することができる。

開発者はアシスタントに「認証を追加する」、「この入力をサニタイズする」、「このエンドポイントをデータベースに接続する」と要求するかもしれない。モデルは通常、答えを生成する。しかし、プロンプトに正しいセキュリティ制約が含まれていない場合、答えは古い慣行、不完全な検証、またはセキュアでないデフォルトに頼る可能性がある。さらに悪いことに、それはカジュアルなレビューにパスするのに十分なものになる可能性がある。

ここで、SASTが認識する必要があるAI固有のパターンが数多くある。

• セキュアなように見えるボイラープレート：AIは、認証チェックや出力エンコードなどの重要な制御を欠いた、ベストプラクティスに似たコードを生成することがある。
• 古い依存関係の仮定：モデルは、トレーニングデータで一般的だったパターンに基づいて、ライブラリ、バージョン、またはAPIを提案する可能性があるが、それらはもはや推奨されていない可能性がある。
• コンテキストのない修正：AIは、ローカルの症状を修正するが、アプリケーションのより広いフローを理解しない可能性がある。そうすると、他の場所にセキュリティギャップが生じる可能性がある。
• 繰り返される脆弱なテンプレート：同じプロンプトが複数のリポジトリで同じ欠陥のパターンを生成する場合、1つの弱点が静かに組織全体に広がる可能性がある。

これは、単に悪いコードを見つけることではなく、コードが十分なコンテキストなしに生成されたかどうかを検出することについてである。

SASTはシンタックスだけでなく意図を理解する必要がある

次の世代のSASTは、単純なパターンマッチングを超える必要がある。既知の脆弱性パターンはまだ重要であり、基本的な欠陥は自動的に捉えられるべきである。ただし、AI生成コードは、シンタックスのみで全体の話を語ることは稀であるため、基準を高める。

顧客レコードを取得するエンドポイントを考えてみよう。コードはパラメータ化されたクエリを使用し、エラーを正しく処理し、標準のインジェクションチェックにパスする可能性がある。ただし、テナント分離を強制するか。現在のユーザーが要求されたレコードにアクセスすることを許可するか。機密データをログするか。

そのような変更は、プライバシーに関する疑問も生じさせる。AI生成のロジックがアプリケーションが保存、ログ、または公開するものを変更する場合、チームはセキュリティレビューの一環としてそのアプリデータ収集の動作を理解する必要がある。

これらは、シンタックス上の問題ではない。意図の問題である。

SASTは、ビジネスロジック、データフロー、フレームワークの規約、変更とアプリケーションの残りの関係について、より多くの認識を必要とする。目標は、SASTをマーケティング目的のために「AIパワード」にすることではない。目標は、AIが間違える可能性のある種類のミスを捉えるのに十分なコンテキストを理解できるようにすることである。

開発者はセキュリティを学ぶ必要があるが、違った方法で

より良いツールは役立つが、人間の責任を除去することはない。AIコーディングアシスタントは開発者をより生産的にするが、同時にチームが完全に理解していないコードを受け入れることも容易にする。

それが、トレーニングの課題を生み出す。従来の年次セキュリティトレーニングは遅すぎるし、日常の仕事から切り離されている。開発者は、決定を下すときに、短い、実用的で、近い距離でレッスンを受ける必要がある。これが、マイクロラーニングが関連する場所である。小さな、焦点を当てた学習の瞬間が、エンジニアを仕事の流れから数時間引き離すことなく、セキュアなコーディングの習慣を強化することができる。

AIコーディング時代の最良のセキュリティ教育は、教室のように見えなくなる。プルリクエストの中でタイムリーな説明のように見え、エンジニアを仕事の流れから引き離すことなく、セキュアなコーディングの習慣を強化するIDEの警告のように見える。

レビュープロセスは変化する必要がある

コードレビューは、次の質問に答えるために使用されていた。コードは読みやすいのか。問題を解決するのか。何かを壊すのか。

AI書きのコードは新しい質問を追加する。プロンプトはセキュリティに気を配っていたか。モデルは依存関係を導入したか。モデルはリポジトリの他の場所からパターンをコピーしたが、そのパターンが存在する理由を理解していなかったか。開発者はロジックを検証したか、または出力のみを検証したか。

これは、AIアシストのコミットごとに法医学的調査が必要であることを意味しない。ただし、チームは、AI生成の変更が高リスクであるかどうかを判断するための簡単な方法が必要である。認証、承認、暗号化、支払いフロー、ファイルアップロード、データベースアクセス、ログ、インフラストラクチャ構成は、UIコピーまたはテストスキャフォールディングよりもより注意深くレビューされるべきである。

まとめ

AIはSASTを無関係にしていない。むしろ、SASTをより重要にしている。

コード生成が開発環境に深く埋め込まれるにつれ、不十分なコードが人間の手によってゆっくり侵入するという古い仮定は、もはや当てはまらない。AIは、有用なソフトウェアを生成できるが、同時に弱いパターン、古い仮定、コンテキストのない修正を、従来のレビュープロセスが吸収できるよりも速く拡大させることもできる。

勝者は、AIコーディングツールを禁止するチームではなくなり、セキュリティワークフローを新しい現実に合わせて再設計するチームになる。コードは瞬時に生成できるが、信頼はまだ獲得する必要がある。

SASTは、シンタックスレベルのミスだけでなく、意図の欠如、安全でないコンテキスト、繰り返されるAIパターン、セキュリティデットを捉える必要がある。