Datadog Code Securityとは｜6機能の守備範囲・対応言語・コミッター課金の料金

Datadog Code Securityは、自社で書いたコードとアプリケーションが使っているオープンソースライブラリを、リポジトリと稼働中のサービスの両方でスキャンする機能群です。ひとつの製品というより、静的解析（SAST）、ソフトウェア構成分析（SCA）、実行時コード解析（IAST）、シークレット検出、IaCの設定ミス検出、サプライチェーン保護という6つの機能をまとめた呼び名だと考えると全体像を掴みやすくなります。

この記事では、2026年9月時点のDatadog公式ドキュメントと料金ページの記載に基づいて、機能ごとの守備範囲、対応言語の差、課金単位の違い、導入時の設定ファイルまでを整理します。SAST・DAST・IASTという手法そのものの選び分けはWebアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分けで扱っているため、ここではDatadogの実装に絞ります。

まとめ：Datadog Code Securityの要点

• 公式ドキュメントが挙げる機能は6つ。Static Code Analysis（SAST）、Software Composition Analysis（SCA）、Runtime Code Analysis（IAST）、Secret Scanning、IaC Security、Supply Chain Security（Preview）です。
• 対応言語は機能ごとに大きく違います。SASTはルール一覧ベースで15言語をカバーする一方、IASTはJava・.NET・Node.js・Pythonの4言語のみで、Go・Ruby・PHPは対象外です。
• 課金単位が二系統に分かれています。リポジトリを見る静的系はコミッター単位、稼働中サービスを見る実行時系はホスト単位です。両者を混ぜて見積もると金額が合いません。
• SDKが要るのは実行時系だけ。SASTと静的SCAはDatadog SDKを必要とせず、リポジトリ連携かCIパイプラインだけで動きます。
• 稼働中アプリへの攻撃をブロックする役割は別製品。In-App WAFやRASPはApp and API Protection（AAP、旧Application Security Monitoring）が担当し、Code Securityの守備範囲ではありません。
• 設定ファイルは code-security.datadog.yaml。schema-version は v1.4 が最新で、sast キーの下にルールセットの取捨選択を書きます。

Code Securityを構成する6つの機能

公式ドキュメントのCode Securityトップページは、この製品を「リポジトリと稼働中サービスの両方で、自社コードとオープンソースライブラリをスキャンし、開発から本番までを一気通貫で可視化するもの」と定義し、次の6機能を挙げています。

静的スキャンと実行時検出という二層構造

検出系の機能は「リポジトリを静的に解析するもの」と「稼働中サービスを実行時に解析するもの」に大別できます。SASTはスキャン対象リポジトリへのコミットごとに走り、静的SCAは対応する依存関係ファイルが更新されたコミットで走ります。実行時側はDatadogのトレーシングライブラリ（SDK）を通じて、IASTがデータの流れを、ランタイムSCAが実際に読み込まれたライブラリを調べます。なおSupply Chain Securityはこの二分に収まらず、開発端末やCIでのパッケージインストール時に介入する別経路です。

この分かれ方は導入手順にも料金にも効いてきます。公式ドキュメントは明示的に「Static Software Composition Analysis（SCA）とStatic Code Analysis（SAST）の各機能はDatadog SDKを必要としない」と書いており、逆に言えばIASTとランタイムSCAはSDKの導入が前提です。既存のDatadog APMが入っていない環境で「まずコードの脆弱性だけ見たい」のであれば、SDKを追加せずに始められるSASTと静的SCAが候補になります。

App and API Protection（旧ASM）との線引き

WAFによる攻撃の検知と遮断は、DatadogではApp and API Protection（AAP）が担当します。公式ドキュメントはApp and API Protection（AAP）について「Formerly known as Application Security Monitoring (ASM)」と注記したうえで、In-App WAFによる悪性トラフィックのブロック、API探索とポスチャ管理、実行時の脅威検知を担当すると説明しています。

