本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第8弾（最終回）として、脆弱性診断について解説する記事です。
脆弱性診断はリリース前の儀式ではなく継続運用です。年1回のペネトレ時代は終わり、現代はCI/CDに組み込んでpush毎に自動検査が標準です。本記事ではSAST／DAST／SCA／IAST／ペネトレの違い、CI/CD組み込み、AI生成コードの穴対策まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』・『安全なWebアプリケーションの作り方 第2版』も参考にしてみてください。
この記事の結論
- Dependabotを初日から有効化する
- SASTをCIに組み込み、DASTをステージングで定期実行する
- SBOMを自動生成し、対応SLA（期限）を定義する
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも脆弱性診断とは何か
健康診断を思い浮かべてください。自覚症状がなくても年に1回は血液検査やレントゲンを受け、病気の兆候を早期に発見します。「体調が良いから大丈夫」と検査を怠ると、気づいた時には手遅れになりかねません。
脆弱性診断はシステムの健康診断です。ソースコード・依存ライブラリ・稼働中のアプリケーション・ネットワーク設定などを自動ツールや専門家の目で検査し、攻撃者に悪用される前に弱点を見つけて直す活動です。
もし脆弱性診断がなければ、既知の脆弱性が放置されたまま本番で稼働し続けます。攻撃者は公開された脆弱性データベースを見て数時間以内に攻撃を自動化するため、知らなかったでは済みません。
なぜ脆弱性診断が必要か
第一に、AIが書くコードに穴が混ざるからです。AI駆動開発で生産性は上がりましたが、AIが書くコードはセキュリティ観点で甘いことも多く、人力レビューだけでは追いつきません。自動診断を組み込んで機械に機械を見張らせるのが現代の前提です。
第二に、依存ライブラリの脆弱性が急増しているからです。現代のアプリは数百〜数千のライブラリに依存しており、Log4Shell（2021年12月のLog4jゼロデイ）のような事件は明日も起こり得ます。自分のコードが完璧でも依存先の穴で刺されます。
第三に、コンプライアンスです。SOC 2・ISMS・PCI DSSなどの認証では継続的な脆弱性管理が必須要件で、実施記録（いつ・何を検査し・どう対応したか）まで監査対象になります。
主要な診断手法 ― 組み合わせて使うのが前提
脆弱性診断は「何を・どう調べるか」で複数の手法に分かれます。1つで全部をカバーできるものは存在せず、組み合わせて使うのが前提です。
| 手法 | 調べる対象 | タイミング |
|---|---|---|
| SAST | ソースコード（静的） | コミット時・CI |
| DAST | 動いているアプリ（動的） | ステージング・週次 |
| SCA | 依存ライブラリ | コミット時・毎日 |
| IAST / RASP | 実行中アプリの内部 | テスト時 / 本番 |
| ペネトレーションテスト | 総合（人手） | 年1〜2回・リリース前 |
SAST — 静的解析でコードの穴を探す
ソースコードを読み取って、動かさずに脆弱性を探す手法です。SQLインジェクション・XSS・ハードコードされた秘密情報など、コードパターンから検知できる穴が対象で、CIでpush毎に実行してPRにコメントさせる使い方が現代の標準です。コミット時点で検知でき開発者がすぐ直せる反面、誤検知（false positive）が多く、実行時に初めて出る問題や設定ミスは見えません。主役はSemgrep（OSS・軽量）とGitHub Code Scanning（CodeQL）。その他、Snyk Code・SonarQube等があります。誤検知は出ますが、重要な穴を1つ防げれば十分ペイする「とりあえず入れる」価値が高い領域です。
DAST — 動いているアプリに攻撃を試す
実際に動いているアプリに攻撃リクエストを送って挙動を見る手法です。言語非依存で、SASTでは見えない設定ミス起因の穴も実環境で検知できるのが強み。反面、スキャン時間が長く、テスト環境の用意やログイン必須ページの扱いに手間がかかります。主役はOSSのOWASP ZAPと定番のBurp Suite。その他、StackHawk（CI統合が得意）・AWS Inspector等があります。基本はステージング環境向きで、本番への実行は必ず事前承認を取って慎重に行います。
SCA — 依存ライブラリの脆弱性を見張る
使っている依存ライブラリに既知の脆弱性（CVE）がないかを調べる手法です。2024年以降の脆弱性の大半はライブラリ由来で、自作コードよりSCAの方がROIが高いと言えるほど重要な領域になりました。主役はDependabot──GitHub標準で、設定ファイル1つで有効化でき、自動修正PRまで出してくれます。その他、Renovate・Snyk Open Source・Trivy等。最優先で導入すべき診断です。
Equifax 2017年事件は、Apache Struts 2のCVE-2017-5638へのパッチを2か月放置した結果、約1.47億人分の個人情報が流出し和解金約7億ドルに達しました。自分のコードが1行も脆弱でなくても、借り物の部品一つで会社が傾くという現実を示し、SCAの価値を決定づけた事件です。
IAST・RASP・ペネトレーションテスト
IASTはテスト実行中にアプリ内部のエージェントが動作を監視する手法で、SASTとDASTの長所を合わせ持ちます。RASPは本番で攻撃を検知して自動ブロックするWAFの進化形です。どちらもエージェント組み込みが必要で導入コストは高めですが、大企業の本格運用では採用が広がっています。
ペネトレーションテストは専門家が攻撃者視点で実際に攻撃を試みる総合診断で、自動ツールでは検知できない複合的な穴（業務ロジックの欠陥・認可バグ・設計上の問題）を発見できるのが最大の価値です。費用は外部ブラックボックスで50〜200万円、認証済み内部診断で100〜500万円、レッドチーム演習で500万円〜が相場（2026年4月時点）。リリース前・大規模改修時・年1回の定期実施が目安で、業者選定ではOSCP等の資格保持者が在籍するかが判断材料になります。
SBOMとサプライチェーン
SBOMは、アプリに含まれるすべての依存コンポーネントの一覧です。Log4Shellのような事件の際に「自社に影響があるか」を即座に特定でき、ライセンス違反（GPL混入等）の把握にも使えます。2024年以降、米国政府調達などで必須化が進み、SBOMの提出が取引条件になりつつある──単なる技術要件ではなく商流の要件に格上げされた概念です。ビルドパイプラインの信頼性をレベル分けするSLSAと合わせて、サプライチェーンセキュリティの両輪になっています。
3つのシナリオで考える
個人開発・スタートアップの場合
DependabotにGitHub Code Scanning（CodeQLの無料枠）、Semgrepを揃えるだけで最低限の検知は揃いますし、コストはゼロで済んでしまいます。Dependabotだけは初日から無条件で入れるのが現代の常識だと思ってください。ペネトレは重要顧客から求められた時点で実施すれば良く、SBOMも npm audit や pip-audit で十分です。
中小SaaS企業の場合
SnykかGitHub Advanced SecurityでSASTとSCAを一本化して、StackHawkでDAST、年1回のペネトレという体制に進みます。SOC 2対応では脆弱性管理の記録を残す継続運用が必須になってきます。SBOMはCycloneDX形式で顧客に提出するのが定番ですね。体制面では専任のセキュリティ担当を1名置いて、開発者がセキュリティの1次責任を持つDevSecOpsの発想で回していきます。
大企業・金融の場合
商用SAST（CheckmarxやVeracode）にDAST（Burp Pro）、IASTとRASPまで含めたフルセットに、四半期ペネトレと年1回のレッドチーム演習を加える体制になります。SBOMは全ビルドで自動生成して、SLSA Level 3以上を目指します。CSIRTとSOCを常設する世界です。
対応SLA ― 見つけた後のスピードで勝負が決まる
脆弱性診断は見つけた後の対応スピードで勝負が決まります。以下が業界標準のSLAです。
| 重要度 | 対応期限 | 実務の動き |
|---|---|---|
| Critical（RCE等） | 72時間以内 | 即時通知、全作業中断して対応 |
| High | 1週間以内 | 次のスプリントで対応 |
| Medium | 1ヶ月以内 | 計画的に対応 |
| Low | 3ヶ月以内 | 定期メンテで対応 |
組み込みタイミングは、SCA（Dependabot）は初日から、SASTはPR時のCI、DASTはステージングで週次、SBOMは全ビルドで自動生成、ペネトレは年1回以上（規制業種は四半期）が実務の鉄板です。Criticalの72時間以内は鉄則──Equifaxのようにパッチを2か月放置すると、企業存続レベルの損害になります。
AI判断軸 ― AIが書き、AIが見張る時代へ
AI生成コードの脆弱性検出にSASTが必須になる理由
AIが書くコード量が増えると、人間のレビューだけでは脆弱性を見落とす確率が上がります。特にAIは「動くこと」を優先するため、入力値のバリデーション不足やSQLのパラメータバインド省略が混入しやすいです。
Semgrep・CodeQLのようなSASTツールをCIに組み込み、すべてのプッシュで自動チェックする運用は、AI活用を前提にした開発では最低ラインです。SASTが検出した問題をAIに修正させ、再度SASTで確認する自動修正ループも現実的になっています。
SBOMがAI生成コードの依存関係を可視化する
AIにコード生成を任せると、人間が意識しないライブラリへの依存が追加されることがあります。AIが「この処理にはlodashが便利」と判断して npm install を指示するようなケースです。
SBOMを自動生成する仕組み（CycloneDX・Syft等）があれば、新しく追加された依存の脆弱性を即座に検知できます。AI時代は依存関係の変更頻度が上がるため、SBOM + SCA（Dependabot / Snyk）のリアルタイム監視がより重要になります。
やってはいけないこと
診断運用で事故る典型を、特に危険な6つに絞ります。どれも「入れた」だけで「運用できていない」構造を持ちます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| Dependabotを有効化してアラート放置 | 500件並んで壁紙化し本物のCriticalも埋もれる → SLA + 担当ローテーションを決める |
| 誤検知が多いからとSASTを無効化 | 重要な検知ごと失う本末転倒 → ルールをチューニングする |
| ペネトレ年1回だけで継続診断なし | 依存ライブラリの穴は毎日生まれる → CI組込の毎日検査に切り替える |
| WAF頼みで根本対策をしない | WAFは検知できた攻撃しか防げない → コード側でパラメータ化クエリ等の根本対策 |
| SBOMを生成しない | Log4Shell級の事件で「自社に影響があるか分からない」事態に → 全ビルドで自動生成する |
| 脆弱性対応をセキュリティチーム任せ | スピードが出ず放置が積み上がる → DevSecOpsで開発者が1次責任を持つ |
なお「有償ツールでなければ意味がない」と導入を先送りするのも誤りです。Dependabot・Semgrep・OWASP ZAPのOSS組み合わせで7割はカバーでき、まず無料枠で始めるのが現実的です。
筆者メモ — 「パッチ遅れ」と「ゼロデイ」の両方が致命傷になった事例
Equifax 2017年情報流出（Apache Struts 2のCVE-2017-5638パッチを2か月放置 → 1.47億人分流出 → 和解金約7億ドル）は、SCAの価値を決定づけた事件です（詳細は付録「重大インシデント事例集」）。
Log4Shell 2021年（Log4jのCVE-2021-44228）では世界中のJava製アプリが一夜にしてゼロデイに晒され、SBOMがないと自社に影響があるかすら分からない事態が多発。サプライチェーンセキュリティ（SBOM / SLSA）が契約条件に組み込まれるきっかけになりました。
どちらも「依存先の穴」が致命傷で、自社コードのSAST / DASTだけでは守り切れない、という教訓を残しました。毎日更新される脆弱性を、毎日検査するのが現代の最低ラインです。人間が年1回まとめて見る運用は、もう成立しない時代に入ったと言えます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- SCA導入（Dependabot / Renovate / Snyk）
- SAST導入（Semgrep / CodeQL / SonarQube）
- DAST導入（OWASP ZAP / StackHawk）
- SBOM生成の自動化（CycloneDX / Syft）
- ペネトレーションテストの頻度と範囲
- 脆弱性対応SLA（Criticalは何日以内か）
- AIセキュリティ検査（LLM利用がある場合）
この記事に関連する記事
まとめ
本記事は脆弱性診断について、SAST・DAST・SCA・IAST・ペネトレ・SBOMの使い分け・対応SLA・AI時代の新しい攻撃面まで含めて解説しました。如何だったでしょうか。
Dependabotを初日から有効化、CIにSAST統合、ステージングにDAST週次実行、SBOM自動生成とSLA定義。これが2026年の脆弱性診断の現実解です。
そしてこれが「セキュリティアーキテクチャ」カテゴリの最終回でした。次回からは新しいカテゴリ（開発・運用設計）の解説に入ります。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は OWASP Top Ten も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（59/95）