Skip to content
Published on

静的解析 / SAST 2026 — Semgrep / CodeQL / Snyk / SonarQube / Aikido / Trivy 徹底比較

Authors

プロローグ — 「セキュリティツール一本で全部守れる時代は終わった」

2018年頃に「静的解析ツール、何を使う?」と聞けば、答えはたいてい二択だった。オープンソースなら SonarQube、エンタープライズなら Checkmarx か Veracode。これでだいたい全部。CI に SAST を一個つないで、四半期ごとに人間が偽陽性を仕分けて、運用担当者は PDF レポートを受け取り、開発者はそれをほとんど見ない。

2026年5月の現在、その絵は粉々になった。ある会社のセキュリティパイプラインを描いてみると、だいたいこうなる。

  • PR で回る SAST — Semgrep または CodeQL。
  • 依存スキャン (SCA) — Snyk Open Source、Endor Labs、Socket.dev、または Dependabot。
  • シークレットスキャン — GitGuardian か Cycode が git push pre-receive で。
  • コンテナイメージスキャン — Trivy または Snyk Container、ビルド直後。
  • SBOM 生成 — SPDX または CycloneDX、ビルド成果物に添付。
  • ランタイム DAST — OWASP ZAP または Burp Suite、ステージングで夜間実行。
  • プライバシースキャン — Bearer が PII フローを検出。
  • 全部を束ねる ASPM — Apiiro、Cycode、または Aikido が一画面で優先順位。

この記事は2026年時点で上記のツールがそれぞれどこに立ち、何が得意で何が苦手なのか、そして「自分のチームは何を選ぶべきか」を整理する。単なるリストではなく、Pro engine、reachability、AI autofix、EU CRA — 2024〜2026の間にこの市場を揺さぶった4つの潮流を一緒に見る。


1章 · 2026年コードセキュリティツール地図 — SAST / DAST / SCA / Secrets / Container

まず全体像。コードセキュリティツールは通常、次の5軸に分類される。

カテゴリ何を見るか代表ツール
SAST (Static App Security Testing)ソースコードの脆弱パターン、dataflowSemgrep, CodeQL, Snyk Code, SonarQube, Checkmarx, Veracode
DAST (Dynamic App Security Testing)実行中アプリの HTTP / 表面脆弱性OWASP ZAP, Burp Suite, Invicti
SCA (Software Composition Analysis)OSS 依存の既知 CVESnyk Open Source, Endor Labs, Socket.dev, Trivy, Dependabot
Secretsコード / git 履歴の API キー、トークンGitGuardian, TruffleHog, Cycode, Gitleaks
Container / IaCコンテナイメージ、Terraform、K8s manifestTrivy, Snyk Container, Aikido, Checkov

ここに2024〜2026の間で新しく入り込んできたカテゴリが2つある。

  • ASPM (Application Security Posture Management) — 複数ツールの検出を一画面で優先順位付け・運用。Apiiro、Cycode、Aikido が代表。
  • Privacy / PII scanning — コードがどんな個人情報を扱うか追跡。Bearer が先頭。

そして2026年のトレンドは明確だ。「複数のツールを一つのプラットフォームが束ねる」。Snyk は Code + Open Source + Container + IaC を一括で売り、Aikido は最初からオールインワン、Semgrep も Pro エンジンの上に Supply Chain・Secrets を乗せた。単一ポイントツールから出発して ASPM のようなプラットフォームになるか、最初からプラットフォームとして入ってくるかの二択になりつつある。


2章 · Semgrep — オープンソース SAST のデファクト + Pro engine

Semgrep は2020年頃に登場した静的解析ツールで、「AST 上のパターンマッチング」というシンプルなモデルを使う。grep のように見えるがコードの構文木を読む。このシンプルさが武器となり、2026年にはオープンソース SAST のデファクト標準になった。

コアコンセプト

  • Rule — YAML で書くマッチパターン。正規表現ではなくコード構造を見る。
  • Semgrep CE (Community Edition) — 無料 OSS、単一ファイル解析。
  • Semgrep Pro engine — 有料、関数間 dataflow、クラス間追跡。
  • Semgrep Supply Chain — SCA。reachability 基盤で「実際に呼ばれている CVE のみ」優先。
  • Semgrep Secrets — git 履歴からシークレット検出。

