---
title: "Datadog Code Securityとは｜6機能・対応言語・3つのバンドル料金とSASTの実行例"
url: "https://www.issoh.co.jp/tech/details/8043/"
published: 2025-08-05
updated: 2026-11-06
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Datadog Code Securityとは｜6機能・対応言語・3つのバンドル料金とSASTの実行例

Datadog Code Securityは、自社で書いたコードとアプリケーションが使うオープンソースライブラリを、リポジトリと稼働中のサービスの両方でスキャンする機能群です。単体の製品というより、静的解析（SAST）、ソフトウェア構成分析（SCA）、実行時コード解析（IAST）、シークレット検出、IaCの設定ミス検出、悪性パッケージのインストール阻止という6機能の総称だと捉えると全体が見えます。

この記事は2026年11月6日時点の[Datadog公式ドキュメント](https://docs.datadoghq.com/security/code%5Fsecurity/)と料金ページ、GitHubで公開されている解析エンジンの実行結果をもとに、機能の守備範囲、対応言語の差、課金単位、導入と設定までを整理します。SAST・DAST・IASTという手法そのものの選び分けは[Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け](/column/details/2485/)で扱っているので、ここではDatadogの実装に絞ります。

## まとめ：Datadog Code Securityの要点

- **機能は6つ**。Static Code Analysis（SAST）、Software Composition Analysis（SCA）、Runtime Code Analysis（IAST）、Secret Scanning、IaC Security、Supply Chain Firewall（Preview）です。DASTは含まれません。
- **対応言語は機能ごとに違います**。SASTはルール一覧で15言語、IASTはJava・.NET・Node.js・Pythonの4言語だけで、Go・Ruby・PHPは対象外です。
- **課金単位は2系統**。リポジトリを見る静的系はコミッター単位、稼働中サービスを見る実行時系はホスト単位です。バンドルはCore（40ドル）・Flex（48ドル）・Advanced（55ドル）の3種類で、Secret ScanningとIaC Securityが入るかどうかで分かれます。
- **SDKが要るのは実行時系だけ**。SASTと静的SCAはリポジトリ連携かCIだけで動き、静的解析エンジンはAPIキー無しでも手元で実行できます。
- **設定ファイルは `code-security.datadog.yaml` で、新規は `schema-version: v1.7`**。1つのファイルに `sast`・`sca`・`iac`・`secrets` の4セクションを書けます。
- **攻撃の遮断は別製品**。In-App WAFやRASPはApp and API Protection（AAP）、ホストのEDR的な検知はWorkload Protectionの担当です。

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

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

| 機能                                 | 何を見るか              | 対象             | 提供状態    |
| ---------------------------------- | ------------------ | -------------- | ------- |
| Static Code Analysis（SAST）         | 自社コードの脆弱性と品質       | リポジトリ          | 提供中     |
| Software Composition Analysis（SCA） | OSSライブラリの脆弱性とライセンス | リポジトリ＋稼働中サービス  | 提供中     |
| Runtime Code Analysis（IAST）        | 稼働中サービス内の自社コード     | 稼働中サービス        | 提供中     |
| Secret Scanning                    | 漏えいした認証情報と有効性      | リポジトリ（Git履歴含む） | 提供中     |
| IaC Security                       | インフラ定義の設定ミス        | リポジトリ          | 提供中     |
| Supply Chain Firewall              | 悪性パッケージのインストール     | 開発端末・CI        | Preview |

6番目の機能は、2026年9月時点のドキュメントではSupply Chain Securityと書かれていましたが、現在はSupply Chain Firewall（SCFW）という製品名で載っています。このほか、ローカルで動くCode Security MCP Serverと、プルリクエストの悪意ある変更を検出するMalicious PR protectionがPreviewとして追加されています。

### 静的スキャンと実行時検出の分かれ方

検出系の機能は、リポジトリを静的に解析するものと、稼働中サービスを実行時に解析するものに分かれます。SASTはスキャン対象リポジトリへのコミットごとに走り、静的SCAは依存関係ファイルが更新されたコミットで走ります。実行時側はDatadogのトレーシングライブラリ（SDK）を通じて、IASTがデータの流れを、ランタイムSCAが実際に読み込まれたライブラリを調べます。

この分かれ方は導入にも料金にも効きます。[IASTのセットアップページ](https://docs.datadoghq.com/security/code%5Fsecurity/iast/setup/)は「Static Software Composition Analysis（SCA）とStatic Code Analysis（SAST）はDatadog SDKを必要としない」と明記しています。APMを入れていない環境でまずコードの脆弱性だけを見たいなら、SDKを足さずに始められるSASTと静的SCAから入るのが手堅い選択です。

### App and API Protection・Workload Protectionとの線引き

WAFによる攻撃の検知と遮断は、App and API Protection（AAP）の担当です。[AAPのドキュメント](https://docs.datadoghq.com/security/application%5Fsecurity/)は冒頭で「Formerly known as Application Security Monitoring (ASM)」と旧称を示し、In-App WAF、API探索とポスチャ管理、実行時の脅威検知を担うと説明しています。検索で見かける「Datadog RASP」もこちら側で、AAPのExploit Preventionがリクエストが脆弱なコードパスに触れたかを判定してブロックします。

「Datadog EDR」で探しているなら、近いのはCloud Security側のWorkload Protectionです。ドキュメントはファイル・ネットワーク・プロセスの活動を継続監視してリアルタイムに脅威を検出する製品と説明しており、Linuxでは eBPF を使うAgentで収集します。Code Securityは「脆弱性を見つけて直す」側、AAPとWorkload Protectionは「攻撃を検知して止める」側です。両者の役割分担の考え方は[脆弱性対応の自動化｜情報収集・優先順位付け・修正・検証で任せる範囲と人が残す判断](/column/details/2372/)も参考になります。

## 機能ごとに異なる対応言語

導入を検討するときに最初に確かめるべきなのが、自社のスタックが各機能の対応表のどこに入るかです。ここは機能ごとに差が大きく、「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ページ](https://docs.datadoghq.com/security/code%5Fsecurity/static%5Fanalysis/static%5Fanalysis%5Frules/)に並ぶルールセットは56個で、言語別に数えると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があります。[AI-Enhanced Static Code Analysisのページ](https://docs.datadoghq.com/security/code%5Fsecurity/static%5Fanalysis/ai%5Fenhanced%5Fsast/)によると、1つ目のLLMがファイルごとに「ユーザー入力が無害化されずに危険な処理へ届くか」を推論し、2つ目のLLMが候補を独立に再評価して誤検知を落とす二段構えです。対応はC#、C++、Dart、Elixir、Go、Java、JavaScript、Kotlin、PHP、Python、Ruby、Rust、Swift、TypeScriptの14言語で、従来のルールセットに無いC++が入る一方でApexは含まれません。有効化はソースコード管理の連携設定にある「Enable AI SAST」のトグルで行い、ルール型と並行して走り、両方が扱う脆弱性の種類ではAI-native側の結果が優先されます。

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

IASTの互換性要件の表では、Go・Ruby・PHPの欄が「not supported」です。しかも同じ4言語の中でも、検出できる脆弱性の種類が揃っていません。[IASTのページ](https://docs.datadoghq.com/security/code%5Fsecurity/iast/)にある検出ルール表（全35ルール）から、Criticalと主要なHighの行を抜き出すと次のとおりです。

| 検出ルール                     | 重大度      | Java | .NET | Node.js | Python |
| ------------------------- | -------- | ---- | ---- | ------- | ------ |
| SQL Injection             | Critical | 対応   | 対応   | 対応      | 対応     |
| Command Injection         | Critical | 対応   | 対応   | 対応      | 対応     |
| SSRF                      | Critical | 対応   | 対応   | 対応      | 対応     |
| NoSQL Injection           | Critical | 非対応  | 対応   | 対応      | 非対応    |
| Code Injection            | Critical | 非対応  | 非対応  | 対応      | 非対応    |
| Cross-Site Scripting      | High     | 対応   | 対応   | 非対応     | 非対応    |
| Untrusted Deserialization | High     | 対応   | 非対応  | 非対応     | 非対応    |
| Path Traversal            | High     | 対応   | 対応   | 対応      | 対応     |
| Hardcoded Secrets         | High     | 対応   | 対応   | 対応      | 非対応    |

35ルールのうちJavaが対応するのは31ルールですが、Pythonは11ルールにとどまり、クロスサイトスクリプティングも信頼されないデシリアライゼーションも検出しません。Python中心のチームがIASTだけで本番の自社コードを網羅するのは無理があり、SASTの `python-security` 系ルールセットと組み合わせるのが前提になります。

Datadogは2024年5月1日のブログで、IASTがOWASP Benchmarkで精度100%を出したと発表しています。ただし同記事の注記どおり、このベンチマークはJavaのテストスイート（約3,000ケース・11カテゴリ）です。PythonやNode.jsで同じ精度が出ることを示したものではない点は割り引いて読んでください。

### IASTとランタイムSCAに必要なSDKのバージョン

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

| 機能       | Java   | .NET   | Node.js | Python | Go     | Ruby   | PHP    |
| -------- | ------ | ------ | ------- | ------ | ------ | ------ | ------ |
| ランタイムSCA | 1.1.4  | 2.16.0 | 4.0.0   | 1.5.0  | 1.49.0 | 1.11.0 | 0.90.0 |
| IAST     | 1.15.0 | 2.42.0 | 4.18.0  | 3.18.0 | 非対応    | 非対応    | 非対応    |

Node.jsは条件が二段構えで、原文は「4.18.0 for Node.js 16+, or 5.0.0 for Node.js 18+」です。さらに、すべての機能を使える下限は「4.30.0 for Node.js 16+ and 5.0.0 for Node.js 18+」と別に書かれています。IASTのセットアップ手順はDatadog Agent 7.41.1以上を指定し、書き込み可能な `/tmp` が必要で読み取り専用ファイルシステムは非対応です。AWS LambdaではNode.jsのIASTが非対応、FargateはPreview扱いと、デプロイ形態でも差があります。

### 静的SCAが読むファイルとロックファイルの優先

静的SCAはソースコードではなく依存関係ファイルを解析します。[静的SCAのセットアップページ](https://docs.datadoghq.com/security/code%5Fsecurity/software%5Fcomposition%5Fanalysis/setup%5Fstatic/)の対応表は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行です。

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

## 料金：コミッター単位・ホスト単位と3つのバンドル

2026年11月6日に取得した[米国向け料金ページ](https://www.datadoghq.com/pricing/?product=code-security)から、Code Security関連のプランを抜き出したのが次の表です。年間契約は年払い時の月額単価、オンデマンドは従量の単価です。

| プラン                                     | 課金単位    | 年間契約 | オンデマンド  |
| --------------------------------------- | ------- | ---- | ------- |
| Static Code Analysis（SAST）              | コミッター／月 | 25ドル | 36ドル    |
| Software Composition Analysis（静的SCA）    | コミッター／月 | 25ドル | 36ドル    |
| IaC Security                            | コミッター／月 | 15ドル | 22ドル    |
| Secret Scanning                         | コミッター／月 | 15ドル | 22ドル    |
| Runtime Code Analysis（IAST）             | ホスト／月   | 20ドル | 29ドル    |
| Software Composition Analysis（ランタイムSCA） | ホスト／月   | 10ドル | 15ドル    |
| Core Bundle                             | コミッター／月 | 40ドル | 57.60ドル |
| Flex Bundle（Secrets）                    | コミッター／月 | 48ドル | 70ドル    |
| Advanced Bundle                         | コミッター／月 | 55ドル | 80ドル    |

バンドルの違いはSecret ScanningとIaC Securityが入るかどうかです。Flex Bundleは「Everything in Core Bundle」にSecret Scanningを加えたもの、Advanced BundleはさらにIaC Securityを加えたものと明記されています。CoreはFAQが構成要素として挙げるSAST・IAST・SCA（静的とランタイム）の4つです。

### バンドルと単体購入の費用比較

静的系だけで比べると、SAST＋静的SCA＋Secret Scanning＋IaC Securityの単体合計は年間契約でコミッターあたり月80ドル、Advanced Bundleは55ドルです。さらにバンドルの実行時系についてFAQは「Runtime SCAとIASTはDatadog Agentが入っている任意のホストで使える」と回答しており、単体購入なら別立てになるホスト課金がかかりません。逆に、SASTしか使わないチームなら単体の25ドルが最安です。

オンデマンドの扱いにも注意が要ります。FAQによると、バンドルのオンデマンド単価が適用されるのは契約数を超えた分だけで、たとえば20コミッターで契約して25人使えば、5人分がオンデマンドのバンドル単価になります。バンドルを契約していないまま4つの機能をオンデマンドで有効にすると、バンドル単価ではなく各製品のオンデマンド単価で別々に請求されます。

### コミッターとホストの数え方

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

IASTとランタイムSCAの課金ホストは、機能が有効で、かつスパンをDatadogへ送っているホストです。APMやインフラ監視の契約は要りませんが、FAQは「APMを無効にしていても、IASTのためのセキュリティトレースやスパンの取り込みにはAPM intakeの費用がかかる」と明記しています。

## 静的解析エンジンのローカル実行と検出結果

SASTの解析エンジン `datadog-static-analyzer` はApache-2.0でGitHubに公開されています。2026年11月4日（UTC）公開の0.9.11（macOS x86\_64版）を取得し、2026年11月6日にmacOS 26.6.2のIntel Mac上で、Datadogの環境変数を何も設定しない状態で実行しました。解析対象は、SQLインジェクションとコマンドインジェクションを含む次のFlaskのコード（`repo/app.py`）1ファイルだけのリポジトリです。

```
import sqlite3, subprocess, hashlib
from flask import Flask, request
app = Flask(__name__)

@app.route("/user")
def user():
    conn = sqlite3.connect("db.sqlite")
    name = request.args.get("name")
    cur = conn.execute("SELECT * FROM users WHERE name = '%s'" % name)
    return str(cur.fetchall())

@app.route("/ping")
def ping():
    host = request.args.get("host")
    return subprocess.check_output("ping -c 1 " + host, shell=True)

def digest(p):
    return hashlib.md5(p.encode()).hexdigest()
```

リポジトリ直下に設定ファイル `repo/code-security.datadog.yaml` を置き、ルールセットを2つに絞って実行した結果が次のとおりです。

```
# 解析対象repoの直下に置いた設定を表示する
$ cat repo/code-security.datadog.yaml
schema-version: v1.7
sast:
  use-default-rulesets: false
  use-rulesets:
    - python-security
    - python-flask

# APIキー無しでそのまま実行する
$ ./datadog-static-analyzer -i repo -o out.json -f json --print-violations
config method             : local configuration file (yaml)
#static analysis rules    : 47
 rule                                              location     severity  message
 python-security/insecure-hash-functions           18:12-18:35  warning   Use of insecure hashing method md5
 python-security/subprocess-shell-true             15:57-15:62  warning   shell set to true
 python-security/variable-sql-statement-injection  9:24-9:63    error     Potential SQL injection
 python-flask/command-injection                    15:36-15:55  error     Command injection vulnerability: user input concatenated into shell command.
```

ルールは実行時にDatadogから取得されるため、ルール数や検出結果は取得する時点で変わることがあります。この日の取得では2ルールセットで47ルール、解析は0.91秒でした。設定ファイルを置かずに実行すると既定のルールセットが読み込まれ、ルール数は1,094、言語はDart・Ruby・Python・Kotlin・Go・TypeScript・JavaScript・C#・Bash・PHP・Java・Rustの12でした。Apex・Elixir・Swiftのルールセットは既定に入っていないので、これらの言語は `use-rulesets` で明示しないと検査されません。

CIで止める用途では `--fail-on-any-violation error` を付けます。上の例ではerrorが2件あるため終了コードは10で返りました。SARIFで出力すると、md5の指摘に「use sha256 instead」という修正案（`hashlib.sha256` への置換範囲つき）が入っていました。指摘を1行だけ除外したいときは、直前の行に `no-dd-sa:python-security/variable-sql-statement-injection` とコメントを書くと、その行の指摘だけが消えることも確認できました。

なお、`schema-version` に存在しない `v1.9` を書いても、0.9.11は警告を出さずに実行しました。この検証ではv1.9の指定ミスを検出できなかったため、実行成功だけで設定の妥当性を判断せず、公式リファレンスの対応版と項目を照合してください。

## 導入の2経路：Datadogホスト型スキャンとCI

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

手数がもっとも少ないのは、Datadog側でスキャンを走らせる方法です。[SASTのセットアップページ](https://docs.datadoghq.com/security/code%5Fsecurity/static%5Fanalysis/setup/)が挙げる対象は、GitHub（Git Large File Storageを使うリポジトリを除く）、GitLab.comとGitLab Self-Managed、Azure DevOps、Bitbucket Cloudです。Azure DevOpsは「Microsoft Entraテナントに接続されている必要があり、Azure DevOps Serverは対応しない」と条件が付いています。Secret Scanningのホスト型スキャンはGitHub・Azure DevOps・GitLabが対象で、Bitbucket Cloudは挙がっていません。

GitHubではGitHub Appに付ける権限で使える機能が変わります。`Content: Read` がDatadog上のコードスニペット表示、`Pull Request: Read & Write` がプルリクエストへのインラインコメントと修正PRの作成、`Checks: Read & Write` が違反によるプルリクエストのブロックに対応します。

### CIパイプラインでの実行

ホスト型を使わない場合は、CIの中で解析エンジンを動かし、`datadog-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以外のソース管理を使う場合は、結果が出始める前にデフォルトブランチで一度リポジトリ全体を解析する必要があります。サードパーティのSAST結果も、SARIF 2.1.0形式なら同じ `datadog-ci sarif upload` で取り込めます。

### code-security.datadog.yamlの設定項目と優先順位

既定ではリポジトリで検出された言語の標準ルールセットが有効になります。絞り込みは、Datadogの画面か `code-security.datadog.yaml` で行います。[設定リファレンス](https://docs.datadoghq.com/security/code%5Fsecurity/guides/configuration/)は「新規の設定にはすべて `schema-version: v1.7` を使う」としており、版ごとに追加された内容は次のとおりです。

| schema-version | 追加された内容                      |
| -------------- | ---------------------------- |
| v1.0           | SASTの設定                      |
| v1.1           | SCAのパス除外                     |
| v1.2           | IaC Securityの設定              |
| v1.3           | IaCのルール単位設定                  |
| v1.4           | IaCルールの `arguments`          |
| v1.5           | Secret Scanningの対象ファイル設定     |
| v1.6           | Secret ScanningのAST絞り込み（実験的） |
| v1.7           | SCAのエコシステム・パッケージ除外           |

SCAのパス除外はv1.1から設定でき、Secret Scanningの対象ファイル設定はv1.5、SCAのエコシステム・パッケージ除外はv1.7で追加されました。SASTとSCAをまとめると次のとおりです。

```
schema-version: v1.7
sast:
  use-default-rulesets: true
  ignore-rulesets:
    - ruby-ai_sast
  ruleset-configs:
    javascript-node-security:
      ignore-paths:
        - "**/*.test.js"
  global-config:
    use-gitignore: true
    max-file-size-kb: 200
sca:
  ignore-paths:
    - "vendor/"
  ignore-packages:
    - "npm:lodash"
```

`ignore-rulesets` は `use-rulesets` と `use-default-rulesets` より優先されます。`use-default-rulesets: false` にするとAI-native SASTのルールセット（`<言語>-ai_sast`）も止まるので、使うものはすべて列挙します。SCAの `ignore-ecosystems` と `ignore-packages` は大文字小文字を区別し、`go:golang.org/x/text` は `Go` エコシステムに一致しないとドキュメントが警告しています。

設定の置き場所は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++のネイティブモジュールやCythonに強く依存するコードでは汚染追跡が正しく伝わらないことがドキュメントに注意書きされています。

## Secret Scanning：Git履歴まで遡る検出

[Secret Scanningのページ](https://docs.datadoghq.com/security/code%5Fsecurity/secret%5Fscanning/)によると、ホスト型スキャンでリポジトリを初めてスキャンしたときに限り、全ブランチのGit履歴もさかのぼって調べます。最新のデフォルトブランチから消えている秘密情報は「Detected in Git History」という履歴のみの検出として表示され、導入時に、Git履歴に残り、スキャン対象と検出ルールに該当する鍵を検出できます。

この履歴のみの検出は、後のスキャンで自動的には閉じません。ドキュメントは「Git履歴を書き換えても閉じない。認証情報をローテーションまたは失効させてからミュートする」と書いています。履歴から消すことより鍵を無効にすることが先、という順序を運用手順に入れておくべきです。CIでのスキャンは対象コミットだけを見るので、履歴の洗い出しはホスト型の初回にしか起きません。

ほかにも運用上の注意があります。SASTにある差分スキャン（diff-aware）はSecret Scanningでは使えず、毎回スキャン対象ファイルの全体を読みます。検出した鍵の一部は第三者サービスに問い合わせて有効か無効かを判定します。プロバイダ固有のパターンに当たらない社内トークンやパスワードを探すGeneric Secret ScanningはPreviewです。コミットやpushの前に手元で止めたい場合は、解析エンジンと同じリリースにある `datadog-static-analyzer-git-hook` を `pre-push` フックに組み込めます。

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

### Datadog Severity Scoreの補正要因

SCAが扱うライブラリの脆弱性には公開のCVSSスコアがありますが、Datadogはそれを起点に補正した独自スコアを出します。補正要因は、脆弱な関数がコードから参照されているか（到達可能性・該当すれば上がる）、本番で稼働しているか、攻撃が観測されているか、公開エクスプロイトがあるか、EPSSによる悪用確率の5つで、到達可能性以外はいずれも該当しなければスコアが下がる方向に働きます。

IASTの指摘は自社コードが対象なのでCVEもCVSSもありません。Datadogが脆弱性の種類ごとに基準重大度を決め、本番稼働の有無と攻撃観測の2要因で補正します。攻撃観測は「直近15日以内にそのサービスでセキュリティシグナルが出たか」で判定されます。SCAとIASTでスコアの作り方が違うので、社内で対応期限（SLA）を決めるときは同じ数字として扱わないでください。脆弱性データベースは、新しい脆弱性の公開からDatadogへの反映まで最大1時間、悪性パッケージは6時間以内とされています。

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

[PR Gates](https://docs.datadoghq.com/pr%5Fgates/)は、プルリクエストで新たに持ち込まれた違反だけを対象に条件を当て、合否をソース管理側のチェックとして返す仕組みです。条件はSASTの脆弱性と品質違反、SCAのライブラリ脆弱性と禁止ライセンス、IaCの脆弱性、漏えいした秘密情報に加え、コードカバレッジと新しいフレーキーテストにも設定できます。チェックを作れるのはGitHub、GitLab、Azure DevOps、Bitbucket Cloudの4つです。

既定のチェックは情報提供のみです。ブロックにするには、GitHub・Azure DevOpsではブランチポリシーで必須チェックにし、Bitbucket CloudではPremiumプランでマージチェックを必須化し、GitLabではDatadogのサービスアカウントをマージリクエストの必須承認者に設定します。制約としてドキュメントは、フォーク元から本体リポジトリへのプルリクエストは対象外であること、マージキューを使うGitHubリポジトリではPR Gatesを必須に設定できないことを警告しています。OSSのようにフォーク経由の貢献が多いリポジトリや、マージキューを使っているリポジトリでは、PR Gatesだけを最後の防衛線にする設計は成り立ちません。

### IASTの脆弱性が閉じる条件

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

## サプライチェーンとAIコーディング支援への対応

### Supply Chain Firewall v4.0.0での作り直し

Supply Chain Firewall（SCFW）は、リポジトリに入った後の依存関係を調べるSCAと違い、`npm`・`pip`・`poetry` のインストールコマンドを包んで、悪性または改ざんされたパッケージをインストール前にブロックします。対象はnpm 7.0以降の `install`、pip 22.2以降の `install`、poetry 1.7以降の `add`・`install`・`sync`・`update` です。2026年8月13日公開のv4.0.0で中身が大きく変わり、リリースノートには次の変更が並んでいます。

- Pythonパッケージから、Goで書かれた単体バイナリに置き換えた（`pip`／`pipx` での導入は不要）
- OSVや公開からの日数などによるローカル判定をやめ、Datadogの脅威インテリジェンスと組織のCode Securityポリシーで判定するようにした。そのため評価付きのインストールにはDatadogの認証情報が必須
- コマンド構文を `scfw run -- <command>` と区切り必須に変更し、`scfw audit` や `--dry-run` を削除

v3以前の記事にある「Datadogアカウントなしで使えるOSSのファイアウォール」という説明は、v4.0.0以降には当てはまりません。判定の根拠になる悪性パッケージのデータセットは `DataDog/malicious-software-packages-dataset` として公開されています。

### Malicious PR protectionとAIによる修正

Preview提供のMalicious PR protectionは、デフォルトブランチ宛てのプルリクエストをLLMで調べ、コードインジェクション、秘密情報の持ち出し、悪性パッケージの公開、CIワークフローの乗っ取りといった変更を検出します。対象はGitHubリポジトリのみです。ドキュメントは想定例として、2025年3月のtj-actions/changed-files侵害を挙げています。検出結果はSecurity Signalsに `source:datadog-code-security` として現れます。

検出後の工程では、ホスト型スキャン限定の誤検知フィルタ（注入系の一部ルールはファイル横断の文脈を使うエージェント型）と、Bits Codeによる修正案の生成が用意されています。

### Code Security MCP Serverのツールと認証要件

Code Security MCP ServerはSTDIOで動くローカルのMCPサーバーで、Claude Code、Claude Desktop、Cursorなどから呼び出します。[MCP Serverのページ](https://docs.datadoghq.com/security/code%5Fsecurity/dev%5Ftool%5Fint/mcp%5Fserver/)に並ぶツールは9本で、2026年9月時点の4本（シークレット・SCA・IaCのスキャンとSBOM生成）から増えています。

| ツール                                  | 内容                       | 認証 |
| ------------------------------------ | ------------------------ | -- |
| `datadog_code_security_scan`         | SAST・シークレット・SCA・IaCを並列実行 | 要  |
| `datadog_sast_scan`                  | SAST                     | 要  |
| `datadog_secrets_scan`               | ハードコードされた秘密情報            | 要  |
| `datadog_sca_scan`                   | 依存関係の脆弱性                 | 要  |
| `datadog_iac_scan`                   | IaCの設定ミス                 | 要  |
| `datadog_generate_sbom`              | SBOM生成                   | 不要 |
| `datadog_library_vulnerability_scan` | パッケージURLで脆弱性を照会          | 要  |
| `datadog_ephemeral_sast_scan`        | 未公開のSASTルール1本で手元を検査      | 不要 |
| `datadog_promote_sast_rule`          | 承認したルールをカスタムルールとして登録     | 要  |

後ろの2本は、手元で直した脆弱性から一時的なルールを書き、同じ型の問題がリポジトリの他の場所に無いかを探してから、承認したルールを保存する流れのためのものです。Datadogに既に上がっている検出結果を問い合わせたいときは、このローカル型ではなく、リモート型のDatadog MCP Serverで `security` ツールセットを使うようにドキュメントが案内しています。リモート型の接続手順は[Datadog MCP Serverの接続手順｜toolsets選択と権限スコープの設計](/tech/details/16586/)で解説しています。

Code Securityは自社コードの欠陥を開発段階で潰す道具で、外部から稼働中のアプリケーションを叩いて確かめる診断の代わりにはなりません。公開前やリリース後に第三者の目で確かめたい場合は、[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)のような外部診断と組み合わせて計画してください。

## よくある質問（FAQ）

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

含まれません。ドキュメントが挙げる6機能にDASTはなく、IASTは外部からのテストではなく「正規のアプリケーショントラフィックの検査に依拠する」方式だと対比されています。エンドポイントの到達性や認証を能動的に確かめる機能としては、App and API Protection側にEndpoint Scanningがあります。

### Datadog Code Securityの料金はいくらですか？

米国向けの年間契約で、SASTと静的SCAがコミッターあたり月25ドル、Secret ScanningとIaC Securityが15ドル、IASTはホストあたり20ドル、ランタイムSCAは10ドルです。バンドルはCore 40ドル、Secret Scanningを足したFlex 48ドル、さらにIaC Securityを足したAdvanced 55ドルで、いずれもコミッター単位です。コミッターは月3回以上コミットした人だけが数えられます。

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

使えません。互換性要件の表でGo・Ruby・PHPのIASTは「not supported」です。これらの言語では、ライブラリの脆弱性を実行時に拾うランタイムSCA（SDKの下限はGo 1.49.0、Ruby 1.11.0、PHP 0.90.0）と、リポジトリ側のSASTを組み合わせます。SASTはGo・Ruby・PHPのいずれにもルールセットがあります。

### Datadog Agentは必須ですか？

機能によります。SASTと静的SCAはSDKもAgentも要らず、リポジトリ連携かCIだけで動きます。IASTとランタイムSCAはAgentとSDKが必要で、IASTの手順はAgent 7.41.1以上を指定しています。APMの契約は不要ですが、セキュリティ用のトレースとスパンの取り込みにはAPM intakeの費用がかかります。

### Datadog EDRとCode Securityは何が違いますか？

対象が違います。DatadogでEDRに近い役割を持つのはWorkload Protectionで、ホストやコンテナのファイル・ネットワーク・プロセスの動きを監視して実行中の脅威を検出します。Code Securityはコードと依存関係の脆弱性を見つける製品で、侵入や不審なプロセスは検出しません。料金ページでもWorkload ProtectionはCloud Security側の項目として載っています。

## 関連記事

- [Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け](/column/details/2485/)
- [Datadogとは？何ができるか・仕組み・料金とCloudWatch/Zabbixとの違い](/tech/details/6476/)
- [TerraformでDatadogを管理する方法｜Provider v4の設定・モニター・AWS連携](/tech/details/10105/)
- [Datadog CI Visibilityとは？対応CI9種の設定手順・料金とCI/CD Optimizationの機能](/tech/details/10333/)
- [Datadog MCP Serverの接続手順｜toolsets選択と権限スコープの設計](/tech/details/16586/)

---

出典: [Datadog Code Securityとは｜6機能・対応言語・3つのバンドル料金とSASTの実行例](<https://www.issoh.co.jp/tech/details/8043/>)（株式会社一創）