本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第8弾（最終回）として、脆弱性診断について解説する記事です。
脆弱性診断はリリース前の儀式ではなく継続運用。年1回のペネトレ時代は終わり、現代は CI/CD に組み込んでpush毎に自動検査が標準です。本記事では SAST／DAST／SCA／IAST／ペネトレの違い、CI/CD組み込み、AI 生成コードの穴対策まで解説します。
このカテゴリの他の記事
なぜ脆弱性診断が必要か
AIが書くコードに穴が混ざる
AI 駆動開発で生産性は上がりましたが、AI が書くコードはセキュリティ観点で甘いことも多く、人力レビューだけでは追いつきません。自動診断を組み込んで機械に機械を見張らせるのが現代の前提です。
依存ライブラリの脆弱性が急増
現代のアプリは数百〜数千のライブラリに依存しています。Log4Shell（2021年12月の Log4j ゼロデイ）のような事件は明日も起こり得て、自分のコードが完璧でも依存先の穴で刺されます。
コンプライアンスで要求される
SOC 2・ISMS・PCI DSS などの認証では、継続的な脆弱性管理が必須要件です。形だけでなく、実施記録（いつ・何を検査し・どう対応したか）まで監査対象になります。
主要な診断手法
脆弱性診断は「何を・どう調べるか」で複数の手法に分かれます。1つで全部をカバーできるものは存在せず、組み合わせて使うのが前提です。
flowchart LR
DEV[コミット] --> SAST[SAST<br/>ソース静的解析]
DEV --> SCA[SCA<br/>依存ライブラリ脆弱性]
SAST --> CI[CI/CDパイプライン]
SCA --> CI
CI --> STG[ステージング]
STG --> DAST[DAST<br/>動的攻撃シミュレーション]
STG --> IAST[IAST<br/>実行中の内部監視]
DAST --> PROD[本番リリース]
IAST --> PROD
PROD --> PEN[ペネトレ<br/>年1-2回]
PROD --> BB[バグバウンティ<br/>継続的]
classDef dev fill:#fef3c7,stroke:#d97706;
classDef ci fill:#dbeafe,stroke:#2563eb;
classDef stg fill:#fae8ff,stroke:#a21caf;
classDef prod fill:#dcfce7,stroke:#16a34a;
class DEV,SAST,SCA dev;
class CI,STG,DAST,IAST ci;
class PROD,PEN,BB prod;| 手法 | 調べる対象 | タイミング |
|---|---|---|
| SAST | ソースコード（静的） | コミット時・CI |
| DAST | 動いているアプリ（動的） | ステージング・本番 |
| SCA | 依存ライブラリ | コミット時・毎日 |
| IAST | 実行中アプリの内部 | テスト実行時 |
| ペネトレーションテスト | 総合（人手） | 年1〜2回・リリース前 |
| バグバウンティ | 外部ハンター | 継続 |
SAST — 静的解析でコードの穴を探す
SAST（Static Application Security Testing＝静的アプリケーションセキュリティテスト）はソースコードを読み取って、動かさずに脆弱性を探す手法です。SQL インジェクション・XSS（Cross-Site Scripting＝クロスサイトスクリプティング）・ハードコードされた秘密情報など、コードパターンから検知できる穴が対象になります。CI で push 毎に実行し、PR にコメントする使い方が現代の標準です。
| メリット | デメリット |
|---|---|
| コミット時点で検知できる | 誤検知（false positive）が多い |
| コード全体を網羅 | 実行時に初めて出る問題は見えない |
| 開発者がすぐ直せる | 言語・フレームワーク依存 |
| 学習コストが低い | 設定ミスは検知できない |
代表的なツールは Semgrep・Snyk Code・SonarQube・GitHub Code Scanning（CodeQL）。
「とりあえず入れる」価値が高い領域です。誤検知は出ますが、重要な穴を1つ防げれば十分ペイします。
DAST — 動いているアプリに攻撃を試す
DAST（Dynamic Application Security Testing＝動的アプリケーションセキュリティテスト）は実際に動いているアプリに対して、攻撃リクエストを送って挙動を見る手法です。ステージング環境に対して定期実行するのが一般的で、実際の環境での挙動を確認できるのが強みです。
| メリット | デメリット |
|---|---|
| 実環境での穴を検知 | 網羅性がやや低い |
| 設定ミスも見つけられる | スキャン時間が長い |
| 言語非依存 | テスト環境が必要 |
| ブラックボックス可 | ログインが必要なページの扱いが面倒 |
代表的なツールは OWASP ZAP・Burp Suite・StackHawk・AWS Inspector。
DAST はステージング環境向き。本番への実行は慎重に、そして必ず事前承認を取って行います。
SCA — 依存ライブラリの脆弱性を見張る
SCA（Software Composition Analysis＝ソフトウェア構成分析）は、使っている依存ライブラリに既知の脆弱性（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（Interactive Application Security Testing）は、テスト実行中にアプリ内部のエージェントが動作を監視する手法で、SAST と DAST の長所を合わせ持ちます。RASP（Runtime Application Self-Protection＝実行時アプリ自己防衛）は本番で動作し、攻撃を検知して自動ブロックする仕組みで、WAF（Web Application Firewall）の進化形のような位置づけです。
| 手法 | 用途 | 導入難易度 |
|---|---|---|
| IAST | テスト時の精密検出 | 中（エージェント組込） |
| RASP | 本番での能動防御 | 高（パフォーマンス影響） |
どちらもエージェントをアプリに組み込む必要があり、導入コストは高めですが、大企業の本格運用では採用が広がっています。
ペネトレーションテスト — 攻撃者視点の総合診断
専門家が攻撃者視点で実際に攻撃を試みる総合診断です。自動ツールでは検知できない複合的な穴（業務ロジックの欠陥・認可バグ・設計上の問題）を発見できるのが最大の価値で、リリース前・大規模改修時・年1回の定期実施が相場です。
| タイプ | 内容 | 費用感 |
|---|---|---|
| 外部ブラックボックス | 公開面からの攻撃 | 50〜200万円 |
| 内部（認証済） | ログイン後の攻撃 | 100〜500万円 |
| 赤チーム（レッドチーム） | 組織ごと試す総合演習 | 500万円〜 |
| ソース付きホワイトボックス | コード開示で徹底検査 | 300万円〜 |
業者選定では PCI QSA（PCI 認定セキュリティ審査員）・OSCP（Offensive Security Certified Professional）保持者が在籍するかが目安になります。
SBOMとサプライチェーン
SBOM（Software Bill of Materials＝ソフトウェア部品表）は、アプリに含まれるすべての依存コンポーネントの一覧です。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（Computer Security Incident Response Team）・SOC（Security Operations Center）を常設する体制です。
よくある勘違い
「リリース前に1回やればOK」
依存ライブラリは日々更新され、穴は毎日生まれます。継続診断が前提です。
「SASTがあればDASTは不要」
SAST はコードの穴、DAST は設定の穴を見ます。役割が違うので、両方必要です。
「WAFがあれば脆弱性診断は不要」
WAF は検知できた攻撃しか防げません。根本的な穴は塞がないので、保険としての WAF と、穴そのものを塞ぐ診断は別物です。
「false positiveが多いから無効化する」
ルールを適切にチューニングするのが正解で、無効化は本末転倒です。Dependabot を有効化した初日にアラートが500件以上並び、誰も対応せず1年経って通知が壁紙と化す状態になっていた、という話はよく聞きます。導入した瞬間にSLAと担当ローテーションを決めないと、どんな良いツールも単なるノイズになる、という教訓です。
「有償ツールでなければ意味がない」
Dependabot・Semgrep・OWASP ZAP の OSS 組合せで7割はカバーできます。まずは無料枠で始めて、回る体制ができてから有償に上げる順番が現実的です。
脆弱性対応SLA・診断の段階別実務表
脆弱性診断は見つけた後の対応スピードで勝負が決まります。以下が業界標準の SLA（Service Level Agreement＝サービス品質保証）です。
| 重要度 | 対応期限 | 通知方法 | 実務の動き |
|---|---|---|---|
| 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の警告を無視 | 既知の脆弱性を本番に持ち出す |
2017年9月の Equifax 情報流出（Apache Struts 2 CVE-2017-5638 パッチを2か月放置、1.47億人分流出、和解金約7億ドル）、2021年12月の Log4Shell（世界中の Java アプリが一夜にしてゼロデイ、SBOM なしで自社影響が不明な企業続出）──「依存先の穴」が致命傷となる事例は繰り返されています。
脆弱性診断はCI/CDに組み込んで毎日検査する運用が前提。年1回のペネトレだけでは穴は塞げません。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、脆弱性診断はAIが書いたコードをAIが検査するという新しい循環に入ります。CodeQL・Semgrep は既に AI ベースのルール提案を導入しており、GitHub Copilot Autofix のように検知と修正を同時に行うツールが主流化しつつあります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| CI/CDに組込の自動診断 | 手動の年次診断のみ |
| SBOM自動生成 | 依存管理が曖昧 |
| Autofix対応ツール | 検知だけで放置 |
| 型安全な言語 | 動的言語の曖昧さ |
一方で、AI自体が新しい攻撃対象になるのが現代の現実です。プロンプトインジェクション・LLM の情報漏洩・AI エージェントの権限逸脱など、従来の診断ツールではカバーできない領域が生まれており、AI 専用のセキュリティ検査（Garak・PromptFoo 等）が新しい柱になります。
AI 時代はAI自体への攻撃も診断対象。従来の SAST / DAST だけでは不十分です。
筆者メモ — 「パッチ遅れ」と「ゼロデイ」の両方が致命傷になった事例
脆弱性診断をサボったコストが会社を傾けた事例は、セキュリティ業界の定番の語り草です。
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利用がある場合）
最終的な判断の仕方
脆弱性診断の核心はリリース前の儀式ではなく、CI/CDに組み込んで継続運用するという発想です。AI が書くコードは穴が混ざりやすく、依存ライブラリの脆弱性は毎日生まれます。認証・認可をどれほど堅牢に設計しても、SQL インジェクション1つで全てが崩れる現実を直視する必要があります。最優先で入れるべきは SCA（Dependabot）で、自社コードより依存先の穴の方が攻撃頻度が高いのが現代の常識です。そこに SAST・DAST を重ね、規模に応じて IAST・ペネトレを積み上げるのが王道です。
もう一つの決定的な軸はAIが書き、AIが守る時代のセキュリティ運用という要請です。CodeQL・Copilot Autofix のように検知と修正を同時に行うツールが標準化する一方で、AI自体が攻撃対象になります。プロンプトインジェクション・LLM 情報漏洩・エージェント権限逸脱など、従来ツールではカバーできない領域にも目を向ける必要があります。SBOM と SLSA はサプライチェーン対策の必須条件として商流に組み込まれ、技術判断を越えて契約条件になる時代です。
選定の優先順位
- Dependabotを初日から有効化 — SCA は最も ROI が高い
- CIにSASTを統合 — push 毎の自動検査が現代の最低ライン
- ステージングにDASTを週次実行 — 設定ミス起因の穴を塞ぐ
- SBOM自動生成と脆弱性SLAを定義 — 商流要件になりつつある
「CI/CDに組み込み、継続的に検査する」のが鉄則。年1回のペネトレだけでは穴を塞ぎきれません。
まとめ
本記事は脆弱性診断について、SAST・DAST・SCA・IAST・ペネトレ・SBOMの使い分け・対応SLA・AI時代の新しい攻撃面まで含めて解説しました。如何だったでしょうか。
Dependabotを初日から有効化、CIにSAST統合、ステージングにDAST週次実行、SBOM自動生成とSLA定義。これが2026年の脆弱性診断の現実解です。
そしてこれが「セキュリティアーキテクチャ」カテゴリの最終回でした。次回からは新しいカテゴリ（開発・運用設計）の解説に入ります。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（53/89）