強み

  • ルール作成が圧倒的に簡単 — YAML 一ファイルでチーム固有ルールを1時間以内に。
  • オープンソースコミュニティが作った1万+の公開ルール。
  • CI 統合が速い。通常5分以内に PR コメントまで到達。
  • Pro engine になると dataflow が強くなり偽陽性が大幅に減る。

弱み

  • CE 単体では関数間の流れが見えず、深い解析が難しい。
  • Pro engine は有料、価格は seat ベースで急速に大きくなる。
  • C++、Swift、Rust のような言語は CodeQL より弱い。

選ぶタイミング

  • チームが小さく、OSS 親和的で、自分のルールを書きたい場合。
  • Python、JS/TS、Go、Java 中心のコードベース。
  • PR 時の短いフィードバックループが重要な場合。
# Semgrep ルールの例 — Flask の SQL injection パターン
rules:
  - id: flask-sql-injection
    pattern: |
      $CURSOR.execute("..." + $VAR + "...")
    message: SQL injection via string concatenation
    severity: ERROR
    languages: [python]
    metadata:
      cwe: CWE-89
      owasp: A03:2021-Injection
# ローカル実行
semgrep --config=auto .

# CI で
semgrep ci --config=p/owasp-top-ten

Semgrep Pro engine は単一関数内のフローを越えて関数間 dataflow を見て、クラスメンバを通じた taint 追跡も行う。無料 CE との最大の違いは「ユーザー入力が5段階の関数呼び出しを経て sink に到達」するケースを掴むか掴まないかだ。


3章 · CodeQL — GitHub Advanced Security の中核

CodeQL は Semmle が作り、2019年に GitHub が買収した静的解析エンジンだ。コードをデータベースに変換してその上にクエリを書くという独特のモデルを使う。SQL を書くように「この条件を満たすコードパスを探せ」と問い合わせる。

コアコンセプト

  • CodeQL database — ソースをパースして作る関係 DB。関数、呼び出し、変数、フローがテーブルに。
  • QL query — Datalog 系列のクエリ言語。SAST ルールがすなわちクエリ。
  • GitHub Advanced Security (GHAS) — CodeQL を GitHub に統合した商用製品。
  • Default setup — GHAS を有効にすれば自動的に標準クエリセットが PR に付く。

強み

  • dataflow 精度が業界最強級。CWE-89、CWE-79 のような taint 流れを関数間で正確に追跡。
  • 対応言語が広い — C/C++、C#、Go、Java/Kotlin、JS/TS、Python、Ruby、Swift。
  • GitHub 統合が深い。PR ブロック、Security タブ、セキュリティアドバイザリ (GHSA) と自動連携。
  • クエリは公開。新しい CVE に対してコミュニティがクエリを追加可能。

弱み

  • 速くない。大きな monorepo でのフルスキャンは30分〜数時間。
  • クエリ作成の難度が高い。Semgrep YAML 1時間で書けるものが CodeQL では数日。
  • GHAS は enterprise 価格 (seat ベース) なので小規模チームには重い。

選ぶタイミング

  • すでに GitHub Enterprise を使う組織。
  • C/C++ または Swift の比重が高いコードベース。
  • 偽陽性を最大限減らし、深い dataflow が必要な場合。
// CodeQL の例 — Java SQL injection taint flow
import java
import semmle.code.java.dataflow.FlowSources
import semmle.code.java.dataflow.TaintTracking

module SqlInjectionConfig implements DataFlow::ConfigSig {
  predicate isSource(DataFlow::Node n) { n instanceof RemoteFlowSource }
  predicate isSink(DataFlow::Node n) {
    exists(MethodCall mc | mc.getMethod().hasName("executeQuery") |
      n.asExpr() = mc.getArgument(0))
  }
}

module SqlInjectionFlow = TaintTracking::Global<SqlInjectionConfig>;

from SqlInjectionFlow::PathNode source, SqlInjectionFlow::PathNode sink
where SqlInjectionFlow::flowPath(source, sink)
select sink, source, sink, "SQL injection from $@", source, "user input"

CodeQL の本当の価値は「一度書いたクエリが全 GitHub リポジトリに適用可能」という点だ。Log4Shell が起きたとき、GitHub は24時間以内にクエリを配布し、それが数十万のリポジトリに即時反映された。この規模感は他のツールが真似しづらい。


4章 · Snyk Code / Snyk Open Source — DeepCode 統合以後

Snyk はもともと SCA(依存スキャン)から始まった。2020年に DeepCode(チューリッヒ工科大スピンオフ、ML ベース SAST)を買収して SAST に拡大し、現在は Code + Open Source + Container + IaC を束ねた統合プラットフォームだ。

