CodeNote.net

Checkmarx を OSS で代替する — SAST・SCA・IaC・シークレットを束ねる AppSec スタック設計

#security#sast#sca#devsecops#open-source
重岡 正 · Sun, June 28, 2026

Checkmarx One は、静的解析（SAST）、ソフトウェア構成分析（SCA）、Infrastructure as Code（IaC）セキュリティ、シークレット検出、動的解析（DAST）などを 1 つのプラットフォームに統合した商用の ASPM（Application Security Posture Management）製品です。エンタープライズ領域ではデファクトスタンダードの一角ですが、高額なライセンス費用、スキャンの長時間化、誤検知を抑えるためのルールチューニングコストは多くの組織で共通の悩みになっています。

この記事では、Checkmarx を OSS で代替しようとするときの設計を、SAST・SCA・IaC・シークレット・DAST の各カテゴリと、それらを束ねる管理基盤の観点から整理します。結論を先に言えば、Checkmarx を 1 対 1 で置き換えられる単一の OSS は存在しません。現実解は「機能カテゴリごとに専用 OSS を組み合わせ、統合脆弱性管理プラットフォームで束ねる」という疎結合なマルチエンジン構成です。

単一 OSS では代替できない、という前提

Checkmarx One（クラウド版）と CxSAST（オンプレ版）は、SAST・SCA・DAST・IaC・コンテナ・シークレット・API セキュリティなど 9 つのスキャンエンジンを 1 つのプラットフォームに束ね、ASPM レイヤーで結果を相関・優先順位付けします。Checkmarx 公式によれば CxSAST は 35 以上のプログラミング言語と 80 以上のフレームワークにネイティブ対応します。したがって「Checkmarx の代替」とは、これら複数カテゴリを個別の OSS で再現することを意味します。

商用プラットフォームの強みは、複数の検査結果を統合・相関して「真の攻撃可能性」を評価する点にあります。静的解析だけに依存するアプローチはデッドコードに対する不要な警告を量産し、開発現場に大きなトリアージ負荷を強います。そこで現代の AppSec アーキテクチャでは、肥大化した単一製品に依存するのではなく、各領域に特化した高性能な OSS スキャナーを配置し、中央の管理基盤で集約・重複排除する構成が合理的な選択肢として支持されています。

面白いのは、Checkmarx 自身が著名な OSS を 2 つ保有・運営している点です。IaC スキャナーの KICS と、DAST の OWASP ZAP（“ZAP by Checkmarx” として Apache-2.0 のまま維持）です。皮肉にも、Checkmarx の代替スタックに Checkmarx 製 OSS が含まれることになります。

SAST — Semgrep CE と Opengrep の分岐点

Checkmarx のコアである SAST 領域は、OSS での完全再現が最も難しいところです。理由は、商用ツールが持つクロスファイル・クロス関数のデータフロー（テイント）解析が、多くの OSS では制限されるためです。

Semgrep Community Edition の制約

Semgrep は、コードをテキストではなく抽象構文木（AST）として構造的に処理するパターンマッチングエンジンで、30 以上の言語を対象に高速なスキャンを実現してきました。ルールを YAML で「コードそっくりに」書ける敷居の低さが人気の理由です。

しかし開発元の Semgrep, Inc. は 2024 年 12 月、旧 Semgrep OSS を Semgrep Community Edition へリブランドしました。エンジンのライセンスは LGPL-2.1 のまま維持されたものの、複数ファイル（cross-file）や関数間（cross-function）を跨ぐデータフロー解析、結果のフィンガープリント生成、ignore の追跡といった高度な機能がコミュニティ版から削除され、商用版に限定されました。さらにルールセットのライセンスも Semgrep Rules License v1.0 へ変更され、「自社内部業務目的のみ」という制限が付きました。エンジンは OSS でも、主要ルール群は純粋な OSS ではない、という整理が実務的です。

この制約は精度に直結します。Semgrep の委託で Doyensec が独立実施したベンチマーク（OWASP WebGoat・Juice Shop を使用）では、WebGoat において単一ファイル解析の Community Edition が脆弱性の 48 %（16 件）を検出したのに対し、クロス関数解析を持つ有償の Pro は 72 %（24 件）を検出し、真陽性率で約 50 % の差が出ました（Juice Shop でも 44 % 対 75 % と同様の傾向が確認されています）。

