Présentation

Datadog Code Security vous aide à sécuriser et à maintenir le code de première partie et les bibliothèques open source de vos applications, du développement à la production.

Il propose une suite d’outils pour vous aider à sécuriser votre code tout au long du cycle de vie du développement logiciel :

• Static Code Analysis (SAST) utilise une méthode Static Application Security Testing pour analyser vos dépôts à la recherche de problèmes de sécurité et de qualité dans le code de première partie, en fournissant des suggestions de correctifs pour empêcher ces problèmes d’atteindre la production.
• Software Composition Analysis (SCA) détecte les bibliothèques open source vulnérables présentes dans vos dépôts et affectant vos services lors de l’exécution, vous aidant ainsi à sécuriser et à maintenir votre chaîne d’approvisionnement logicielle.
• Runtime Code Analysis (IAST) utilise une méthode Interactive Application Security Testing pour détecter les vulnérabilités affectant vos services lors de l’exécution.

Configurer Code Security

Bibliothèques open source

Datadog Software Composition Analysis détecte les vulnérabilités des bibliothèques et répertorie les dépendances au sein de votre base de code et de vos services en cours d’exécution.

Consultez Software Composition Analysis pour configurer la détection des vulnérabilités des bibliothèques de manière statique et/ou lors de l’exécution.

Code de première partie

Intégrations d’outils de développement

Activer les commentaires sur les pull requests

Datadog peut agir comme un réviseur de code automatique pour signaler les vulnérabilités et les violations de qualité dans les pull requests GitHub. Pour plus d’informations, consultez GitHub Pull Requests.

Installez les intégrations IDE

Installez les plugins IDE Datadog pour identifier les problèmes de sécurité du code directement dans votre éditeur de code. Selon votre IDE, les plugins prennent en charge les fonctionnalités suivantes :

• Static Code Analysis (SAST)
• Software Composition Analysis (SCA)
• Runtime Code Analysis (IAST)
• Secret Scanning
• Infrastructure as Code (IaC) Scanning

Personnalisez les paramètres de votre dépôt

Dans les paramètres de Code Security, vous pouvez gérer les dépôts pour lesquels les commentaires de PR sont activés, ainsi que personnaliser la configuration des règles de Static Code Analysis (SAST) appliquées à travers ou au sein des dépôts. Pour toutes les règles par défaut fournies par Datadog, consultez les Règles SAST.

Configurez les portes de PR

Datadog fournit des Portes de PR en tant que fonctionnalité de plateforme pour vous aider à maintenir et à appliquer des normes de sécurité et de qualité pour les modifications apportées à votre base de code. Pour plus d’informations, consultez la configuration des portes de PR.

Priorisez les vulnérabilités avec le contexte d’exécution

Code Security offre des vues centrées sur les vulnérabilités de toutes les vulnérabilités dans les bibliothèques et le code détectées à la fois par l’analyse statique des dépôts et par la détection des services en cours d’exécution.

Explorez les vulnérabilités

Pour les vulnérabilités de bibliothèque, chaque ligne du tableau représente une vulnérabilité spécifique affectant une version de bibliothèque. Selon que vous avez activé la détection statique ou au moment de l’exécution, la colonne Detected In affiche les dépôts et/ou services spécifiques affectés par cette vulnérabilité.

Dans le panneau latéral pour une vulnérabilité de bibliothèque unique dans SCA, en plus des détails sur la vulnérabilité, Datadog affiche :

• Un Severity breakdown de l’instance de plus haute gravité de cette vulnérabilité observée dans vos dépôts et vos services. Pour chaque emplacement détecté de la vulnérabilité dans vos dépôts et/ou services, Datadog ajuste le score de gravité de base de la vulnérabilité en fonction de facteurs environnementaux. Pour en savoir plus, consultez Score de gravité Datadog.
• Un Repositories tableau de toutes les instances où la vulnérabilité a été détectée dans vos dépôts. Pour chaque instance, Datadog indique si la dépendance est classée comme directe ou transitive, le statut de remédiation de la vulnérabilité, ainsi que les étapes de remédiation spécifiques.
• Un Impacted Services tableau de tous les services en cours d’exécution affectés par cette vulnérabilité de bibliothèque. Un service est affecté par une vulnérabilité de bibliothèque si la bibliothèque a été chargée au moment de l’exécution et détectée par les SDK d’application de Datadog.

Les niveaux de gravité sont évalués comme suit :

Explorer les résultats par dépôt

Code Security propose également des vues centrées sur les dépôts des résultats d’analyse statique, prenant en charge un filtrage granulaire sur toutes les branches et tous les commits pour les dépôts analysés.

Cliquez sur un dépôt sur la page Repositories pour accéder à une vue plus détaillée où vous pouvez personnaliser la requête de recherche par branche (la branche par défaut apparaissant en premier) et par commit (en commençant par le plus récent).

Vous pouvez utiliser les facettes prêtes à l’emploi suivantes pour créer une requête de recherche afin d’identifier et de résoudre les mauvaises pratiques de codage dans l’onglet Code Quality ou les risques de sécurité dans l’onglet Code Vulnerabilities.

Nom de la facette	Description
État du résultat	Filtre les résultats en fonction de l’état d’achèvement de l’analyse.
ID de la règle	Règles spécifiques ayant déclenché les résultats.
Nom de l’outil	Détermine quels outils ont contribué à l’analyse.
CWE (Common Weakness Enumeration)	Filtre les résultats par catégories de vulnérabilités reconnues.
Correctifs disponibles	Filtre les problèmes pour lesquels des correctifs suggérés sont disponibles.
Message de résultat	Contient des descriptions ou des messages concis associés aux résultats.
Description de la règle	Contient la justification de chaque règle.
Fichier source	Contient les fichiers où des problèmes ont été détectés.
Version de l’outil	Filtre les résultats par la version des outils utilisés.

Vous pouvez accéder aux correctifs suggérés directement depuis les résultats pour remédier aux vulnérabilités de sécurité ou améliorer les pratiques de qualité du code.

Vous pouvez utiliser les facettes prêtes à l’emploi suivantes pour créer une requête de recherche afin d’identifier et de traiter les risques de sécurité dans les bibliothèques tierces dans l’onglet Library Vulnerabilities ou pour examiner votre inventaire de bibliothèques dans l’onglet Library Catalog.

Nom de la facette	Description
Nom de la dépendance	Identifie les bibliothèques par leur nom.
Version de la dépendance	Filtre par versions spécifiques de bibliothèques.
Langage	Trie les bibliothèques par langage de programmation.
Score	Trie le score de risque ou de qualité des dépendances.
Gravité	Filtre les vulnérabilités en fonction de leur niveau de gravité.
Plateforme	Distingue les bibliothèques selon la plateforme à laquelle elles sont destinées.

Vous pouvez accéder aux rapports de vulnérabilité et localiser les fichiers sources où la vulnérabilité a été découverte dans vos projets, ainsi que des informations sur les propriétaires du code du fichier.

Notifier, corriger et signaler

Code Security vous aide à configurer des workflows pour suivre et gérer la correction des résultats :

• Configurez des règles de notification pour informer votre ou vos équipes des nouveaux résultats via Slack, Jira, e‑mail, et plus encore
• Suivez les vulnérabilités par service et par équipe sur la page Code Security Summary.

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][101] 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][102].

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][103].

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.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Écrivez du code sécurisé avec Datadog Code SecurityCENTRE D'APPRENTISSAGE