主要製品

  • Snyk Code — SAST。DeepCode AI エンジン基盤、ML で学習したパターン。
  • Snyk Open Source — SCA。依存 CVE + ライセンス + reachability。
  • Snyk Container — コンテナイメージ + IaC。
  • Snyk Cloud — AWS、Azure、GCP 設定スキャン。

強み

  • IDE 統合が優れている。VS Code、IntelliJ、JetBrains すべて一級サポート。
  • 開発者フレンドリーな UX。発見から fix 提案まで一つの PR ですっきり。
  • Reachability analysis — 「この CVE は私たちのコードパスで実際に呼ばれているか」を判断。
  • DeepCode AI が autofix を提案 (Snyk DeepCode AI Fix)。

弱み

  • 価格が高い。特に Open Source まで全部使うと enterprise 価格。
  • セルフホスティングの選択肢が限定的 — ほとんどが SaaS。
  • ルールのカスタマイズが Semgrep ほど自由ではない。

選ぶタイミング

  • スタートアップ〜中堅で「一つのベンダーから SAST+SCA+Container を全部受け取りたい」場合。
  • IDE 内でリアルタイムフィードバックを望む開発チーム。
  • 外部 SaaS 使用に抵抗のない組織。
# Snyk CLI の使用
snyk auth
snyk code test                  # SAST
snyk test                       # SCA (依存)
snyk container test alpine:3    # コンテナ
snyk iac test terraform/        # IaC

# CI 統合 (GitHub Actions)
- uses: snyk/actions/setup@master
- run: snyk test --severity-threshold=high

Snyk の大きな変化は2024年の DeepCode AI 統合加速。以前はパターンベースだった SAST が ML 学習 + LLM autofix に移った。実測で「偽陽性30〜40%減、autofix 採用率50%以上」という報告が出始めた。ただし ML ベースの弱みである「なぜこれが脆弱と判断したかの説明が弱い」という批判も同時に存在する。


5章 · SonarQube 11 — クラシックの進化

SonarQube は2008年からある静的解析のクラシック。元々はコード品質(重複、複雑度、テストカバレッジ)が中心だったが、2010年代後半からセキュリティルール (SonarSource Security) を強化して SAST 市場にも入った。

コアコンセプト

  • SonarQube Server — セルフホストサーバー。Community / Developer / Enterprise / Data Center エディション。
  • SonarLint — IDE プラグイン。現在は SonarQube for IDE に改名。
  • SonarCloud — マネージド SaaS。
  • Clean Code — 2023年に導入された新モデル。issue を5つの attribute に分類。

強み

  • セルフホスティングが標準。on-prem 要求が強い金融・政府に強い。
  • 25+の言語対応。幅が広い。
  • Quality Gate — PR が基準未達ならブロックするワークフローが成熟。
  • Community Edition が無料 + 機能十分。

弱み

  • SAST 精度は Semgrep Pro/CodeQL に比べ一段下という評価が多い。
  • UI がクラシックでモダンなツールに比べて重い。
  • セルフホスティングなので運用負荷 (サーバー、DB、アップグレード) がある。

選ぶタイミング

  • コード品質 + セキュリティを一つのツールで見たい場合。
  • セルフホスティングが必須の規制業界 (金融、公共、医療)。
  • Java/C# 中心のエンタープライズコードベース。
# SonarQube + Maven ビルド
sonar:
  image: sonarsource/sonar-scanner-cli
  command: >
    sonar-scanner
    -Dsonar.projectKey=my-app
    -Dsonar.host.url=$SONAR_HOST
    -Dsonar.login=$SONAR_TOKEN
    -Dsonar.qualitygate.wait=true

SonarQube 11(2024年リリース)のコアな変化は二つ。一つは Clean Code モデルの強化 — issue を単なる「重要度」ではなく attribute (Consistency, Intentionality, Adaptability, Responsibility) に分類する。もう一つは AI アシストコードルール — Copilot が生成したコードパターンを認識するルールセットが追加された。


6章 · Aikido Security — オールインワン新興

Aikido Security はベルギーのスタートアップで2023年創業、2024年にシリーズ A(1700万ドル)、2025年にシリーズ B(5000万ドル)を受け、急速に成長したオールインワン AppSec プラットフォームだ。

