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