Code Analysis de Datadog permet d’identifier et de résoudre les problèmes de qualité de code et les vulnérabilités de sécurité avant le déploiement en production, garantissant un code sûr et propre tout au long du cycle de vie du développement logiciel.
Static Analysis (SAST) analyse vos référentiels pour détecter des problèmes de qualité et de sécurité dans le code interne, et propose des correctifs afin d’empêcher que ces problèmes n’impactent la production.
Software Composition Analysis (SCA) analyse votre base de code à la recherche de bibliothèques open source importées, ce qui aide à gérer vos dépendances et à sécuriser vos applications contre les menaces externes.
En utilisant datadog-ci, vous pouvez intégrer les analyses d’autres fournisseurs dans votre workflow de développement, ce qui permet d’envoyer directement les résultats de Static Analysis et de SCA à Datadog. Vous pouvez accéder aux derniers résultats d’analyse pour chaque référentiel sur la page Repositories afin de surveiller et d’améliorer efficacement la santé du code sur toutes les branches.
Configurer Code Analysis
Il est possible de configurer Code Analysis pour exécuter des analyses sur le code directement dans Datadog ou sur le code exécuté dans vos pipelines CI. Pour commencer, accédez à Software Delivery > Code Analysis > Repositories et cliquez sur + Add a Repository.
Avec les analyses hébergées par Datadog, votre code est analysé dans l’infrastructure de Datadog plutôt que dans votre pipeline CI. Datadog lit votre code, exécute l’analyseur statique pour effectuer une Static Analysis ou une Software Composition Analysis, puis téléverse les résultats.
L’utilisation des analyses hébergées par Datadog supprime la nécessité de configurer un pipeline CI pour pouvoir utiliser Code Analysis.
Activez Code Analysis sur vos référentiels GitHub pour chaque compte GitHub que vous avez ajouté en configurant l’intégration GitHub.
Il est possible soit d’activer Software Composition Analysis (SCA) pour analyser les vulnérabilités, les problèmes de licence et les risques liés à la chaîne d’approvisionnement dans vos bibliothèques open source pour tous les référentiels, soit d’activer SCA pour des référentiels individuels dans le panneau latéral Repositories.
Sélectionnez parmi les types d’analyses suivants ceux que vous souhaitez exécuter dans votre référentiel.
Static Analysis : examinez votre code pour détecter les mauvaises pratiques et les vulnérabilités.
Si vous utilisez un référentiel GitHub, vous pouvez configurer l’intégration GitHub et connecter votre référentiel pour activer les analyses Static Analysis et Software Composition Analysis.
Les commentaires dans les pull requests GitHub sont activés par défaut. Cliquez sur Connect Repositories sur la page de configuration de Code Analysis et survolez l’indicateur Missing dans la colonne PR Permissions pour voir quelles autorisations vous devez mettre à jour pour votre compte.
Pour désactiver cette fonctionnalité, accédez à la page Code Analysis Settings et cliquez sur le bouton dans la colonne GitHub Comments.
Indiquez un nom pour le service ou la bibliothèque dans le champ dd_service, comme shopist.
Action GitHub
Il est possible de configurer une GitHub Action pour exécuter des analyses Static Analysis et Software Composition Analysis dans le cadre de vos workflows CI.
Créez un fichier .github/workflows/datadog-static-analysis.yml dans votre référentiel avec le contenu suivant :
Ensuite, créez un fichier .github/workflows/datadog-sca.yml dans votre référentiel avec le contenu suivant :
on:[push]name:Datadog Software Composition Analysisjobs:software-composition-analysis:runs-on:ubuntu-latestname:Datadog SBOM Generation and Uploadsteps:- name:Checkoutuses:actions/checkout@v3- name:Check imported libraries are secure and compliantid:datadog-software-composition-analysisuses:DataDog/datadog-sca-github-action@mainwith:dd_api_key:${{ secrets.DD_API_KEY }}dd_app_key:${{ secrets.DD_APP_KEY }}dd_service:shopistdd_env:cidd_site:datadoghq.com
Script personnalisable
Il est possible de téléverser un rapport SARIF avec les résultats de Static Analysis ou un rapport SBOM avec les résultats de Software Composition Analysis vers Datadog en utilisant le package NPM datadog-ci.
Analyse statique
Pour téléverser des rapports Static Analysis vers Datadog, vous devez installer Unzip et Node.js version 14 ou ultérieure.
Ajoutez le contenu suivant à la configuration de votre pipeline CI :
# Set the Datadog site to send information toexportDD_SITE="datadoghq.com"# Install dependenciesnpm install -g @datadog/datadog-ci
# Download the latest Datadog static analyzer:# https://github.com/DataDog/datadog-static-analyzer/releasesDATADOG_STATIC_ANALYZER_URL=https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-unknown-linux-gnu.zip
curl -L $DATADOG_STATIC_ANALYZER_URL > /tmp/ddog-static-analyzer.zip
unzip /tmp/ddog-static-analyzer.zip -d /tmp
mv /tmp/datadog-static-analyzer /usr/local/datadog-static-analyzer
# Run Static Analysis/usr/local/datadog-static-analyzer -i . -o /tmp/report.sarif -f sarif
# Upload resultsdatadog-ci sarif upload /tmp/report.sarif --service "shopist" --env "ci"
Software Composition Analysis
Pour téléverser les résultats de Software Composition Analysis vers Datadog, vous devez installer Trivy et Node.js version 14 ou ultérieure.
Ajoutez le contenu suivant à la configuration de votre pipeline CI :
Une fois que vous avez configuré ces scripts, exécutez une analyse de votre référentiel sur la branche par défaut. Les résultats commenceront ensuite à apparaître sur la page Repositories.
Exécuter Static Analysis dans un IDE
Installez les plugins IDE Datadog pour exécuter des analyses Static Analysis localement et voir les résultats directement dans votre éditeur de code. Vous pouvez détecter et corriger des problèmes tels que des problèmes de maintenabilité, des bugs ou des vulnérabilités de sécurité dans votre code avant de valider vos modifications.
Pour commencer à exécuter des analyses Static Analysis dans votre IDE, consultez la documentation correspondante pour l’éditeur de code de votre choix.
Activer les commentaires Code Analysis dans les pull requests GitHub
Il est possible d’intégrer Code Analysis avec les pull requests GitHub pour signaler automatiquement les non-conformités de code et améliorer la qualité du code lors du processus de relecture.
Une fois configuré, Code Analysis commente directement dans la PR, en indiquant les non-conformités avec des détails tels que le nom, l’ID, la sévérité et les correctifs suggérés, que vous pouvez appliquer directement depuis l’interface GitHub.
Après avoir ajouté les fichiers de configuration appropriés à votre référentiel, créez une application GitHub dans Datadog (une nouvelle application ou une mise à jour d’une application existante). Assurez-vous qu’elle dispose des droits de lecture et d’écriture appropriés sur les pull requests.
Une fois que vous avez configuré votre application, accédez à la page Code Analysis Settings et cliquez sur le bouton dans la colonne GitHub Comments pour chaque référentiel.
Cliquez sur un référentiel dans 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).
Il est possible d’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
Rôle
Statut du résultat
Filtrer les résultats en fonction du statut d’exécution 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.
Possède des correctifs
Filtre les problèmes pour lesquels des correctifs sont disponibles.
Message du résultat
Contient des descriptions concises ou des messages 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
Filtrer les résultats en fonction de la version des outils utilisés.
Il est possible d’accéder aux correctifs suggérés directement depuis les résultats pour améliorer les pratiques de qualité de code et corriger les vulnérabilités de sécurité.
Il est possible d’utiliser les facettes prêtes à l’emploi suivantes pour créer une requête de recherche afin d’identifier et de corriger 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
Rôle
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
Distinguer les bibliothèques selon la plateforme visée.
Accéder aux rapports de vulnérabilités et localiser les fichiers sources où la vulnérabilité a été découverte dans vos projets, ainsi qu’aux informations sur les responsables du code du fichier.
Explorer les résultats dans le Service Catalog
Examiner les non-conformités de code associées à vos services et les non-conformités de code identifiées par l’analyse statique afin de résoudre les ralentissements et les défaillances. Accéder à Service Management > Services > Service Catalog et cliquer sur la vue Delivery pour analyser l’état de préproduction de vos services.
Cliquez sur un service pour accéder aux informations sur les pipelines CI depuis Pipeline Visibility, ainsi qu’aux vulnérabilités de sécurité et aux problèmes de qualité du code depuis Code Analysis, dans l’onglet Delivery du panneau latéral.
Lier les services aux non-conformités de code et aux bibliothèques
Datadog associe les non-conformités du code ou les bibliothèques aux services compétents en utilisant les mécanismes suivants :
Si une méthode réussit, aucune autre tentative de mappage n’est effectuée. Chaque méthode de mappage est détaillée ci-dessous.
Identifier l’emplacement du code dans le Service Catalog
La version de schéma v3 et ultérieure du Service Catalog permet d’ajouter le mappage de l’emplacement du code de votre service. La section codeLocations spécifie l’emplacement du référentiel contenant le code et ses chemins associés.
L’attribut paths est une liste de globs
qui doivent correspondre aux chemins du référentiel.
Datadog détecte l’utilisation de fichiers dans des produits supplémentaires tels que Error Tracking et associe les fichiers au service runtime. Par exemple, si un service nommé foo contient une entrée de log ou une trace de pile avec un fichier ayant un chemin /modules/foo/bar.py, il associe le fichier /modules/foo/bar.py au service foo.
Détecter le nom du service dans les chemins et les noms de référentiels
Datadog détecte les noms de service dans les chemins et les noms de référentiels, et associe le fichier au service en cas de correspondance.
Pour une correspondance de référentiel, si un service nommé myservice existe et
que l’URL du référentiel est https://github.com/myorganization/myservice.git, alors
myservice est associé à tous les fichiers du référentiel.
Si aucune correspondance de référentiel n’est trouvée, Datadog tente de trouver une correspondance dans le
path du fichier. Si un service nommé myservice existe et que le chemin est /path/to/myservice/foo.py, le fichier est associé à myservice car le nom du service fait partie du chemin. Si deux services sont présents
dans le chemin, le nom du service le plus proche du nom de fichier est sélectionné.
Lier les équipes aux non-conformités du code et aux bibliothèques
Datadog associe automatiquement l’équipe attachée à un service lorsqu’une non-conformité de code ou un problème de bibliothèque est détecté. Par exemple, si le fichier domains/ecommerce/apps/myservice/foo.py
est associé à myservice, l’équipe myservice sera associée à toute non-conformité
détectée dans ce fichier.
Si aucun service ou aucune équipe n’est trouvé, Datadog utilise le fichierCODEOWNERS
dans votre référentiel. Le fichier CODEOWNERS détermine quelle équipe est propriétaire d’un fichier dans votre fournisseur Git.
Remarque : il est nécessaire de mapper avec précision vos équipes de votre fournisseur Git à vos équipes Datadog pour que cette fonctionnalité fonctionne correctement.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