何が違うか

  • オールインワン — SAST、SCA、IaC、Secrets、Container、Cloud Posture、DAST を一つのダッシュボードで。
  • 開発者ファースト UX — 偽陽性を ML で自動 dedup し、ノイズを大幅に削減。
  • AI Autofix — 発見された脆弱点に対して PR を自動生成。
  • 価格が透明 — seat 価格を公開、小規模チームが始めやすい。

強み

  • セットアップが本当に速い。GitHub OAuth 一回押すと5分以内に初回スキャン。
  • 一画面で SAST + SCA + Container + IaC + Secrets を見る。コンテキストスイッチ0。
  • 価格が Snyk・GHAS より親和的 — 小規模チームは無料 tier 可能。
  • AI Autofix の採用率が高いという報告。単純な依存アップグレード PR を自動生成。

弱み

  • リリース3年目で深さの面で Snyk・Semgrep Pro より浅いルールセットがある。
  • セルフホスティング選択肢は enterprise tier のみ。
  • 大きな monorepo の深い dataflow は CodeQL ほど強くない。

選ぶタイミング

  • セキュリティ人員が小さいか不在のスタートアップ・中堅。
  • 「複数ツール管理せず一画面で終わらせたい」場合。
  • AI autofix を積極活用したいチーム。
# Aikido CLI 統合
aikido scan --severity high

# GitHub App インストール後は
# - PR ごとに自動コメント
# - severity ベースのブロック
# - AI Autofix PR が自動生成

Aikido の本当の差別化点は「ノイズ管理」だ。普通の SAST ツールは大きな monorepo で数千の issue を吐き出し、セキュリティエンジニアが半分以上を偽陽性として close する。Aikido は ML で dedup + コンテキスト(どの環境、どのパス)で優先順位を付け、「今週本当に見るべき30個」だけを見せる。この UX の差が小規模チームで大きな価値になる。


7章 · Cycode / GitGuardian — secrets + supply chain

コードと git 履歴から漏洩したシークレット(API キー、トークン、証明書)を捕まえるカテゴリは2020年頃に GitGuardian が事実上作った。Cycode はそこに supply chain まで束ねてより広い ASPM に行った。

GitGuardian

  • 2017年創業、シークレット検出に特化。
  • 350+種類のシークレットパターン (AWS、GCP、Stripe、Slack、...)。
  • 公開 GitHub 全体を24時間スキャンし、leak 発生時即時通知 (Has My Secret Leaked)。
  • pre-receive hook で push 時点にブロック可能。
  • 無料 tier が25ユーザーまでで寛大。

Cycode

  • 2019年創業、ASPM(Application Security Posture Management)としてポジショニング。
  • Secrets + SCA + IaC + SAST + Source Code Leak + CI/CD posture を一画面で。
  • 「Source Path Analysis」— 一つの脆弱点がどこで誰が作ったどの PR で入ったか追跡。
  • enterprise 対象が明確。

強み / 弱み比較

項目GitGuardianCycode
強みシークレット検出精度1位、無料 tier 寛大フルスタック ASPM、大規模組織可視性
弱みシークレット以外の領域は弱いシークレットだけ見れば GitGuardian より狭い
価格シークレットだけならコスパ最強enterprise 価格

選ぶタイミング

  • GitGuardian — シークレット leak が最優先関心事。他の SAST/SCA は別である場合。
  • Cycode — 「ASPM 単一プラットフォーム」を望む中堅以上。
# GitGuardian ggshield pre-commit hook
repos:
  - repo: https://github.com/gitguardian/ggshield
    rev: v1.32.0
    hooks:
      - id: ggshield
        language_version: python3
        stages: [commit, push, manual]

シークレット検出の難しさは「正規表現だけでは不足」という点だ。AWS access key はパターンが明確だが、JWT トークンや Stripe restricted key のようなものは文脈(周辺の変数名、関数)と entropy を見なければならない。GitGuardian と Cycode はどちらも ML 分類器を追加して偽陽性を減らし、2025年頃から LLM ベースの「これが本物のシークレットか placeholder か判断」機能も入った。


8章 · Trivy (Aqua) — コンテナ + 依存 + IaC

Trivy は Aqua Security が作ったオープンソースのコンテナスキャナで、シンプルな CLI から出発して今や事実上の標準になった。コンテナイメージだけでなく、依存、IaC、K8s manifest、SBOM まで一つのバイナリで全部やる。

