概要

Datadog SAST をアプリ内で設定するには、Security > Code Security に移動します。

Static Code Analysis スキャンの実行場所を選択

Datadog ホスト型スキャンでスキャンする

Datadog のインフラストラクチャー上で直接 Datadog Static Code Analysis (SAST) スキャンを実行できます。サポートされているリポジトリタイプには以下が含まれます。

• GitHub (Git Large File Storage を使用しているリポジトリを除く)
• GitLab.com および GitLab Self-Managed
• Azure DevOps

始めるには、Code Security ページに移動します。

CI パイプラインでスキャンする

Datadog Static Code Analysis は、datadog-ci CLI を使用して CI パイプラインで実行されます。

まず、Datadog の API キーとアプリケーションキーを構成します。DD_APP_KEY とDD_API_KEY をシークレットとして追加します。Datadog のアプリケーションキーに code_analysis_read スコープがあることを確認してください。

次に、選択した CI プロバイダーの以下の手順に従って Static Code Analysis を実行します。

ソースコード管理プロバイダーを選択する

Datadog Static Code Analysis は、すべてのソースコード管理プロバイダーをサポートしており、GitHub、GitLab、および Azure DevOps に対してネイティブサポートを提供しています。

構成をカスタマイズする

デフォルトでは、Datadog Static Code Analysis (SAST) は、各プログラミング言語の Datadog のデフォルトルールセットを使用してリポジトリをスキャンします。Datadog または code-security.datadog.yaml ファイル内で、実行するルールセットやルール、その他のパラメーターをカスタマイズできます。完全な構成リファレンスについては、Static Code Analysis (SAST) 構成を参照してください。

Datadog のサービスとチームに発見をリンクする

Datadog associates code and library scan results with Datadog services and teams to automatically route findings to the appropriate owners. This enables service-level visibility, ownership-based workflows, and faster remediation.

To determine the service where a vulnerability belongs, Datadog evaluates several mapping mechanisms in the order listed in this section.

Each vulnerability is mapped with one method only: if a mapping mechanism succeeds for a particular finding, Datadog does not attempt the remaining mechanisms for that finding.

Mapping using the Software Catalog (recommended)

Services in the Software Catalog identify their codebase content using the codeLocations field. This field is available in the Software Catalog schema version v3 and allows a service to specify:

• a repository URL

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git

• one or more code paths inside that repository

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**

If you want all the files in a repository to be associated with a service, you can use the glob ** as follows:

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

The schema for this field is described in the Software Catalog entity model.

Datadog goes through all Software Catalog definitions and checks whether the finding’s file path matches. For a finding to be mapped to a service through codeLocations, it must contain a file path.

Some findings might not contain a file path. In those cases, Datadog cannot evaluate codeLocations for that finding, and this mechanism is skipped.

Example (v3 schema)

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

SAST finding

If a vulnerability appeared in github.com/org/myrepo at /src/billing/models/payment.py, then using the codeLocations for billing-service Datadog would add billing-service as an owning service. If your service defines an owner (see above), then Datadog links that team to the finding too. In this case, the finding would be linked to the billing-team.

SCA finding

If a library was declared in github.com/org/myrepo at /go.mod, then Datadog would not match it to billing-service.

Instead, if it was declared in github.com/org/billing-service at /go.mod, then Datadog would match it to billing-service due to the “**” catch-all glob. Consequently, Datadog would link the finding to the billing-team.

When the Software Catalog cannot determine the service

If the Software Catalog does not provide a match, either because the finding’s file path does not match any codeLocations, or because the service uses the v2.x schema, Datadog evaluates whether Error Tracking can identify the service associated with the code. Datadog uses only the last 30 days of Error Tracking data due to product data-retention limits.

When Error Tracking processes stack traces, the traces often include file paths. For example, if an error occurs in: /foo/bar/baz.py, Datadog inspects the directory: /foo/bar. Datadog then checks whether the finding’s file path resides under that directory.

If the finding file is under the same directory:

• Datadog treats this as a strong indication that the vulnerability belongs to the same service.
• The finding inherits the service and team associated with that error in Error Tracking.

If this mapping succeeds, Datadog stops here.

Service inference from file paths or repository names

When neither of the above strategies can determine the service, Datadog inspects naming patterns in the repository and file paths.

Datadog evaluates whether:

• The file path contains identifiers matching a known service.
• The repository name corresponds to a service name.

When using the finding’s file path, Datadog performs a reverse search on each path segment until it finds a matching service or exhausts all options.

For example, if a finding occurs in github.com/org/checkout-service at /foo/bar/baz/main.go, Datadog takes the last path segment, main, and sees if any Software Catalog service uses that name. If there is a match, the finding is attributed to that service. If not, the process continues with baz, then bar, and so on.

When all options have been tried, Datadog checks whether the repository name, checkout-service, matches a Software Catalog service name. If no match is found, Datadog is unsuccessful at linking your finding using Software Catalog.

This mechanism ensures that findings receive meaningful service attribution when no explicit metadata exists.

Link findings to teams through Code Owners

If Datadog is able to link your finding to a service using the above strategies, then the team that owns that service (if defined) is associated with that finding automatically.

Regardless of whether Datadog successfully links a finding to a service (and a Datadog team), Datadog uses the CODEOWNERS information from your finding’s repository to link Datadog and GitHub teams to your findings.

Diff-aware scanning

Diff-aware scanning により、Datadog の静的アナライザーは、機能ブランチのコミットで変更されたファイルのみをスキャンします。リポジトリ内のすべてのファイルに対して毎回分析を実行しないことで、スキャン時間を大幅に短縮します。CI パイプラインで Diff-aware scanning を有効にするには、次の手順に従ってください。