検索でよく見かける「Datadog RASP」も、Code Securityではなくこちら側です。AAPのExploit PreventionがRuntime Application Self-Protection（RASP）の技術を使い、リクエストが脆弱なコードパスに触れたかどうかを判定してブロックします。ドキュメントはExploit PreventionをIn-App WAFの拡張と位置づけ、In-App WAFを一次防御として使ったうえで、WAFがすり抜けた攻撃をブロックすると説明しています。

つまりCode Securityは「脆弱性を見つけて直す」側、AAPは「攻撃を検知して止める」側です。どちらか一方で両方の目的を満たすことはできません。両者の一般的な役割分担は脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界も参考になります。

機能ごとに異なる対応言語の範囲

Datadog Code Securityを検討するときに最初に確認すべきなのが、自分たちのスタックが各機能の対応表のどこに入るかです。ここは機能ごとに差が大きく、「Code Securityは◯◯言語に対応」とひとくくりに語ると誤ります。

SASTの対応言語：概要ページとルール一覧の食い違い

Static Code Analysisの概要ページは、スキャン対象として「languages and technologies」という書き方でPython、JavaScript、TypeScript、Java、C#、Go、Ruby、PHP、Docker、YAML、Kotlin、Elixir、Apex、Swiftの14項目を挙げています。ところが実際のルールを一覧するSAST Rulesページを見ると、言語別ルールセットの対象はApex、Bash、C#、Dart、Elixir、Go、Java、JavaScript、Kotlin、PHP、Python、Ruby、Rust、Swift、TypeScriptの15言語でした（ほかにjsx-react、tsx-react、railsというフレームワーク単位のルールセットがあります）。

概要ページにあるDockerとYAMLにはルールセットが無く、逆にルール側にあるBash・Dart・Rustは概要ページの14項目に入っていません。自社のスタックが対象かどうかを判断するときは、概要ページの一覧ではなくSAST Rulesページで該当言語のルールセットが実在するかを確認するのが確実です。

これとは別に、Datadogホスト型スキャン限定でAI-native SASTというルールセット群が用意されています。ルールセット名は <language>-ai_sast という形式で、C#、C++、Dart、Elixir、Go、Java、JavaScript、Kotlin、PHP、Python、Ruby、Rust、Swift、TypeScriptの14言語ぶんあります。従来のルールセットに無いC++がここで拾える一方、Apexは含まれません。ルールIDは datadog/typescript-promptinjection のように datadog/ 接頭辞つきで指定します。

IASTはJava・.NET・Node.js・Pythonの4言語のみ

Runtime Code Analysis（IAST）の対応言語は4つです。ドキュメントの検出ルール表はJava、.NET、Node.js、Pythonの4列しか持たず、互換性要件の表ではGo・Ruby・PHPの欄が「not supported」と明記されています。

さらに、同じ4言語のあいだでも検出できる脆弱性の種類が揃っていません。ドキュメントの表から重大度Criticalと一部Highの行を抜き出すと次のようになります。

Pythonはこの抜粋の範囲でも対応が薄く、クロスサイトスクリプティングや信頼されないデシリアライゼーションを検出しません。Python中心のチームがIASTだけで本番の自社コードを網羅しようとすると穴が残ります。ドキュメント自身も「Coverage may vary by language and framework」と断っており、フレームワーク単位の対応は互換性要件のページで個別に確認する必要があります。

IASTとランタイムSCAのSDK最低バージョン

実行時系の2機能はDatadogのSDK経由で動くため、トレーサのバージョン下限があります。ドキュメントの互換性要件の表は次のとおりです。

Node.jsだけは条件が二段構えで、ドキュメントの原文は「4.18.0 for Node.js 16+, or 5.0.0 for Node.js 18+」です。トレーサ4系ならNode.js 16以上で4.18.0以上、トレーサ5系ならNode.js 18以上で5.0.0以上という組み合わせを示しており、どちらか一方に固定されるわけではありません。