コア機能

  • Image scan — Docker/OCI イメージの OS パッケージ + 言語別パッケージ (npm, pip, gem, ...) の CVE。
  • Filesystem scan — ローカルファイルシステム(例 dist ディレクトリ)。
  • Repository scan — git リポジトリを丸ごと。
  • IaC scan — Terraform、K8s、Dockerfile ポリシー違反。
  • SBOM scan — SPDX、CycloneDX 形式で出力。
  • K8s scan — クラスタ全体のワークロードを一度に。

強み

  • オープンソース、無料。単一バイナリでインストール簡単。
  • 速い。小さなイメージは5秒以内。
  • DB が定期的に更新され (CVE-aware) 結果が信頼できる。
  • Aqua Security の商用製品 (Aqua Platform) と自然に接続。

弱み

  • SAST はやらない。あくまで SCA + コンテナ + IaC。
  • ルールカスタマイズは OPA/Rego が必要で多少の学習コスト。
  • 大きなクラスタの K8s スキャンはメモリを多く使うことがある。

選ぶタイミング

  • 無料/OSS でコンテナ + IaC + 依存を全部扱いたいとき。
  • 他のツール (Snyk、GHAS) の上に OSS 補助スキャナとして乗せたいとき。
  • K8s 環境全体の baseline セキュリティ点検。
# Trivy の使用例
trivy image alpine:3.20
trivy fs ./src
trivy repo https://github.com/user/repo
trivy config terraform/
trivy k8s --report summary cluster

# SBOM 生成
trivy image --format cyclonedx -o sbom.json alpine:3.20

Trivy の大きな強みは「一つのツールで5つを全部やる」点だ。小規模チームなら Trivy + Semgrep CE + GitGuardian 無料 tier の組み合わせだけで SAST + SCA + Container + IaC + Secrets をすべてカバーできる。OSS フレンドリーなチームのスタート地点としてほぼ常に登場する。


9章 · Checkmarx / Veracode — エンタープライズ陣営

Checkmarx(イスラエル、2006)、Veracode(米国、2006)は SAST 市場のクラシック両強だ。両方とも大企業 / 金融 / 政府を主顧客にした enterprise SAST プラットフォームだ。

Checkmarx

  • Checkmarx One — 統合プラットフォーム。SAST + SCA + Container + IaC + API Security。
  • 25+言語対応、深い dataflow 解析。
  • セルフホスティング + SaaS の両方。
  • 韓国でもパートナー多数、金融分野で多数導入。

Veracode

  • クラシック SAST + DAST + SCA + Container。
  • バイナリ解析可能 — ソースがなくても .jar/.dll から解析。
  • コンプライアンスレポートが強い (PCI-DSS、HIPAA)。
  • SaaS 中心。

強み

  • enterprise コンプライアンスレポートが標準化されている。
  • 深い dataflow + 大きなコードベース処理。
  • 24時間サポート、オンサイトコンサルティング。
  • 大組織のセキュリティ運用チーム(通常数十〜数百名)が運用しやすい設計。

弱み

  • 価格が非常に高い。通常 enterprise 価格見積もり。
  • 開発者フレンドリーとは言いがたい。結果がセキュリティチーム中心。
  • スキャンが遅く、偽陽性比率がモダンツールより高いという批判。
  • UI/UX が重い。Snyk・Semgrep・Aikido のようなモダンツールと比較すると格差。

選ぶタイミング

  • コンプライアンスレポートが契約要件の場合(政府、金融、公共)。
  • 大組織、専任セキュリティチームがある場合。
  • セルフホスティング + 24時間 enterprise サポートが必須なとき。
# Checkmarx One CLI
cx scan create --project-name "my-app" \
  --branch main \
  --scan-types sast,sca,iac-security \
  -s ./source

# Veracode CLI
veracode static scan \
  --source-file my-app.jar \
  --app-name my-app

エンタープライズ陣営の変化はモダンツールの追撃。Snyk、Semgrep Pro、GHAS が enterprise 市場を侵食すると Checkmarx・Veracode も UX 改善と AI autofix(Checkmarx AI Security Champion など)導入を加速した。価格帯が同じならモダンツールが次第に有利な流れだ。


10章 · OWASP ZAP, Bearer, Endor Labs, Socket.dev — その他の強者

上の8章で扱いきれなかったが、2026年に外せないツールたち。

OWASP ZAP

  • Zed Attack Proxy。オープンソース DAST の標準。
  • 実行中のウェブアプリをクロールしながら OWASP Top 10 パターンを試行。
  • 無料、大きなコミュニティ。
  • CI 統合も可能 (zap-baseline.py)。

