Ce produit n'est pas pris en charge par le site Datadog que vous avez sélectionné. ().
Trouvez les Generic Secrets dans votre code

Generic Secret Scanning est en préversion. Il recherche les jetons et mots de passe internes qui ne correspondent pas à un modèle de fournisseur.

Request Access

Datadog Secret Scanning analyse le code pour trouver les secrets exposés. Datadog tente également de valider les secrets et d’afficher leur statut (valide, invalide) pour vous aider à hiérarchiser la correction des secrets.

Configurer Secret Scanning

Les analyses peuvent s’exécuter dans vos pipelines CI/CD ou directement dans Datadog avec l’analyse hébergée (prise en charge pour GitHub, Azure DevOps et GitLab). Pour commencer, accédez à Code Security Setup et cliquez sur Activate scanning for your repositories ou apprenez à configurer Secret Scanning en utilisant GitHub actions ou avec d’autres fournisseurs CI.

Règles de Secret Scanning

Datadog Secret Scanning est propulsé par Sensitive Data Scanner (SDS) et inclut toutes les règles de la catégorie Secrets et identifiants de SDS. Pour un sous-ensemble de détections, Secret Scanning vérifie automatiquement si les clés détectées sont actives avec la validation active par des tiers.

Fonctionnement

Secret Scanning s’intègre directement à vos dépôts pour détecter en continu les secrets divulgués dans votre code. Basé sur l’analyseur statique de Datadog, il analyse chaque commit sur toutes les branches de chaque dépôt configuré. Les résultats sont présentés avec le contexte du dépôt, de la branche et du chemin de fichier afin que votre équipe puisse identifier, hiérarchiser et corriger les secrets exposés à la source.

Chaque analyse examine le contenu complet de chaque fichier concerné au niveau du commit analysé, et pas seulement les lignes ou les fichiers modifiés par le commit. Lorsque Datadog analyse un dépôt pour la première fois avec l’analyse hébergée, il analyse également l’historique Git complet du dépôt. Voir Détecter les secrets dans l’historique Git.

L’analyse prenant en compte les différences, disponible pour Static Code Analysis, n’est pas prise en charge pour Secret Scanning.

Fonctionnalités clés

Détecter les secrets dans l’historique Git

La suppression d’un secret d’un fichier ne le supprime pas du dépôt. Le secret demeure dans les commits précédents, où toute personne ayant accès au dépôt peut le récupérer.

Lorsqu’un dépôt est analysé pour la première fois avec l’analyse hébergée, Datadog analyse l’intégralité de son historique Git sur toutes les branches, en plus du dernier commit. Les secrets qui ne sont plus présents au niveau du dernier commit de la branche par défaut sont signalés comme des découvertes d’historique uniquement.

Les découvertes d’historique uniquement sont étiquetées Detected in Git History dans la liste des découvertes. Pour les examiner :

Le panneau de détails de la découverte indique où se trouve le secret dans l’historique du dépôt :

  • Introduced in : Le commit qui a ajouté le secret, et l’auteur de ce commit.
  • Removed in : Le commit qui a supprimé le secret. Si le secret est toujours présent sur une branche ou un tag non fusionné, cela indique Not removed.
L'historique Git est analysé une fois, lors de la première analyse d'un dépôt avec l'analyse hébergée. Un secret toujours présent sur une branche ou un tag non fusionné, mais pas sur la branche par défaut, est signalé comme une découverte d'historique uniquement. Les analyses CI n'analysent que le commit analysé.
Les découvertes d'historique uniquement ne sont pas fermées automatiquement par les analyses ultérieures, et la réécriture de l'historique Git ne les ferme pas. Faites pivoter ou révoquez l'identifiant exposé, puis mettez en sourdine la découverte.

Examinez les secrets exposés dans les pull requests

Lorsqu’une pull request introduit un secret divulgué, Datadog ajoute automatiquement des commentaires en ligne pour signaler l’exposition. Vous pouvez également ouvrir une nouvelle pull request depuis Datadog pour corriger directement la découverte. Pour plus d’informations, consultez Commentaires sur les pull requests.

Bloquez automatiquement les fuites avec les PR Gates

Utilisez les PR Gates pour empêcher que des secrets divulgués ne soient fusionnés dans votre branche principale. Datadog analyse chaque pull request à la recherche de secrets exposés et signale un statut de réussite ou d’échec directement à GitHub, Azure DevOps ou GitLab (en préversion).

Par défaut, les checks sont informatifs, mais vous pouvez les rendre bloquants pour empêcher la fusion lorsque des secrets sont détectés. Pour obtenir des instructions de configuration, consultez Set up PR Gate Rules.

Exclusions en ligne

Vous pouvez ajouter des exclusions en ligne pour empêcher certaines découvertes d’apparaître dans les résultats d’analyse. Commentez no-dd-secrets pour ignorer les secrets détectés sur la ligne suivante.

Afficher et filtrer les constats

Après avoir configuré le Secret Scanning, chaque commit vers un dépôt analysé déclenche une analyse. Les découvertes sont résumées sur la page Code Security Vulnerabilities et regroupées par dépôt sur la page Code Security Repositories.

Sous l’onglet Secret Scanning (Secrets), utilisez des filtres pour affiner les résultats par facettes telles que :

  • Gravité
  • Statut (open, muted, fixed)
  • Validation Status
  • Équipe
  • Visibilité du dépôt
  • Is Git History

Créer des tickets Jira à partir des constats

Vous pouvez créer un ticket Jira bidirectionnel directement à partir de n’importe quel constat pour suivre et corriger les problèmes dans vos workflows existants. Le statut du ticket reste synchronisé entre Datadog et Jira. Pour plus d’informations, consultez Synchronisation bidirectionnelle des tickets avec Jira.

Déclarez un incident à partir d’un secret divulgué

Déclarer un incident à partir d’une découverte en cliquant sur Declare incident dans le panneau latéral de Secret Scanning. L’incident est pré-rempli avec toutes les métadonnées de détection.

Masquer les résultats

Pour masquer un constat, cliquez sur Mute dans le panneau de détails du constat. Cela ouvre un workflow où vous pouvez créer une règle de mise en sourdine pour un filtrage contextuel par valeurs de tag (par exemple, par repository). Mettre un constat en mode mute le masque et l’exclut des rapports.

Pour restaurer un constat en mode mute, cliquez sur Unmute dans le panneau de détails. Vous pouvez également utiliser le filtre Status sur la page Code Security Vulnerabilities pour examiner les découvertes mises en sourdine.

Étapes suivantes

  1. Mettez en place Secret Scanning dans votre environnement.
  2. Configurez Automation Pipelines pour automatiser le tri initial.
  3. Examinez les résultats sur la page Code Security Vulnerabilities.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles: