Descripción general

Para configurar Datadog SAST en la aplicación, navegue a Security > Code Security.

Seleccione dónde ejecutar los escaneos de Datadog Static Code Analysis

Analizar con escaneo alojado por Datadog

Puede ejecutar escaneos de Datadog Static Code Analysis (SAST) directamente en la infraestructura de Datadog. Los tipos de repositorio admitidos incluyen:

• GitHub (excluyendo repositorios que utilizan Git Large File Storage)
• GitLab.com y GitLab Self-Managed
• Azure DevOps
• Bitbucket Cloud

Para comenzar, navegue a la Code Security página.

Analizar en pipelines de CI

Datadog Static Code Analysis se ejecuta en sus pipelines de CI utilizando la datadog-ci CLI.

Primero, configure su Datadog API y sus claves de aplicación. Agregue DD_APP_KEY y DD_API_KEY como secretos. Por favor, asegúrese de que su clave de aplicación de Datadog tenga el contexto code_analysis_read.

A continuación, ejecute Datadog Static Code Analysis siguiendo las instrucciones para el proveedor de CI que eligió a continuación.

Seleccione su proveedor de gestión de código fuente

Datadog Static Code Analysis es compatible con todos los proveedores de gestión de código fuente, con soporte nativo para GitHub, GitLab, Azure DevOps y Bitbucket Cloud Premium.

Personalice su configuración

De forma predeterminada, Datadog Static Code Analysis (SAST) escanea sus repositorios con los conjuntos de reglas predeterminados de Datadog para cada lenguaje de programación. Puede personalizar qué conjuntos de reglas o reglas se ejecutan, junto con otros parámetros, en Datadog o en un archivo code-security.datadog.yaml. Para obtener la referencia de configuración completa, consulte Configuración de análisis de código estático (SAST).

Vincule los hallazgos a los servicios y equipos de 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.

Escaneo con reconocimiento de diferencias

El escaneo con reconocimiento de diferencias permite que el analizador estático de Datadog escanee solo los archivos modificados por una confirmación en una rama de funciones. Acelera significativamente el tiempo de escaneo al no ejecutar el análisis en cada archivo del repositorio para cada escaneo. Para habilitar el escaneo con reconocimiento de diferencias en su canalización de CI, siga estos pasos:

1. Asegúrese de que sus variables DD_APP_KEY, DD_SITE y DD_API_KEY estén configuradas en su canalización de CI.
2. Agregue una llamada a datadog-ci git-metadata upload antes de invocar el analizador estático. Este comando garantiza que los metadatos de Git estén disponibles para el backend de Datadog. Los metadatos de Git son necesarios para calcular la cantidad de archivos a analizar.
3. Asegúrese de que datadog-static-analyzer se invoque con la bandera --diff-aware.

Ejemplo de secuencia de comandos (estos comandos deben invocarse en su repositorio Git):

datadog-ci git-metadata upload

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

Nota: Cuando no se puede completar un escaneo que reconoce diferencias, se escanea todo el directorio.

Cargue resultados de análisis estático de terceros a Datadog

Puede enviar resultados de herramientas de análisis estático de terceros a Datadog, siempre que estén en el Formato de intercambio de resultados de análisis estático (SARIF) interoperable. Se requiere Node.js versión 14 o posterior.

Para cargar un informe SARIF:

1. Asegúrese de que las variables DD_API_KEY y DD_APP_KEY estén definidas.

2. Opcionalmente, establezca una DD_SITE variable (el valor predeterminado es datadoghq.com).

3. Instale la utilidad datadog-ci:

   npm install -g @datadog/datadog-ci
   

4. Ejecute la herramienta de análisis estático de terceros en su código y genere los resultados en formato SARIF.

5. Cargue los resultados en Datadog:

   datadog-ci sarif upload $OUTPUT_LOCATION
   

Pautas de soporte para SARIF

Datadog admite la ingesta de archivos SARIF de terceros que cumplan con el esquema SARIF 2.1.0. El SARIF esquema es utilizado de manera diferente por las herramientas de análisis estático. Si desea enviar archivos SARIF de terceros a Datadog, por favor asegúrese de que cumplan con los siguientes detalles:

• La ubicación de la infracción se especifica a través del objeto physicalLocation de un resultado.
  • El artifactLocation y su uri deben ser relativos a la raíz del repositorio.
  • El objeto region es la parte del código resaltada en la interfaz de usuario de Datadog.
• El partialFingerprints se utiliza para identificar de forma única un hallazgo en un repositorio.
• properties y tags añaden más información:
  • La etiqueta DATADOG_CATEGORY especifica la categoría del hallazgo. Los valores aceptables son SECURITY, PERFORMANCE, CODE_STYLE, BEST_PRACTICES, ERROR_PRONE.
  • Las infracciones anotadas con la categoría SECURITY se muestran en el explorador de vulnerabilidades y en la pestaña Security de la vista del repositorio.
• La sección tool debe tener una sección driver válida con atributos name y version.

Por ejemplo, aquí hay un ejemplo de un archivo SARIF procesado por Datadog:

{
    "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"
}

Asignación de gravedad de SARIF a CVSS

El formato SARIF define cuatro gravedades: ninguna, nota, advertencia y error. Sin embargo, Datadog informa la gravedad de las infracciones y vulnerabilidades utilizando el Sistema de puntuación de vulnerabilidad común (CVSS), que define cinco gravedades: crítica, alta, media, baja y ninguna.

Al ingerir archivos SARIF, Datadog asigna las gravedades de SARIF a las gravedades de CVSS utilizando las reglas de asignación a continuación.

Retención de datos

Datadog almacena los hallazgos de acuerdo con nuestros Periodos de retención de datos. Datadog no almacena ni conserva el código fuente del cliente.

<!– Lecturas adicionales