Bearer

  • プライバシー + セキュリティ静的解析。
  • 「このコードがどんな PII(メール、電話番号、SSN)を扱うか」追跡。
  • GDPR、CCPA コンプライアンスレポートに強い。
  • 2023年に Cycode が買収。

Endor Labs

  • SCA 専門、「reachability analysis」の先駆者。
  • 依存の CVE のうち「実際に呼ばれるコードパスにあるか」を判断。
  • 結果として優先順位付きの脆弱点リストが出る — 通常80%以上が unreachable にダウングレード。
  • 2024年シリーズ B 7000万ドル。

Socket.dev

  • npm サプライチェーンに特化。
  • 依存変化を PR でリアルタイム解析(postinstall script、telemetry、ファイルシステムアクセス、...)。
  • 「このパッケージが急に telemetry を追加した」のような supply chain attack シグナルを検出。
  • npm エコシステム内で圧倒的。

比較マトリックス

ツールカテゴリ強み弱み
ZAPDASTOSS、大きなコミュニティUI クラシック、偽陽性多い
BearerPrivacy SASTPII フロー追跡1位一般 SAST は弱い
Endor LabsSCA + Reachability優先順位決定に強い価格 enterprise
Socket.devnpm サプライチェーンリアルタイム supply chain シグナルnpm 外は弱い

11章 · SBOM (SPDX / CycloneDX) — 標準の成熟

SBOM(Software Bill of Materials)は「このソフトウェアがどんなコンポーネントで作られたか」のリストだ。2021年の米国大統領令14028以後事実上義務化の流れが始まり、2024年の EU CRA で EU 市場でも強制化方向に固まった。

二つの標準

  • SPDX — Linux Foundation。2010年スタート。ライセンスコンプライアンスに強い。
  • CycloneDX — OWASP。2017年スタート。セキュリティ中心、VEX 統合。

2026年現在、両方とも生き残り、ツールは通常両方の形式に対応する。CycloneDX がセキュリティツール (Trivy、Snyk、Anchore、Syft) 側で若干優勢な印象。

何を含むか

フィールド意味
Componentパッケージ名、バージョン、種類 (library, OS, container, ...)
Supplier誰が作ったか
Hash完全性検証用
Licenseライセンス (SPDX ID)
Relationshipdepends-on, contains のようなグラフ
Vulnerabilities(オプション) 既知 CVE リスト、VEX

生成ツール

  • Syft (Anchore) — 無料 OSS、コンテナ + ファイルシステムから SBOM 生成。
  • Trivy — Syft 統合、image scan 時に同時。
  • Snyk、GitHub — 自動生成および添付。
  • Dependency-Track (OWASP) — SBOM を受け取り CVE と連結するサーバー。
# Syft でコンテナから SBOM 生成
syft alpine:3.20 -o cyclonedx-json > sbom.json
syft alpine:3.20 -o spdx-json > sbom.spdx.json

# Trivy で同様に
trivy image --format cyclonedx -o sbom.json alpine:3.20

# GitHub の SBOM API
gh api /repos/OWNER/REPO/dependency-graph/sbom > sbom.json

VEX (Vulnerability Exploitability eXchange)

SBOM とペアを成す標準。「このコンポーネントのこの CVE は私たちの製品で影響なし」のような vendor 応答を標準化する。2025年からツールが VEX 入力を受け取り始め、reachability analysis と結合して「本当に risky な CVE のみ」優先順位を付ける流れの中核インフラになった。


12章 · Reachability analysis — Endor, Snyk

「依存に CVE が100個ある」というレポートを受けたことがあれば、そのうち何個が本当に自分のアプリで呼ばれているか数えたこともあるだろう。Reachability analysis はこの問題を自動化する。

Reachability とは

  • 第1段階 — 依存グラフでパッケージが直接 import されているか? (dependency)
  • 第2段階 — そのパッケージの vulnerable な関数が import されているか? (symbol-level)
  • 第3段階 — 自分のアプリコードでその vulnerable 関数が実際に呼ばれているか? (call-graph)
  • 第4段階 — その呼び出しが実際のランタイムに到達可能か? (taint + control flow)

業界の測定によると、第1段階で掴まれた CVE の70〜95%は第3〜4段階に行くと unreachable だ。つまりほとんどはパッチ不要か、優先度が低い。

主要プロバイダ