Opengrep フォークの誕生

この商業化に対抗し、Semgrep CE から切り離された高度な解析機能を無償かつオープンに維持するために立ち上がったのが Opengrep プロジェクトです。2025 年 1 月、Aikido Security・Endor Labs・Jit・Orca Security・Kodem など 10 社以上の DevSecOps ベンダーからなるコンソーシアムが、制限が課される前の最後のフル機能 CE コードベースを LGPL-2.1 でフォークしました。

Opengrep は、有償版へ移された関数間データフロー追跡（テイント解析）を 12 言語で復活させ、結果のフィンガープリント生成に加えて Semgrep にはない Visual Basic 対応まで追加しています。既存の Semgrep コミュニティルールやカスタム YAML ルールと完全な互換性を持ち、JSON・SARIF 出力も互換です。CLI 専用で完全無料、商用ティアもありません。ベンダーロックインを避けながら商用 SAST に近い解析深度を無料で得たい組織にとって、現時点で最有力の選択肢です。

言語特化スキャナーの補完

汎用 SAST だけでは、特定フレームワークに固有の脆弱性を見落とす危険があります。汎用エンジンをベースに据えつつ、言語固有の仕様を深く理解する専用リンターを併用するアプローチが有効です。

  • Bandit: Python 専用。ハードコードされたパスワード、危険な組み込み関数、SQL インジェクションのパターンを高速に検出する（Apache-2.0）。
  • Brakeman: Ruby on Rails 特化の定番。Rails 固有のルーティング・データフロー・設定不備に最適化され、汎用ツール特有の誤検知を抑える。ただし現行版は独自の Brakeman Public Use License で、完全 MIT のフォーク Railroader が別に存在する点に注意。
  • gosec: Go の AST を走査し、暗号の誤用・SQL インジェクション・ハードコードされたクレデンシャルなど Go 固有の不備を検出する（Apache-2.0）。
  • SpotBugs + Find Security Bugs: JVM（Java・Kotlin・Scala・Groovy）向け。バイトコード解析で 128 種類の脆弱性を検出する。ただし Find Security Bugs の公開リリースは 2020 年で止まっており、保守鮮度にはリスクがある。

汎用エンジンとしてもう 2 つ、SonarQube と CodeQL は評価対象に入ります。SonarQube Community Build はコード品質と運用基盤としては優秀ですが、テイント解析・PR デコレーション・ブランチ解析は商用版限定です。CodeQL はセマンティック解析の深さで商用に最も近い一方、プロプライエタリコードの CI/CD での利用には有償の GitHub Advanced Security が必須という重大なライセンス制約があります。無料で使えるのは OSS コードや学術研究に限られます。

SAST ツールの比較

評価項目Semgrep Community EditionOpengrepSonarQube Community Build
ライセンスエンジン: LGPL-2.1 / ルール: Semgrep Rules License v1.0エンジン・ルールとも LGPL-2.1（制限なし）LGPL-3.0
解析の深度単一ファイル・関数内のパターンマッチングのみ関数間データフロー・テイント解析基本的な脆弱性とコード品質（テイント解析は商用限定）
対応言語30 以上の主要言語30 以上に加え Visual Basic 等を独自追加20 以上（C/C++/COBOL 等は商用のみ）
CI/CD 親和性極めて軽量、ビルド環境不要軽量、全 Semgrep ルールが稼働可能無償版はメインブランチ中心
主な強み導入実績とコミュニティの成熟度商用制約のない高度解析、ベンダー連合の支援コード品質との一元管理

SCA — Trivy を中心とした依存関係スキャン

依存ライブラリやコンテナイメージの脆弱性を管理する SCA は、ファーストパーティコードの SAST と同等に重要です。この領域は OSS が商用に最も肉薄しており、Trivy を中心とした構成で十分に代替できます。

