Aperçu

Pour configurer Datadog SAST dans l’application, accédez à Sécurité > Sécurité du code.

Sélectionnez où exécuter les analyses de code statique

Scannez avec le scan hébergé par Datadog

Vous pouvez exécuter des analyses de code statique Datadog (SAST) directement sur l’infrastructure Datadog. Les types de dépôts pris en charge incluent :

• GitHub (à l’exclusion des dépôts utilisant Git Large File Storage)
• GitLab.com et GitLab auto-hébergé
• Azure DevOps

Pour commencer, accédez à la page Sécurité du code.

Scannez dans les pipelines CI

L’analyse de code statique Datadog s’exécute dans vos pipelines CI en utilisant le datadog-ci CLI.

Tout d’abord, configurez vos clés API et d’application Datadog. Ajoutez DD_APP_KEY et DD_API_KEY en tant que secrets. Veuillez vous assurer que votre clé d’application Datadog a le scope code_analysis_read.

Ensuite, exécutez l’analyse de code statique en suivant les instructions pour votre fournisseur CI choisi ci-dessous.

Sélectionnez votre fournisseur de gestion de code source

L’analyse statique de code Datadog prend en charge tous les fournisseurs de gestion de code source, avec un support natif pour GitHub, GitLab et Azure DevOps.

Personnalisez votre configuration

Par défaut, l’analyse statique de code Datadog (SAST) analyse vos dépôts avec les ensembles de règles par défaut de Datadog pour chaque langage de programmation. Vous pouvez personnaliser les ensembles de règles ou les règles qui s’exécutent, ainsi que d’autres paramètres, dans Datadog ou dans un fichier code-security.datadog.yaml. Pour la référence complète de configuration, voir Configuration de l’analyse statique de code (SAST).

Liez les résultats aux services et équipes 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.

Analyse sensible aux différences

L’analyse sensible aux différences permet à l’analyseur statique de Datadog de ne scanner que les fichiers modifiés par un commit dans une branche de fonctionnalité. Cela accélère considérablement le temps de scan en évitant d’exécuter l’analyse sur chaque fichier du dépôt pour chaque scan. Pour activer l’analyse sensible aux différences dans votre pipeline CI, suivez ces étapes :

1. Assurez-vous que vos variables DD_APP_KEY, DD_SITE et DD_API_KEY sont définies dans votre pipeline CI.
2. Ajoutez un appel à datadog-ci git-metadata upload avant d’invoquer l’analyseur statique. Cette commande garantit que les métadonnées Git sont disponibles pour le backend Datadog. Les métadonnées Git sont nécessaires pour calculer le nombre de fichiers à analyser.
3. Assurez-vous que l’analyseur statique Datadog est invoqué avec le drapeau --diff-aware.

Exemple de séquence de commandes (ces commandes doivent être invoquées dans votre dépôt Git) :

datadog-ci git-metadata upload

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

Remarque : Lorsqu’un scan sensible aux différences ne peut pas être complété, l’ensemble du répertoire est scanné.

Téléchargez les résultats d’analyse statique tiers sur Datadog

Vous pouvez envoyer les résultats des outils d’analyse statique tiers à Datadog, à condition qu’ils soient au format interopérable Format d’échange des résultats d’analyse statique (SARIF). La version 14 ou ultérieure de Node.js est requise.

Pour importer un rapport SARIF, procédez comme suit :

1. Assurez-vous que les DD_API_KEY et DD_APP_KEY variables sont définies.

2. Optionnellement, définissez une DD_SITE variable (la valeur par défaut est datadoghq.com).

3. Installez l’utilitaire datadog-ci :

   npm install -g @datadog/datadog-ci
   

4. Exécutez l’outil d’analyse statique tiers sur votre code et exportez les résultats au format SARIF.

5. Téléchargez les résultats sur Datadog :

   datadog-ci sarif upload $OUTPUT_LOCATION
   

Directives de support SARIF

Datadog prend en charge l’ingestion de fichiers SARIF tiers conformes au schéma SARIF 2.1.0. Le SARIF le schéma est utilisé différemment par les outils d’analyse statique. Si vous souhaitez envoyer des fichiers SARIF tiers à Datadog, veuillez vous assurer qu’ils respectent les détails suivants :

• L’emplacement de la violation est spécifié par l’objet physicalLocation d’un résultat.
  • Le artifactLocation et son uri doivent être relatifs à la racine du dépôt.
  • L’objet region est la partie du code mise en évidence dans l’interface utilisateur de Datadog.
• Le partialFingerprints est utilisé pour identifier de manière unique une découverte dans un dépôt.
• properties et tags ajoutent plus d’informations :
  • L’étiquette DATADOG_CATEGORY spécifie la catégorie de la découverte. Les valeurs acceptables sont SECURITY, PERFORMANCE, CODE_STYLE, BEST_PRACTICES, ERROR_PRONE.
  • Les violations annotées avec la catégorie SECURITY sont affichées dans l’explorateur de vulnérabilités et l’onglet Sécurité de la vue du dépôt.
• La section tool doit avoir une section driver valide avec des attributs name et version.

Par exemple, voici un exemple d’un fichier SARIF traité par 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"
}

Mapping de la sévérité SARIF à CVSS

Le format SARIF définit quatre niveaux de sévérité : aucun, note, avertissement et erreur. Cependant, Datadog signale les violations et la gravité des vulnérabilités en utilisant le Système de notation des vulnérabilités communes (CVSS), qui définit cinq niveaux de gravité : critique, élevé, moyen, faible et aucun.

Lors de l’ingestion de fichiers SARIF, Datadog mappe les niveaux de gravité SARIF aux niveaux de gravité CVSS en utilisant les règles de correspondance ci-dessous.

Conservation des données

Datadog stocke les résultats conformément à nos Périodes de conservation des données. Datadog ne stocke ni ne conserve le code source des clients.

<!– Lectures complémentaires