ツール深さ言語カバー備考
Endor Labs第4段階 (call-graph)Java、JS/TS、Python、Go、Rust などreachability 専門
Snyk Open Source第3段階 (symbol)Java、JS/TS、PythonUX が滑らか
Semgrep Supply Chain第3段階Java、JS/TS、Python、Ruby、GoSemgrep エンジン活用
Socket.dev第1段階 + 行動解析npm 特化別次元

効果

ある実測事例 — 大きなモノレポ (JS/TS、300K LOC、依存1500個) 基準。

  • 依存 CVE 総計412件(第1段階)。
  • symbol-level reachability 適用: 87件(79%減)。
  • call-graph reachability 適用: 31件(92%減)。
  • セキュリティチームが実際に見るべきは31件。

この効果のため2024年以降 SCA ツールを選ぶ際 reachability は事実上必須機能になった。


13章 · LLM-powered SAST + Autofix

2023〜2026の間で最大の流れ。LLM が SAST の二つを変えた。

1. ルール作成 / dataflow

伝統的に SAST ルールは正規表現または dataflow グラフ上の明示的ルールだった。LLM は自然言語説明 → コードパターンをある程度一般化する。結果として「見たことのない新しい脆弱パターン」も捕まえる可能性。

  • Snyk DeepCode AI — ML 学習基盤、パターン + AI ハイブリッド。
  • Aikido AI — ルール + LLM dedup。
  • Semgrep Assistant — 自然言語 → Semgrep YAML ルール生成。
  • GitHub Copilot Autofix (旧 Code Scanning Autofix) — CodeQL 結果に LLM パッチ。

2. Autofix

発見された脆弱点に対して LLM がパッチ PR を自動生成する。

  • 依存アップグレード(最も安全、採用率高い)。
  • コードパッチ(慎重、人間レビュー必須)。
  • 設定変更(Dockerfile、K8s manifest)。

実測の落とし穴

LLM autofix が自動 PR を作っても常に正しいとは限らない。

  • 誤った fix — 脆弱点は解決したが機能回帰。テストカバレッジが不十分だと事故。
  • 部分 fix — sink は塞いだが source はそのまま。別経路で同じ攻撃可能。
  • コンテキスト不足 — 「この関数は internal でだけ呼ばれるから escape 不要」というドメイン知識が見えない。

2026年のベストプラクティスは「LLM autofix は PR ドラフト + 人間レビュー必須、依存アップグレードのような単純ケースのみ自動マージ許可」だ。コードパッチはまだ人間が確認するべき。

# Autofix がよく間違えるパターンの例
# Before — SQL injection
query = f"SELECT * FROM users WHERE name = '{name}'"
cursor.execute(query)

# LLM autofix v1 (誤り) — escape のみ追加
query = f"SELECT * FROM users WHERE name = '{name.replace(chr(39), chr(39)+chr(39))}'"
cursor.execute(query)

# LLM autofix v2 (正解) — parameterized
cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

14章 · EU CRA (2024) — ソフトウェア規制の始まり

EU Cyber Resilience Act は2024年10月に EU 議会通過、2024年11月に発効した規制だ。EU 市場に出される「デジタル要素を持つ製品」(ここにソフトウェア含む)にセキュリティ要件を強制する。

何を要求するか

  • 脆弱点管理プロセス — 最低5年間(あるいは製品寿命の間)パッチを提供しなければならない。
  • 既知の脆弱点発見時24時間以内に報告 — ENISA に通知。
  • SBOM 提供 — コンポーネントリストを市場監督当局からの要請時に提供。
  • Secure by design — 設計段階からセキュリティを考慮。
  • CE マーク — 適合性評価通過後 CE マーク貼付。

スケジュール

  • 2024年11月 — 発効。
  • 2026年9月 — 報告義務適用開始。
  • 2027年12月 — 全要件適用。

韓国・日本の会社が影響を受ける場合

  • EU 市場に SaaS または IoT 製品を販売する時。
  • EU 顧客にライブラリ・ソフトウェアコンポーネントを供給する時 (B2B 含む)。
  • オープンソースメンテナーは「商業的に活動」しなければ免除。

ツールへの影響

EU CRA は SBOM、脆弱点管理プロセス、24時間報告をすべて要求するため、ツール選択で次が重要になった。

  1. SBOM 生成 + 保存 + 外部公開機能。
  2. 24時間以内に発見 → 分類 → パッチ → 報告につながるワークフロー。
  3. 監査ログ — 誰がどんな決定をしたか5年間記録。

