概要#

脆弱性診断ツールは種類が多く、選定の時点で迷いやすいです。 この記事では、まず全体像をつかみ、そのあとに実運用で使える比較と導入ステップまで一気に整理します。

想定読者とこの記事のゴール#

本記事は、開発チームまたはSRE/セキュリティ担当として「脆弱性診断ツールをどう選び、どう運用に乗せるか」を短時間で判断したい読者を想定しています。

ゴールは次の3点です。

• 種別ごとの役割を誤解なく把握する
• 無料/有料を含む現実的な選択肢を比較する
• 明日から動ける導入ステップを決める

まず押さえる用語整理#

似た言葉が多いため、最初にざっくり整理しておきます。

• SAST: ソースコードを静的に解析し、実装上の問題を早期検出
• DAST: 稼働中アプリにリクエストを送り、外部から見える脆弱性を検出
• OAST: 外部コールバックを使い、Blind系（SSRF/XXE等）の検出を補完
• SCA: OSS依存パッケージの脆弱性・ライセンスを把握
• CSPM/KSPM/IaC Scan: クラウド設定やIaCのミスコンフィグを検出

実務上は「診断（検出）」と「防御（RASP/CNAPP/CWPPなど）」を分けて考えると、導入時の判断がしやすくなります。

まず全体像（種別一覧）#

最初に、脆弱性診断の種別を一枚で把握します。ここを基準に、この後の比較表や導入パターンを見ていくと理解しやすいです。

ツール選定マップ（Mermaid）#

次に、よく使う種別と代表ツールの関係をマップで俯瞰します。無料/有料/推奨を色で見分けられるようにしています。

flowchart LR
    A[脆弱性診断種別]
    A --> SAST[SAST]
    A --> DAST[DAST]
    A --> OAST[OAST]
    A --> SCA[SCA]
    A --> CSPM[CSPM]
    A --> APIST[APIST]
    A --> CIS[CIS]
    A --> SECRET[Secrets Scan]

    SAST --> Semgrep[Semgrep]
    SAST --> SonarQube[SonarQube]
    DAST --> ZAP[OWASP ZAP]
    DAST --> Burp[Burp Suite]
    OAST --> Interactsh[Interactsh]
    OAST --> Collaborator[Burp Collaborator]
    SCA --> Dependabot[Dependabot]
    SCA --> Snyk[Snyk]
    CSPM --> Prowler[Prowler]
    CSPM --> Wiz[Wiz]
    APIST --> APIFuzz[APIFuzzer]
    APIST --> Crunch[42Crunch]
    CIS --> Trivy[Trivy]
    CIS --> Grype[Grype]
    SECRET --> Gitleaks[Gitleaks]
    SECRET --> GHSecret[GitHub Secret Scanning]

    class Semgrep,ZAP,Interactsh,Dependabot,Prowler,APIFuzz,Trivy,Grype,Gitleaks free;
    class SonarQube,Burp,Collaborator,Snyk,Wiz,Crunch,GHSecret paid;
    class Semgrep,ZAP,Trivy,Gitleaks,Dependabot recommended;

    classDef free fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef paid fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
    classDef recommended fill:#fffde7,stroke:#f9a825,stroke-width:3px,color:#5d4037;

• 色の意味: 緑=無料中心、青=有料中心、黄枠=推奨（導入しやすさ/実績ベース）

有料・無料と推奨の一覧（実務向け）#

マップで全体感をつかんだあと、実際の選定に使えるように有料/無料と推奨候補を表で整理します。

ツール選定の判断軸#

製品比較は機能の多さだけでなく、運用に乗るかどうかで評価するのが重要です。最低限、以下の軸で比較することを推奨します。

組織規模別の導入パターン#

CI/CDへの最小実装例（GitHub Actions）#

最初の一歩として、PR時に SAST + SCA + Secrets + Container を実行する構成が現実的です。

1
name: security-minimum
2
on:
3
  pull_request:
4
  push:
5
    branches: [main]
6

7
jobs:
8
  security-scan:
9
    runs-on: ubuntu-latest
10
    steps:
11
      - uses: actions/checkout@v4
12

13
      - name: Semgrep (SAST)
14
        uses: returntocorp/semgrep-action@v1
15

16
      - name: Trivy (Container/FS)
17
        uses: aquasecurity/trivy-action@0.24.0
18
        with:
19
          scan-type: "fs"
20
          scan-ref: "."
21
          severity: "CRITICAL,HIGH"
22

23
      - name: Gitleaks (Secrets)
24
        uses: gitleaks/gitleaks-action@v2
25

26
      - name: Dependency Check (SCA)
27
        uses: dependency-check/Dependency-Check_Action@main
28
        with:
29
          project: "sample"
30
          path: "."
31
          format: "HTML"

ポイントは、最初から完璧を目指さず、重大度で閾値を決めて段階的に厳格化することです。

運用ルール（導入後に効く項目）#

ツール導入よりも、トリアージ運用の設計が成果を左右します。最低限、以下を決めておくと運用が安定します。

• 重大度ごとの対応期限（例: Criticalは48時間以内）
• 誰が一次トリアージするか（開発/セキュリティの責任分界）
• 誤検知のクローズ基準と再発防止の記録方法
• 例外承認フロー（期限付き、承認者明記）
• 月次での再発傾向レビュー

よくある失敗と回避策#

• ツールを増やしすぎて誰も見なくなる
  -> 最初は4種類程度に絞る（SAST/SCA/Secrets/Container）
• 検出はするが直らない
  -> SLAと担当を定義し、未対応を可視化する
• 誤検知が多く開発体験を壊す
  -> ルールを棚卸しし、ノイズの高い検知は調整する
• 本番運用前にCI時間が肥大化する
  -> PR時と夜間バッチでジョブを分割する

30/60/90日ロードマップ#

参考フレームワーク#

判断根拠を揃えるため、以下のフレームワークを参照すると実務で説明しやすくなります。

• OWASP ASVS
• OWASP SAMM
• NIST SSDF

まとめ#

脆弱性診断ツールの導入は「どの製品を入れるか」だけでなく、「どの順で、誰が、どう回すか」で成果が大きく変わります。 まずは小さく始めて、SAST/SCA/Secrets/Container を確実に運用し、次に DAST/OAST や CSPM へ広げる進め方が現実的です。