DevSecOpsで自動診断が変えるLLM時代の防御

手作業のレビューが追いつかない開発速度の現実

あなたの会社でも、リリース前の最終確認が「人の目で何とかする」状態になっていないでしょうか。開発チームは毎週のようにコードを更新し、SaaSも社内サービスも止まらず改善されます。その一方で、手作業の脆弱性確認は、速度も再現性も足りません。ここにDevSecOpsの本当の難しさがあります。開発、セキュリティ、運用を一つの流れで回すには、release dayの前に自動で安全性を確かめる仕組みが必要です。私はこの記事を読んで、DevSecOpsの主戦場が「人手によるチェック」から「工程そのものの設計」へ移ったと解釈しました。
Verizonの2025 Data Breach Investigations Reportでは、脆弱性の悪用が初期侵入の20%を占め、前回報告から34%増えました。20%という数字は、攻撃者が正面突破ではなく、既知の穴を狙う比率が高いことを示します。34%増は、脆弱性対応の遅れがそのまま攻撃機会の拡大につながった事実です。さらにCredential abuseが22%という点も重要で、守る対象がコードだけでは足りず、認証や権限設定まで含めて見直す必要があります。現場では「脆弱性対応」と「ID管理」を別部署で処理している担当者も多いはずです。私はそこが、被害が長引く最大のボトルネックだと見ています。

SAST、DAST、依存関係、シークレット検出をどう組み合わせるか

自動セキュリティテストの価値は、単に「便利」だからではありません。見つける対象が異なる複数のテストを、開発パイプライン内で分業させる点にあります。Static Application Security Testing、つまりSASTは、実行前のソースコードを解析して、不適切な入力処理や危険な関数利用を拾い上げます。コードの行単位で指摘できるので、修正箇所が明確です。逆に、Dynamic Application Security Testing、つまりDASTは、動いているアプリに外側からリクエストを送り、認可不備やリダイレクトの欠陥を探します。コードだけでは見えない挙動を確認できるため、Webサービスでは欠かせません。
記事本文では、XBOWのようなサービスが、アプリの攻撃面をマッピングし、実際にどの経路で侵入できるかまで検証すると紹介されています。私はここをかなり重く受け止めました。なぜなら、セキュリティ部門が欲しいのは「危なそう」という曖昧なアラートではなく、「本当に到達可能だった」という証拠だからです。証拠があると、開発チームへの引き継ぎが早くなり、チケットの往復も減ります。
Software Composition Analysis、いわゆるSCAは、外部ライブラリやOSSの脆弱性を洗います。現代のアプリは自前コードだけでは成り立ちません。CISAのKnown Exploited Vulnerabilities catalogを参照して優先度を決める手法は、実務でも有効です。カタログに載るということは、攻撃者が実際に使った脆弱性だという意味だからです。さらにSecret scanningは、APIキーやトークンの漏えいを見つけます。公開リポジトリや共有設定に秘密情報が残る事故は、1件でも致命傷になります。Infrastructure-as-Codeの診断も外せません。クラウド設定ファイルの中に、公開ストレージや弱い権限が紛れ込みやすいからです。
要するに、SASTは「書いたコード」、DASTは「動くアプリ」、SCAは「借りたコード」、Secret scanningは「置いてはいけない鍵」を見る仕組みです。この4つを分けて回して初めて、DevSecOpsは現実的な速度で動きます。OWASPがセキュリティをパイプラインに組み込むべきだと繰り返す理由も、ここにあります。私の見方では、単発の診断導入では足りず、CI/CDの標準工程に組み込んだ時点で初めて投資効果が出ます。

日本企業の導入で先に決めるべき運用ルール

日本企業にとっての論点は、ツール選定そのものではありません。どの診断を、どの段階で、誰が止めるのかを先に決めることです。たとえばSASTをPull Requestの時点で回し、DASTはステージング環境だけに限定し、Secret scanningは全ブランチで常時有効にする、といった分担が必要です。これを曖昧にすると、アラートだけが増えて誰も責任を持たない状態になります。そうなると、現場はすぐに自動診断を信用しなくなります。
実務で見るべき数字は、検出件数よりも「修正までの時間」です。1日に100件の警告が出ても、優先順位がつかなければ意味がありません。逆に、5件でも本番直結の穴を止められるなら、投資価値は高いです。私はここで、セキュリティを「件数管理」で扱う癖を改めるべきだと考えます。開発責任者は、重大度スコアよりも攻撃経路の有無を見なければなりません。
AIを使う診断機能も、日本では慎重に扱う必要があります。AIは探索範囲を広げ、修正案の下書きを作る一方で、誤検知や過剰検知も生みます。だからこそ、人が判断するラインを明確にする設計が必要です。現場感で言えば、セキュリティ担当が全件レビューする運用はすぐに破綻します。開発者が一次対応し、セキュリティは高リスクだけを精査する形が最も現実的です。これは日本の多くの開発組織にそのまま当てはまります。

AI診断と人の判断を分ける設計が標準になる流れ

これからのDevSecOpsでは、AIが診断の入口を広げ、人が本当に危ない箇所だけを絞り込む構図が定着します。私はこの流れを、セキュリティ運用の省力化ではなく、意思決定の再設計だと見ています。アラートを増やすほど強くなるのではなく、攻撃可能性を示す証拠を増やすほど強くなる、という方向です。自動テストはその入口を担います。