Cycode、Aikido、Snyk のような ASPM プラットフォームが EU CRA 対応機能を素早く追加し、GHAS も Security Advisory ワークフローを強化した。2026年に EU 市場進出を考慮する韓国・日本のチームなら SAST ツール選択時に CRA 対応機能を必ず確認すべきだ。


15章 · 韓国 / 日本の SAST 導入状況

韓国

韓国は情報通信網法、個人情報保護法、ISMS-P 認証によりセキュリティ点検が事実上義務的な市場だ。伝統的に次のツールが強かった。

  • Fortify (Micro Focus / OpenText) — 金融分野で多数導入。
  • Checkmarx — 韓国パートナー多数、大企業中心。
  • Veracode — グローバル企業の韓国支社中心。
  • Sparrow (スパロウ) — 韓国国産 SAST。国家情報院・金融分野で認証取得。

2020年代中盤からモダンツールが侵食を始めた。

  • Semgrep — スタートアップ・プラットフォーム企業(クーパン、トス、Naver、カカオ)導入多数。
  • Snyk — トス、Woowa Brothers、LINE など。
  • GHAS — GitHub Enterprise 導入企業。
  • カカオエンタープライズ KaibAi — カカオの AI コードセキュリティツール。2024年頃からカカオ・関連会社で内部優先適用。韓国語コードコンテキスト(コメント、変数名)処理に強み。

日本

日本の SAST 市場は保守的だが、2020年代に入りグローバルツールが急速に浸透中。

  • Veracode、Checkmarx — 金融・通信大企業。
  • 株式会社FFRIセキュリティ (FFRI Security) — 日本国産。エンドポイント保護が主力だが、静的解析・脆弱性診断コンサルティングも強い。政府・防衛多数顧客。
  • GMO Cybersecurity by Ierae — 日本のメジャーセキュリティ会社。診断・コンサル + ツール。
  • Snyk Japan — 2020年代後半に日本拠点拡大。
  • GitGuardian Japan, Aikido — シークレット/オールインワンツール導入事例増加。

日本市場の特徴。

  1. セルフホスティング選好 — SonarQube on-prem が強い。
  2. コンサル + ツール結合モデルが一般的 — 単独 SaaS 導入は慎重。
  3. 政府・防衛は日本国内企業(FFRI など)優先。

結論 — 地域別推奨

シナリオ韓国推奨日本推奨
スタートアップ (10〜50人)Semgrep + Trivy + GitGuardianAikido または Snyk
中堅 (50〜500人)Snyk または GHAS + AikidoSnyk + Cycode
大企業 (500+)Checkmarx + Cycode + 自社Veracode + FFRI コンサル
金融分野Sparrow + Fortify + CheckmarxCheckmarx + GMO + セルフホスト SonarQube
EU 進出検討Cycode または Aikido (SBOM + CRA)Snyk または Aikido (SBOM + CRA)

おわりに — 「ツールを買うのではなく、ワークフローを買う」

2026年の SAST 市場は単一カテゴリではなく5軸のトーナメントだ。そして次の5つの流れが市場を揺さぶっている。

  1. オールインワンプラットフォーム統合 — Snyk、Aikido、Cycode が SAST/SCA/Secrets/Container を一括で。
  2. Reachability — 「この CVE 本当に危険か」を自動判断。
  3. LLM autofix — 発見からパッチ PR まで自動化。
  4. EU CRA — SBOM + 24時間報告 + 5年パッチ義務化。
  5. 開発者ファースト UX — IDE 統合、PR 即時フィードバック、偽陽性自動 dedup。

小規模チームの出発点はシンプルだ — Semgrep CE + Trivy + GitGuardian 無料 tier。ここから出発しチームが大きくなれば一つの ASPM (Aikido、Cycode、Snyk) に束ねるか、GitHub Enterprise を使うなら GHAS で統合すればいい。大組織は enterprise ツール (Checkmarx、Veracode) と ASPM (Cycode) の組み合わせが標準。

一つの真理 — 「ツールを買うのではなく、ワークフロー(発見 → 分類 → パッチ → 報告)を買う」。どのツールを選んでもこのワークフローが5分以内に動かなければ、1万個の issue がバックログに積まれるだけだ。ツール評価の最初の質問はいつも「PR が SAST で赤線を受けたら、1時間以内にマージ可能な状態に行けるか?」だ。


参考 / References