Go・Ruby・PHPのサービスでも、ライブラリの脆弱性を実行時に拾うランタイムSCAは使えます。自社コードの脆弱性をランタイムで追うIASTだけが対象外という整理です。IASTのセットアップ手順はDatadog Agent 7.41.1以上を指定しています（ランタイムSCAのAgent要件は言語ごとの互換性要件で別に確認してください）。APMとインフラ監視を無効にしていてもIASTは単独で動きますが、セキュリティ用のトレースとスパンを取り込むためのAPM intake費用は発生するとドキュメントは明記しています。

静的SCAの対象ファイルとロックファイルの優先順位

静的SCAはソースコードではなく依存関係ファイルを解析します。対応表はC#の.NET、C++のConan、Dartのpub、Goのmod、JVMのGradleとMaven、Node.jsのBun・npm・pnpm・yarn、PHPのcomposer、PythonのPDM・pip・poetry・UV、Rubyのbundler、RustのCargo、SwiftのSwiftPMという18行で構成されています。

見落としやすいのが読み取り順です。ドキュメントは「Datadog SCAは対応ロックファイルが検出されない場合にのみマニフェストをスキャンする」と明記しており、ロックファイルがあればそちらが優先されて package.json や pyproject.toml は読まれません。マニフェストだけを読む場合、^2.3.4 のような範囲指定は「その範囲を満たす最新の公開版」として解決され、プレリリース版は除外されます。ロックファイルをコミットしていないリポジトリでは、検出されるバージョンが実際の本番環境とずれる余地があるということです。

料金の2系統：コミッター単位とホスト単位

2026年9月時点の米国リージョン向け料金ページから、Code Security関連のプランを抜き出したものが次の表です。年間契約欄は年払い時の月額単価で、オンデマンド（従量）だと単価が上がります。

単価そのものより重要なのが、単位が2種類あることです。リポジトリを見る4プランはコミッター単位、稼働中サービスを見る2プランはホスト単位で、見積もりの母数がまったく違います。リポジトリ数でもリポジトリの行数でもない点にも注意してください。

コミッターの数え方

料金ページのFAQは、コミッターを「Gitのauthorメールアドレスで識別されるアクティブなGitコミッター」と定義し、課金対象になるのは「その月に少なくとも3回コミットした場合」としています。月に1回か2回しか触らない兼務メンバーは課金対象に入りません。逆に、CIボットが個別のメールアドレスでコミットしている場合は数え方に影響する可能性があるため、導入前に自社のコミット履歴を確認しておくと見積もりのずれを防げます。

バンドル選択時のランタイム側ホスト課金

40ドルのCode Securityバンドルはコミッター単位ですが、料金ページのFAQは「バンドルの一部として購入したランタイムSCAとIASTは、APMが入っている任意のホストで使える」と回答しています。個別に買うとホスト単位の課金が別立てになるのに対し、バンドルではホスト数の制約が外れる形です。静的系と実行時系の両方を使う予定があるなら、個別プランの合算とバンドルを必ず比較してください。

導入は2経路：Datadogホスト型スキャンとCIパイプライン

Datadogホスト型スキャンの対応リポジトリと必要権限

もっとも手数が少ないのは、Datadog側のインフラでスキャンを走らせる方法です。対応するリポジトリはGitHub（Git Large File Storageを使うリポジトリを除く）、GitLab.comおよびGitLab Self-Managed、Azure DevOps、Bitbucket Cloudです。Azure DevOpsについては「Microsoft Entraテナントに接続されている必要があり、Azure DevOps Serverは対応しない」という条件がドキュメントに明記されています。

GitHubを使う場合、GitHub Appに付ける権限で使える機能が変わります。Content: Read がDatadog上でのコードスニペット表示、Pull Request: Read & Write がプルリクエストへのインラインコメントと修正PRの自動作成、Checks: Read & Write がSAST違反によるプルリクエストのブロックに対応します。マージをブロックするには Checks: Read & Write の権限に加えて、GitHub側で対象のチェックを必須に設定する必要があります。

