개요

Datadog SAST를 앱 내에서 설정하려면 Security > Code Security로 이동하십시오.

Static Code Analysis 스캔을 실행할 위치 선택

Datadog 호스팅 스캐닝을 사용하여 스캔

Datadog Static Code Analysis(SAST) 스캔을 Datadog 인프라에서 직접 실행할 수 있습니다. 지원되는 리포지토리 유형의 예:

• GitHub(Git Large File Storage를 사용하는 리포지토리 제외)
• GitLab.com 및 GitLab Self-Managed
• Azure DevOps
• Bitbucket Cloud

시작하려면 Code Security 페이지로 이동하십시오.

CI 파이프라인에서 스캔

Datadog Static Code Analysis는 CI 파이프라인에서 datadog-ci CLI를 사용하여 실행됩니다.

먼저 Datadog API 및 애플리케이션 키를 구성합니다. DD_APP_KEY 및 DD_API_KEY를 시크릿으로 추가합니다. Datadog 애플리케이션 키에 code_analysis_read 범위가 있어야 합니다.

다음으로, 아래에서 선택한 CI 공급자에 적합한 지침을 따라 Static Code Analysis를 실행합니다.

소스 코드 관리 공급자 선택

Datadog Static Code Analysis는 모든 소스 관리 공급자를 지원하며, GitHub, GitLab, Azure DevOps, Bitbucket Cloud Premium을 기본적으로 지원합니다.

구성 사용자 지정

기본적으로 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 스캐닝

Diff-aware 스캐닝을 사용하면 Datadog의 정적 분석기가 기능 브랜치에서 커밋으로 수정된 파일만 스캔할 수 있습니다. 스캔할 때마다 리포지토리의 모든 파일에서 분석을 실행할 필요가 없기 때문에 스캔 시간을 대폭 단축해 줍니다. CI 파이프라인에서 diff-aware 스캐닝을 활성화하려면 다음 단계를 따르세요.

1. CI 파이프라인에서 DD_APP_KEY, DD_SITE 및 DD_API_KEY 변수가 설정되어 있어야 합니다.
2. 정적 분석기를 호출하기 전에 datadog-ci git-metadata upload에 호출을 추가하세요. 이 명령을 사용하면 Datadog 백엔드에서 Git 메타데이터를 사용할 수 있도록 보장합니다. 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 스캔을 완료할 수 없는 경우, 디렉터리 전체가 스캔됩니다.

타사 정적 분석 결과를 Datadog에 업로드

타사 정적 분석 도구의 결과가 상호 운용 가능한 Static Analysis Results Interchange Format(SARIF) 형식이면 Datadog에 전송할 수 있습니다. 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 스키마는 정적 분석기 도구마다 다르게 사용됩니다. 타사 SARIF 파일을 Datadog으로 전송하려면 해당 파일이 다음 세부 정보를 준수해야 합니다.

• 위반 위치가 결과의 physicalLocation 개체를 통해 지정됩니다.
  • artifactLocation 및 그에 속한 uri가 리포지토리 루트에 상대적이어야 합니다.
  • region 개체가 Datadog UI에서 강조 표시된 코드의 일부분입니다.
• 리포지토리 전체에서 발견 사항을 고유하게 식별하는 데 partialFingerprints를 사용합니다.
• properties 및 tags로 더 많은 정보 추가:
  • 태그 DATADOG_CATEGORY는 발견 사항의 카테고리를 지정합니다. 용인되는 값은 SECURITY, PERFORMANCE, CODE_STYLE, BEST_PRACTICES, ERROR_PRONE입니다.
  • 카테고리 SECURITY로 어노테이션된 위반 사항은 리포지토리 조회의 취약성 탐색기 및 보안 탭에 표시됩니다.
• tool 섹션에는 name 및 version 속성이 있는 유효한 driver 섹션이 있어야 합니다.

예를 들어 다음은 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은 Common Vulnerability Scoring System(CVSS)를 사용하여 위반 사항 및 취약성 심각도를 보고하는데, 여기에서는 critical, high, medium, low 및 none의 5가지 심각도를 정의합니다.

Datadog은 SARIF 파일을 수집할 때 아래의 매핑 규칙을 사용하여 SARIF 심각도를 CVSS 심각도로 매핑합니다.

데이터 보존

Datadog은 당사 데이터 보존 기간 에 따라 발견 사항을 저장합니다. Datadog은 고객 소스 코드를 저장 또는 보존하지 않습니다.

<!– 추가 자료