Aqua Security が開発する Trivy は、コンテナイメージ・Git リポジトリ・ファイルシステム・Kubernetes クラスターを単一バイナリで走査できるマルチレイヤースキャナーです。ビルド前段階では各言語のロックファイル（package-lock.json・poetry.lock・go.mod・Cargo.lock など）を解析し、ビルド後段階ではコンテナ内のインストール済みパッケージを特定します。脆弱性データベースは NVD だけでなく GitHub Advisory Database や各 Linux ディストリのアドバイザリを自動同期します。SBOM 生成では CycloneDX と SPDX をネイティブサポートします。

Trivy が統合型なのに対し、Anchore の Syft（SBOM 生成）と Grype（脆弱性スキャン）の組み合わせは Unix 哲学に沿った単機能ツールで、既存パイプラインへの部分的な組み込みが容易です。Google と OpenSSF の OSV-Scanner は OSV データベースを使い、エコシステム固有のマッチングで誤検知が少ないのが特徴です。

ポートフォリオ全体の継続監視には OWASP Dependency-Track が向きます。SBOM を取り込んで継続的に再評価し、新しい CVE が公開されるたびに影響範囲を洗い直せます。修正 PR の自動化は Dependabot や Renovate に任せます。

なお、ライセンススキャンでは注意が必要です。Trivy の --scanners license は依存コンポーネントのライセンスを SPDX 識別子で分類しますが、特定バージョンでは CycloneDX 出力時に「ライセンス ID/名称」と「SPDX ライセンス論理式」を同一配列に同時出力し、下流の検証でパースエラーを起こす事象（Issue #9300）が報告されています。自動検証を過信せず、trivy.yaml でポリシーを適切にチューニングする運用が求められます。

IaC とシークレット

IaC: Checkov・KICS・Trivy config

IaC の設定ミス検出では Checkov が最有力です。Prisma Cloud（Palo Alto）が開発し、Terraform・CloudFormation・Kubernetes・Helm・ARM・Bicep など幅広いフォーマットに対応します。1,000 以上の組み込みポリシーに加え、他の OSS にないグラフベースのクロスリソース解析を備える点が強みです。

Checkmarx 製の KICS も有力です。Apache-2.0 で完全にオープンソース化されており、Terraform・Kubernetes・Ansible・Docker・CloudFormation・Bicep・Pulumi・GitHub Workflows など 22 以上のプラットフォームを網羅します。2,400 以上のクエリが Open Policy Agent の Rego で記述されており、組織独自のルールをコードで追加できます。重要度に応じた終了コードを返すため、パイプラインでのゲート制御も容易です。Trivy の config スキャンも、後述の tfsec のチェックライブラリを継承しており、1 ツールで IaC まで見たいときに便利です。

この領域では終息が相次いでいる点に注意が必要です。tfsec は全チェックが Trivy へ統合済みで新機能はなく、Terrascan は 2025 年 11 月 20 日に Tenable がリポジトリを読み取り専用化（アーカイブ）しました。既存パイプラインは動きますが CVE 更新が止まるため、新規採用は非推奨です。Kubernetes のランタイムまで見るなら Kubescape（CNCF Incubating）が選択肢になります。

シークレット: Gitleaks・TruffleHog

シークレット検出では Gitleaks が最も信頼されている OSS の 1 つです。正規表現とエントロピーで検出し、Git の過去コミット全体をスキャン（gitleaks detect）できるほか、コミット前に差分だけを評価する保護モード（gitleaks protect）を備えます。過去のコードに眠る大量の偽陽性でチームが機能不全に陥るのを防ぐため、初回スキャン結果をベースラインとしてコミットし、以降は新規に混入した漏洩だけを検知する運用が可能です。コア CLI は MIT ですが、GitHub Action である gitleaks-action は組織利用に無料のライセンスキーが必要な点に留意してください。

TruffleHog は検証ファーストのアプローチが特徴で、検出した認証情報が「今も有効か」を実際に API で確認します。800 以上の検出器を持ち、履歴スキャンやインシデント対応に向きます（v3 以降は AGPL-3.0 で、統合時のコピーレフト伝播に注意）。レガシーコードへの後付け導入には、ベースライン機能を持つ detect-secrets（Yelp、Apache-2.0）が向きます。定石は、Gitleaks を pre-commit と CI の高速ブロックに、TruffleHog を定期的な履歴スキャンと検証に、という併用です。