CIパイプラインでの実行

Datadogホスト型を使わない場合は、datadog-ci CLIをCIの中で実行して結果をアップロードします。APIキーとアプリケーションキーをシークレットとして登録し、アプリケーションキーには code_analysis_read スコープを付けておく必要があります。

# Datadogのサイトと認証情報を設定する
$ export DD_SITE="datadoghq.com"
$ export DD_API_KEY="YOUR_DATADOG_API_KEY"
$ export DD_APP_KEY="YOUR_APP_KEY_WITH_code_analysis_read"

# 解析エンジンを取得して配置する（x86_64 Linuxの例）
$ curl -L https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-unknown-linux-gnu.zip > /tmp/analyzer.zip
$ unzip /tmp/analyzer.zip -d /tmp

# Gitメタデータを先に送ってから解析し、結果をアップロードする
$ npm install -g @datadog/datadog-ci
$ datadog-ci git-metadata upload
$ /tmp/datadog-static-analyzer -i . -g -o /tmp/report.sarif -f sarif --diff-aware
$ datadog-ci sarif upload /tmp/report.sarif

git-metadata upload を静的解析の実行前に挟むのはドキュメントが明示している手順で、解析対象ファイル数の算出にGitメタデータが必要なためです。GitHub・GitLab・Azure DevOps・Bitbucket Cloud以外のソース管理を使っている場合は、結果が表示され始める前に「デフォルトブランチで一度リポジトリ全体の解析を走らせる」必要がある点にも注意してください。

ルールセットを絞る設定ファイル

既定ではリポジトリで検出された言語に対してDatadogの標準ルールセットが有効になります。絞り込みたい場合は、Datadogの画面か code-security.datadog.yaml で設定します。設定は sast キーの下に書き、ファイル先頭には schema-version が必要です。新規に書くなら最新の v1.4 を使います。

schema-version: v1.4
sast:
  use-default-rulesets: true
  ignore-rulesets:
    - ruby-ai_sast
  ruleset-configs:
    javascript-node-security:
      ignore-paths:
        - "**/*.test.js"
  global-config:
    use-gitignore: true
    ignore-generated-files: true
    max-file-size-kb: 200

ignore-rulesets は use-rulesets と use-default-rulesets の両方より優先されます。ルール単位では severity を ERROR／WARNING／NOTICE／NONE から、category を BEST_PRACTICES／CODE_STYLE／ERROR_PRONE／PERFORMANCE／SECURITY から指定できます。個別の行を除外したいだけなら、コード中に no-dd-sa コメント（シークレット検出は no-dd-secrets）を置く方法もあります。

設定の置き場所は3層あり、組織レベル、Datadog上のリポジトリレベル、リポジトリ直下のファイルの順に優先度が上がります。リスト系のフィールドは重複を除いて連結され、真偽値や数値のようなスカラーは優先度が高いほうの値で上書きされるという、型によって違うマージ規則が定義されています。

古い記事や既存リポジトリで static-analysis.datadog.yml を見かけたら、それは旧スキーマです。ドキュメントは「このスキーマは非推奨で新しい更新を受け取らない」と明記し、両方のファイルが存在する場合は code-security.datadog.yaml が優先されるとしています。移行していないリポジトリでは、新しいキーを書いても効かないことになります。

IASTの有効化はトレーサ側

IASTだけは設定場所が違い、アプリケーションの起動オプションか環境変数で有効化します。Javaであればシステムプロパティを渡します。

$ java -javaagent:/path/to/dd-java-agent.jar \
    -Ddd.iast.enabled=true \
    -Ddd.service=my-service -Ddd.env=prod \
    -jar /path/to/app.jar