1. CI パイプラインでDD_APP_KEY、DD_SITE、およびDD_API_KEY の変数が設定されていることを確認してください。
2. 静的アナライザーを呼び出す前に datadog-ci git-metadata upload を呼び出してください。このコマンドは、Git メタデータが Datadog バックエンドで利用可能になることを保証します。Git メタデータは、分析対象のファイル数を算出するために必要です。
3. datadog-static-analyzerが --diff-aware フラグ付きで呼び出されることを確認してください。

コマンドの実行順の例 (これらのコマンドは Git リポジトリ内で実行する必要があります)

datadog-ci git-metadata upload

datadog-static-analyzer -i /path/to/directory -g -o sarif.json -f sarif –-diff-aware <...other-options...>

注: Diff-aware scanning が完了できない場合、ディレクトリ全体がスキャンされます。

サードパーティの静的分析結果を Datadog へアップロードする

サードパーティの静的分析ツールから Datadog に分析結果を送信することができます (相互運用可能な静的分析結果交換フォーマット (SARIF) であることが条件)。Node.js バージョン 14 以降が必要です。

SARIF レポートをアップロードするには

1. DD_API_KEY および DD_APP_KEY 変数が定義されているを確認してください。

2. 必要に応じて DD_SITE 変数を設定します (デフォルトは datadoghq.com)。

3. datadog-ci ユーティリティをインストールします。

   npm install -g @datadog/datadog-ci
   

4. サードパーティの静的分析ツールをコード上で実行し、結果を SARIF 形式で出力します。

5. 結果を Datadog にアップロードします。

   datadog-ci sarif upload $OUTPUT_LOCATION
   

SARIF サポートガイドライン

Datadog は、2.1.0 SARIF スキーマに準拠したサードパーティの SARIF ファイルの取り込みをサポートしています。SARIF schema は静的アナライザーツールによって異なる方法で使用されます。サードパーティの SARIF ファイルを Datadog に送信する場合は、 以下の詳細に準拠していることを確認してください。

• 違反の場所は、結果の physicalLocation オブジェクトを通じて指定されます。
  • artifactLocation とその uri は、リポジトリのルートに対して相対的でなければなりません。
  • region オブジェクトは、Datadog UI で強調表示されたコードの部分です。
• partialFingerprints は、リポジトリ全体で発見を一意に識別するために使用されます。
• propertiesおよびtagsは、さらに情報を追加します。
  • タグ DATADOG_CATEGORY は、発見のカテゴリを指定します。許容される値は SECURITY、PERFORMANCE、CODE_STYLE、BEST_PRACTICES、ERROR_PRONE です。
  • カテゴリ SECURITY で注釈された違反は、Vulnerabilities explorer およびリポジトリビューの Security タブに表示されます。
• tool セクションには、有効な driver セクションと name およびversion 属性が必要です。

例えば、Datadog によって処理された SARIF ファイルの例は次のとおりです。

{
    "runs": [
        {
            "results": [
                {
                    "level": "error",
                    "locations": [
                        {
                            "physicalLocation": {
                                "artifactLocation": {
                                    "uri": "missing_timeout.py"
                                },
                                "region": {
                                    "endColumn": 76,
                                    "endLine": 6,
                                    "startColumn": 25,
                                    "startLine": 6
                                }
                            }
                        }
                    ],
                    "message": {
                        "text": "timeout not defined"
                    },
                    "partialFingerprints": {
                        "DATADOG_FINGERPRINT": "b45eb11285f5e2ae08598cb8e5903c0ad2b3d68eaa864f3a6f17eb4a3b4a25da"
                    },
                    "properties": {
                        "tags": [
                            "DATADOG_CATEGORY:SECURITY",
                            "CWE:1088"
                        ]
                    },
                    "ruleId": "python-security/requests-timeout",
                    "ruleIndex": 0
                }
            ],
            "tool": {
                "driver": {
                    "informationUri": "https://www.datadoghq.com",
                    "name": "<tool-name>",
                    "rules": [
                        {
                            "fullDescription": {
                                "text": "Access to remote resources should always use a timeout and appropriately handle the timeout and recovery. When using `requests.get`, `requests.put`, `requests.patch`, etc. - we should always use a `timeout` as an argument.\n\n#### Learn More\n\n - [CWE-1088 - Synchronous Access of Remote Resource without Timeout](https://cwe.mitre.org/data/definitions/1088.html)\n - [Python Best Practices: always use a timeout with the requests library](https://www.codiga.io/blog/python-requests-timeout/)"
                            },
                            "helpUri": "https://link/to/documentation",
                            "id": "python-security/requests-timeout",
                            "properties": {
                                "tags": [
                                    "CWE:1088"
                                ]
                            },
                            "shortDescription": {
                                "text": "no timeout was given on call to external resource"
                            }
                        }
                    ],
                    "version": "<tool-version>"
                }
            }
        }
    ],
    "version": "2.1.0"
}

SARIF から CVSS 重大度へのマッピング

SARIF フォーマットは、none、note、warning、および error の4つの重大度を定義しています。 ただし、Datadog は共通脆弱性評価システム (CVSS) を使用して違反および脆弱性の重大度を報告しており、 そこでは critical、high、medium、low、none の5つの重大度が定義されています。

SARIF ファイルを取り込む際、Datadog は以下のマッピングルールを使用して SARIF の重大度を CVSS の重大度にマッピングします。

データ保持

Datadog は、当社の Data Retention Periods に従って発見を保存します。Datadog は顧客のソースコードを保存または保持しません。

<!– 参考資料