なお Gitleaks の主要開発者は、機能が完成した Gitleaks（今後はセキュリティパッチ中心）から次世代ツールへの移行を進めています。従来の TOML による正規表現ベースの allowlist に代わり、CEL（Common Expression Language）系の式言語を採用することで、パスパターンやダミー文字列の除外を柔軟に記述でき、設定ファイルの肥大化を抑えつつ誤検知をさらに減らす方向に進化しています。

ASPM — DefectDojo で束ねる

個別の OSS ポイントツールをパイプラインで並列に走らせるだけでは、各スキャナーが出力する報告書を個別に確認・トリアージすることになり、運用負荷はかえって商用ツールを上回ります。この「アラートの分断」を防ぎ、Checkmarx One の中央管理ポータルを OSS で再現するために、OWASP のフラグシッププロジェクトである OWASP DefectDojo を中核に据えます。

DefectDojo は Python（Django）ベースで、非同期の重い処理を担う Celery ワーカーと、ジョブを中継するメッセージブローカー（Valkey または Redis）で構成される、本番利用に耐える拡張的なシステムです。200 以上のツールの結果を取り込め、Product Type・Product・Engagement・Test・Finding という多層のデータモデルでセキュリティガバナンスを表現します。ライセンスは BSD-3-Clause のオープンコアです。

DefectDojo の最大の価値は、異なるツールや複数回のスキャンで重複して報告されるアラートを自動でマージするスマート重複排除にあります。インポート時に CWE 分類・ファイルパス・行番号・エンドポイント、スキャナー固有の ID やカスタムハッシュを比較し、同一とみなした脆弱性を既存の Finding の子ノードとしてまとめます。これにより、500 件の生アラートを、実際に対処すべき 150 件程度の一意な問題に自動圧縮できます。

修正フローの連携では Jira との双方向同期に対応します。トリアージ結果から Push to Jira でチケットを自動作成し、Jira 側でチケットをクローズすると Webhook 経由で DefectDojo の Finding が Remediated や Risk Accepted に自動で書き換わります。

以下の図は、各 OSS ポイントツールと DefectDojo がどうつながり、Checkmarx の一元管理を再現するかを示したものです。

graph TD
    A[開発者がコードを変更] --> B(Pre-commit Hook: Gitleaks)
    B -->|シークレット未検出| C[Git リポジトリへ Push]
    C --> D[CI/CD パイプライン起動]
    subgraph Scanners [スキャナー並列実行]
        D --> E[SAST: Opengrep]
        D --> F[SCA: Trivy]
        D --> G[IaC: Checkov / KICS]
    end
    E -->|SARIF 出力| H[DefectDojo REST API]
    F -->|JSON 出力| H
    G -->|JSON 出力| H
    subgraph Dojo [DefectDojo ASPM]
        H --> I[インポート / 自動重複排除]
        I --> J[CVSS / EPSS 重大度評価と SLA 判定]
    end
    J -->|双方向連携| K[Jira チケット自動起票]
    K -->|Webhook 同期| J
    J -->|通知| L[Slack アラート]

DAST を加えるなら、Checkmarx が保有する OWASP ZAP を CI に組み込みます。ZAP はプロキシ・スパイダー・能動/受動スキャンを備えた無料 DAST の最有力で、REST・GraphQL・SOAP に対応します。テンプレート（YAML）ベースで既知 CVE を高速に検出する Nuclei を補完的に組み合わせると、API セキュリティの相当部分までカバーできます。

2025–2026 年に押さえるべき動向

この領域は動きが速いため、設計時に前提を最新化しておく必要があります。

  • Semgrep OSS が Community Edition へ改称（2024 年 12 月）。クロス関数解析などが有償版へ移動し、ルールが制限的ライセンスに変更された。
  • Opengrep フォークの登場（2025 年 1 月）。クロス関数テイント解析を復活させ、ほぼ週次でリリースが続いている。
  • tfsec が Trivy へ統合され、Terrascan が 2025 年 11 月 20 日にアーカイブ。IaC の勢力図が Checkov と Trivy へ寄った。
  • SonarCloud が SonarQube Cloud、Community Edition が Community Build へ改称。

とりわけ重いのがサプライチェーン攻撃です。2026 年 3 月、脅威アクターが認証情報の漏洩を悪用して Trivy のバイナリ、trivy-action、setup-trivy、そして Checkmarx の KICS GitHub Action にまで認証情報窃取マルウェアを注入する事件が発生しました（CVE-2026-33634、CVSS 9.4、Critical）。GitHub の immutable releases で保護されていた一部タグのみが無傷でした。教訓は明快で、GitHub Actions は可変タグ（@v1 など）ではなくフルコミット SHA で固定すべきです。セキュリティツール自体が攻撃対象になる時代であることを、設計の前提に組み込む必要があります。

代替の限界とトレードオフ

このマルチエンジン構成はライセンス費用を大幅に削減できますが、移行を決める前に以下の限界も評価すべきです。

  • レガシー言語への対応: Checkmarx の強みの 1 つは COBOL・RPG・PL/SQL・VB6・ABAP といったメインフレーム系言語を含む圧倒的なカバレッジです。Opengrep 等の OSS はこれらへの対応が不十分で、金融・行政システムなどレガシーコードを日常的にスキャンする環境では、OSS だけで 100 % 代替するのは技術的に困難です。商用 SAST を部分的に維持するハイブリッド運用が現実的になります。
  • 人件費へのトレードオフ: 商用ベンダーはエンジン保守・脆弱性フィードの更新・誤検知チューニング・SLA サポートを保証します。これを OSS に切り替えることは、ライセンス料を「トリアージルールや DefectDojo の運用保守を担う内製 DevSecOps チームの人件費」へ移転することを意味します。
  • ライセンスの落とし穴: CodeQL はプロプライエタリコードの CI/CD に有償の GitHub Advanced Security が必須、Semgrep のルールは制限的ライセンス、Brakeman の現行版は独自ライセンス、TruffleHog は AGPL-3.0 のコピーレフト、gitleaks-action は組織利用にキーが必要と、ツールごとに条件が異なります。商用配布や SaaS への組み込みを考えるなら精査が不可欠です。
  • 精度と誤検知: 単一ファイル解析の Semgrep CE や CPE マッチングの OWASP Dependency-Check は、reachability 解析を持つ商用ツールより誤検知が多い傾向があります。DefectDojo での重複排除とトリアージ運用が前提になります。

まとめ

Checkmarx の完全な 1 対 1 OSS 代替は存在しません。Checkmarx が単なる SAST エンジンではなく、言語対応・クエリ編集・IDE/CI 連携・クラウド/オンプレ・多層運用を一体で持つプラットフォームだからです。

現実的な答えは、Opengrep（または Semgrep CE）+ Trivy + Checkov/KICS + Gitleaks + OWASP DefectDojo を軸に、言語特化ツールと OWASP ZAP を必要に応じて足す構成です。導入は段階的に進めるのが安全です。まず軽量スタックを CI/CD に入れて pre-commit シークレット検出と PR 単位のスキャンを確立し、誤検知が運用を圧迫し始めたら DefectDojo で重複排除とトリアージを集中管理し、SAST のテイント解析精度が不足したら Opengrep への移行や有償ツールの部分導入を検討します。

モダンな言語（Java・Python・JavaScript・Go・Rust など）中心で、CI/CD を自社開発している組織にとって、この構成はコスト削減とベンダーロックインからの解放をもたらす有力な戦略です。一方で、レガシー言語の比率が高い環境や、運用に割ける内製リソースが限られる組織では、商用ツールの継続やハイブリッド運用のほうが総コストで有利になることもあります。自社の言語比率と運用体制を起点に、機能分解の設計から始めるのが正しい順序です。

以上、アプリケーションセキュリティについて日々向き合っている立場から、Checkmarx を SAST・SCA・IaC・シークレットの OSS スタックで代替する設計の全体像を、現場からお送りしました。