Node.jsとPythonは環境変数 DD_IAST_ENABLED=true で有効になります。なお、PythonのIASTは実行時にコードを書き換えるため、同様の変換を行うサードパーティライブラリと衝突する可能性があるとドキュメントが警告しています。CやC++で書かれたネイティブモジュール、CPython API、Cythonに強く依存しているコードベースでは、汚染範囲の追跡が正しく伝播せず精度が落ちるとも明記されています。

検出結果の優先順位付けとマージ前のブロック

Datadog Severity Score：静的解析・実行時情報・脅威情報による補正

SCAが扱うライブラリの脆弱性には公開されたCVSSスコアがありますが、Datadogはそれを起点に、リポジトリ側で静的に判定する到達可能性、実行時の稼働状況、外部の脅威情報を合わせて補正した独自スコアを出します。補正要因はドキュメントに表として整理されています。

IASTの場合は自社コードが対象でCVEもCVSSも存在しないため、Datadogが脆弱性の種類ごとに基準重大度を定め、そこに本番稼働の有無と攻撃観測の2要因を掛けて最終スコアを出します。SCAとIASTでスコアの作り方が違う点は、社内でSLAを決めるときに影響します。

脆弱性データベースの鮮度も公開されています。新しい脆弱性が公開されてからDatadogに現れるまでは最大1時間、悪意あるパッケージは6時間以内に報告されるとドキュメントは書いています。出典はNVD、GitHub Advisory Database、osv.dev、PyPAのAdvisory Database、Global Security Database、Datadog GuardDog、Datadogのセキュリティリサーチです。

PR Gatesによるマージのブロック

検出して終わりにしないための仕組みがPR Gatesです。プルリクエスト内の変更をスキャンし、設定した重大度しきい値を超える指摘があればGitHubやAzure DevOpsに失敗ステータスを返します。既定では情報提供のみで、ブロックにするかどうかはリポジトリ側の設定で切り替えます。シークレット検出についてはGitLabもPreviewで対応しています。

脆弱性が閉じる条件

IASTの脆弱性はサービス単位で管理され、閉じるタイミングが2通り定義されています。通常は14日間再検出されなければクローズ、新しいバージョンをデプロイした場合は、元の環境でその新バージョンから検出されなくなってから24時間後にクローズです。さらに、いったん閉じた脆弱性が15か月以内に再検出されると自動で再オープンします。「直したはずの指摘が復活した」ときは、この再オープンの挙動を疑ってください。

サプライチェーン保護：インストール時点のブロック

Preview提供のSupply Chain Securityは、他の機能と発想が違います。リポジトリに入ったあとのライブラリを調べるSCAに対し、Datadog Supply Chain Firewall（SCFW）は npm・pip・poetry のコマンドを実行時にインターセプトし、悪意あるパッケージや公開されたばかりのパッケージをインストール前にブロックします。判定にはDatadogの悪意あるパッケージフィード（GuardDogが元になっています）、既知の脆弱性アドバイザリ、設定可能な新しさのしきい値を使います。

SCFWとGuardDog、そしてSASTの解析エンジンはいずれもGitHubで公開されています。2026年9月18日時点で3つともApache-2.0ライセンスで、DataDog/datadog-static-analyzer の最新リリースは0.9.7（2026年9月16日公開）、DataDog/supply-chain-firewall はv4.0.0（2026年8月13日公開）でした。判定ロジックを自分で確認したい場合はこれらのリポジトリが一次情報になります。

AIコーディング支援からの直接スキャン

もうひとつPreview提供なのがCode Security MCP Serverです。こちらはローカルで動くModel Context Protocolサーバーで、公開ツールは datadog_secrets_scan、datadog_sca_scan、datadog_iac_scan、datadog_generate_sbom の4つです。Claude Code、Claude Desktop、Cursor、Visual Studio Codeの設定例がドキュメントに用意されています。IaCの指摘については、Datadogの画面から修正プロンプトをコピーしてコーディングエージェントに渡す、あるいはCursorのディープリンクで直接開くという導線も用意されています。

よくある質問（FAQ）

Datadog Code SecurityにDASTは含まれますか？

Code Securityのドキュメントが列挙する6機能にDAST（動的アプリケーションセキュリティテスト）はありません。稼働中アプリを外部から叩く方式ではなく、IASTが「正規のアプリケーショントラフィックの検査に依拠する」方式を採っている点がドキュメントで対比されています。外部からエンドポイントの到達性や認証を能動的に検証したい場合は、App and API Protection側のEndpoint Scanningが近い役割を担います。ただしPreview機能で、AAPがAPMトレースから発見したエンドポイントにGETリクエストを送る方式のため、汎用のDASTの代わりにはなりません。

SASTだけを単体で契約できますか？

できます。料金ページにはStatic Code Analysis（SAST）が単体プランとして掲載されており、年間契約でコミッターあたり月25ドルです。静的SCA、Secret Scanning、IaC Securityもそれぞれ単体プランがあり、4つの年間契約単価を足すとコミッターあたり月80ドルです。ただし40ドルのバンドルについて料金ページのFAQが構成要素として挙げているのはSAST・IAST・SCA（静的とランタイム）で、Secret ScanningとIaC Securityが含まれるかは同ページからは読み取れません。金額だけでなく契約対象の機能を確認してから比較してください。

IASTはGoやRubyのサービスでも使えますか？

使えません。互換性要件の表でGo・Ruby・PHPのIAST欄は「not supported」と明記されています。これらの言語では、ライブラリの脆弱性を実行時に検出するランタイムSCA（必要なDatadog SDKの最低バージョンはGo向け1.49.0、Ruby向け1.11.0、PHP向け0.90.0。言語処理系自体のバージョンではありません）と、リポジトリ側のSASTを組み合わせる構成になります。SASTはGoとRubyの両方に対応しています。

Datadog Agentは必須ですか？

機能によります。SASTと静的SCAはDatadog SDKを必要とせず、リポジトリ連携かCIパイプラインだけで動きます。IASTとランタイムSCAはDatadog SDKを使い、IASTのセットアップ手順はDatadog Agent 7.41.1以上を指定しています。ランタイムSCAのAgent要件は言語ごとの互換性要件で確認してください。APMそのものを使っていなくてもIASTは動きますが、セキュリティ用のトレースとスパンを取り込むためのAPM intake費用は発生します。

Code SecurityとApp and API Protectionはどちらを先に入れるべきですか？

目的で分かれます。開発段階で脆弱性を潰したいならCode Security、すでに公開しているアプリへの攻撃を検知・遮断したいならAAPです。AAPのExploit Preventionが使うRASPは、脆弱性が残っている状態での緊急的な緩和策として機能する一方、根本の修正はCode Security側の指摘を潰す作業になります。順序を決めるうえでは、脆弱性診断全体の中での位置づけを整理した脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界もあわせて確認してください。

関連記事

• Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け：本記事ではDatadogの実装に絞ったSAST・IAST・SCAという手法そのものの違いと、診断項目の考え方を扱っています。
• Datadogとは何か？機能やメリット、導入の背景を詳しく解説：Code Securityの前提になるDatadogプラットフォーム全体の機能構成をまとめています。
• TerraformでDatadogを管理する方法｜Provider設定・モニター・AWSインテグレーション実践ガイド：IaC Securityがスキャンする側のTerraform定義を、Datadog自体の管理に使う方法です。
• CI Visibilityとは何か? 仕組みとメリットから見るCI/CDパイプライン可視化の基本概念：Code SecurityのスキャンをCIに組み込む際、パイプライン自体の可視化をどう設計するかの参考になります。
• Datadog MCP Serverの接続手順｜toolsets選択と権限スコープの設計：本記事で触れたローカル型のCode Security MCP Serverとは別の、Datadog本体を操作するリモート型MCP Serverの接続手順です。