Analyse du code

L'analyse du code dans GitHub Advanced Security for Azure DevOps vous permet d'analyser le code dans un référentiel Azure DevOps pour rechercher des vulnérabilités de sécurité et des erreurs de codage. Tous les problèmes identifiés par l’analyse sont déclenchés en tant qu’alerte. L’analyse du code utilise CodeQL pour identifier les vulnérabilités.

CodeQL est le moteur d’analyse du code développé par GitHub pour automatiser les vérifications de sécurité. Vous pouvez analyser votre code à l’aide de CodeQL et afficher les résultats sous forme d’alertes d’analyse du code. Pour obtenir une documentation plus spécifique sur CodeQL, consultez la documentation CodeQL.

GitHub Advanced Security pour Azure DevOps fonctionne avec Azure Repos. Si vous souhaitez utiliser GitHub Advanced Security avec des référentiels GitHub, consultez GitHub Advanced Security.

Configurations supplémentaires pour l’analyse de code

Prise en charge des langages et des requêtes

Les experts GitHub, les chercheurs en sécurité et les contributeurs de la communauté écrivent et gèrent les requêtes CodeQL par défaut utilisées pour l’analyse du code. Les requêtes sont régulièrement mises à jour pour améliorer l’analyse et réduire les faux résultats positifs. Les requêtes sont open source. Vous pouvez donc afficher et contribuer aux requêtes dans le référentiel github/codeql.

CodeQL prend en charge et utilise les identifiants de langage suivants :

Pour plus d’informations, veuillez consulter la section Langages et frameworks pris en charge.

Vous pouvez consulter les requêtes spécifiques et les détails des tâches exécutées par CodeQL dans le journal de build.

Personnalisation du mode de build pour l’analyse de code

L’analyse de code prend en charge deux modes de build lors de la configuration d’un pipeline pour le scan :

• none : la base de données CodeQL est créée directement à partir du code source sans compiler la base de code (pris en charge pour tous les langages interprétés, et également pris en charge pour C# et Java).
• manual : vous définissez les étapes de génération à utiliser pour la codebase dans le flux de travail (pris en charge pour tous les langages compilés).

Pour plus d’informations sur les différents modes de build, y compris une comparaison des avantages de chaque mode, veuillez consulter la section Analyse de code CodeQL pour les langages compilés.

Pour exécuter une analyse de code via GitHub Advanced Security pour Azure DevOps, le mode de build autobuild devient une tâche de build distincte, AdvancedSecurity-CodeQL-Autobuild@1.

Voici un exemple de configuration valide avec plusieurs langages et le mode de build none :

trigger: none
 
pool:
  vmImage: windows-latest

steps:
- task: AdvancedSecurity-Codeql-Init@1
  displayName: Initialize CodeQL
  inputs:
# build mode `none` is supported for C# and Java, and JavaScript is an interpreted language
# and build mode `none` has no impact on JavaScript analysis
    languages: 'csharp, java, javascript' 
    buildtype: 'none'

- task: AdvancedSecurity-Codeql-Analyze@1
  displayName: Perform CodeQL Analysis

Voici un exemple de configuration non valide avec plusieurs langages et le mode de build none :

trigger: none
 
pool:
  vmImage: windows-latest

steps:
- task: AdvancedSecurity-Codeql-Init@1
  displayName: Initialize CodeQL
  inputs:
# build mode `none` is supported for C# but build mode `none` is NOT supported for Swift
# so this pipeline definition will result in a failed run
    languages: 'csharp, swift'
    buildtype: 'none'

- task: AdvancedSecurity-Codeql-Analyze@1
  displayName: Perform CodeQL Analysis

Utilisation de requêtes personnalisées avec CodeQL

Par défaut, si vous n’avez pas spécifié de fichier de configuration personnalisé dans la configuration de votre pipeline, CodeQL exécute le pack de requêtes security-extended pour analyser votre code. Vous pouvez utiliser des requêtes CodeQL personnalisées pour écrire vos propres requêtes et ainsi rechercher des vulnérabilités et des erreurs spécifiques. Vous devez également créer un fichier de configuration personnalisé pour modifier l’analyse par défaut de CodeQL.

Pour rechercher des requêtes personnalisées existantes ou pour contribuer à votre propre requête personnalisée, consultez Contribution à CodeQL.

Analyse avec des requêtes personnalisées

Le moyen le plus rapide de commencer avec une requête personnalisée consiste à écrire une requête et à l’enregistrer dans votre référentiel Azure DevOps local. Vous pouvez personnaliser les détails d’une requête personnalisée en fonction de vos besoins, mais elle doit comporter au moins un ID de règle. Pour plus d’informations sur la rédaction de vos propres requêtes CodeQL, veuillez consulter la section Rédaction de requêtes CodeQL. Vous pouvez également regrouper plusieurs requêtes dans une suite de requêtes ou utiliser des packs publiés par d’autres personnes. Pour plus d’informations, consultez la section Publication et utilisation des packs CodeQL.

Utilisation d’un fichier de configuration personnalisé

Un fichier de configuration personnalisé est un moyen de gérer les requêtes exécutées pendant l’analyse de CodeQL sur votre code. Vous pouvez spécifier plus de requêtes ou de packs de requêtes à exécuter, et changer ou désactiver les requêtes CodeQL par défaut.

Pour inclure une requête spécifique de votre choix, spécifiez la requête avec un nom et un chemin d’accès à l’emplacement du fichier de requête (.ql) dans votre référentiel.

Pour inclure un pack spécifique de votre choix, spécifiez le nom du pack. Vous pouvez spécifier n’importe quel nombre de packs de requêtes CodeQL à exécuter dans votre fichier de configuration.

L’étape suivante consiste à créer un fichier qlpack.yml. Ce fichier déclare le pack CodeQL et les informations le concernant. Tous les fichiers *.ql se trouvant dans le même répertoire (ou sous-répertoire) qu’un qlpack.yml sont considérés comme faisant partie du package.

Voici un exemple de fichier de configuration :

name: "Run custom queries"

# When using a configuration file, if you do not disable default queries,
# then the default CodeQL queries in the `code-scanning` query suite will also execute upon analysis.
disable-default-queries: true
 
# To reference local queries saved to your repository,
# the path must start with `./` followed by the path to the custom query or queries.
# Names for each query referenced is optional.
queries:
  - name: Use security-extended query suite
    uses: security-extended
  - name: Use local custom query (single query)
    uses: ./customQueries/javascript/FindTestFunctions.ql
  - name: Use local custom query (directory of queries)
    uses: ./customQueries/javascript/MemoryLeakQueries  
 
packs:
 - mygithuborg/mypackname
 
paths:
 - src
 
paths-ignore:
  - src/node_modules
  - '**/*.test.js'
 
query-filters:
 - include:
    kind: problem
 - include:
     precision: medium
 - exclude:
    id:
      - js/angular/disabling-sce
      - js/angular/insecure-url-allowlist

Si vous utilisez une requête personnalisée, voici un exemple de qlpack.yml placé dans le répertoire de vos requêtes personnalisées :

version: 1.0.1
dependencies:
  codeql/javascript-all: "*"
  codeql/javascript-queries: "*"

La variable dependencies contient toutes les dépendances de ce package et leurs plages de versions compatibles. Chaque dépendance est référencée comme le scope/name d’un pack de bibliothèque CodeQL. Lors de la définition de dependencies, votre qlpack.yml dépend exactement de l’un des packs de langage de base (par exemple, JavaScript, C#, Ruby, etc.), ce qui détermine le langage que votre requête peut analyser.

Pour des conseils plus spécifiques et des options de configuration avec votre fichier de configuration, veuillez consulter la section Personnalisation de votre configuration avancée pour l’analyse de code ou pour configuration de qlpack.yml, consultez la section Structure du pack CodeQL.

Une fois que vous avez votre fichier de configuration, vous devez personnaliser votre pipeline exécutant l’analyse CodeQL pour pouvoir utiliser votre nouveau fichier. Voici un exemple de pipeline pointant vers un fichier de configuration :

trigger: none
 
pool:
  vmImage: windows-latest

# You can either specify your CodeQL variables in a variable block... 
variables:
# `configfilepath` must be an absolute file path relative to the repository root
  advancedsecurity.codeql.configfilepath: '$(build.sourcesDirectory)/.pipelines/steps/configfile.yml' 

# Or you can specify variables as variables for the task. You do not need both definitions. 
steps:
- task: AdvancedSecurity-Codeql-Init@1
  displayName: Initialize CodeQL
  inputs:
    languages: 'javascript'
    loglevel: '2'
    configfilepath: '$(build.sourcesDirectory)/.pipelines/steps/configfile.yml'
# If downloading a pack from GitHub,
# you must include a GitHub access token with the scope of `read:packages`.
  env:
    GITHUB_TOKEN: $(githubtoken)

- task: AdvancedSecurity-Codeql-Analyze@1
  displayName: Perform CodeQL Analysis

Alertes d’analyse du code

GitHub Advanced Security pour les alertes d’analyse du code Azure DevOps incluent des indicateurs d’analyse de code par référentiel qui alertent des vulnérabilités d’application au niveau du code.

Pour utiliser l’analyse du code, vous devez d’abord configurer GitHub Advanced Security pour Azure DevOps.

L’onglet Advanced Security sous Repos dans Azure DevOps est le hub pour afficher vos alertes d’analyse du code. Sélectionnez l’onglet Analyse du code pour afficher les alertes d’analyse. Vous pouvez filtrer par branche, état, pipeline, type de règle et gravité. À ce jour, le hub d’alertes n’affiche pas les alertes pour les analyses effectuées sur les branches PR.

Il n’y a aucun effet sur les résultats si les pipelines ou les branches sont renommés. Cela peut prendre jusqu’à 24 heures avant que le nouveau nom ne s’affiche.

Si vous choisissez d’exécuter des requêtes CodeQL personnalisées, il n’existe pas par défaut de filtre séparé pour les alertes générées à partir de différents packs de requêtes. Vous pouvez filtrer par règle, qui est différente pour chaque requête.

Si vous désactivez Advanced Security pour votre référentiel, vous perdez l’accès aux résultats dans l’onglet et la tâche de build Advanced Security. La tâche de build ne échoue pas, mais tous les résultats des builds exécutés avec la tâche alors qu’Advanced Security est désactivé sont masqués et non conservés.

Détails de l’alerte

Sélectionnez une alerte pour plus d’informations, notamment des conseils de correction. Chaque alerte inclut un emplacement, une description, un exemple et une gravité.

Affichage des alertes pour un dépôt

Toute personne disposant d’autorisations contributeur pour un référentiel peut afficher un résumé de toutes les alertes pour un référentiel sous l’onglet Advanced Security sous Repos. Sélectionnez l’onglet Analyse du code pour afficher toutes les alertes d’analyse des secrets.

Pour afficher les résultats, les tâches d’analyse du code doivent d’abord s’exécuter. Une fois la première analyse terminée, toutes les vulnérabilités détectées s’affichent sous l’onglet Advanced Security.

Par défaut, la page des alertes affiche les résultats de l’analyse des dépendances pour la branche par défaut du référentiel.

Le statut d’une alerte donnée reflète l’état du pipeline branche par défaut et de la dernière exécution, même si l’alerte existe sur d’autres branches et pipelines.

Ignorer les alertes d’analyse du code

Pour ignorer les alertes, vous avez besoin des autorisations appropriées. Par défaut, seuls les administrateurs de projet peuvent ignorer les alertes de sécurité avancée.

Pour ignorer une alerte :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez-la.
2. Sélectionnez la liste déroulante Fermer l’alerte.
3. S’il n’est pas déjà sélectionné, sélectionnez Risque accepté ou Faux positif comme raison de fermeture.
4. Ajoutez un commentaire facultatif dans la zone de texte Commentaire.
5. Sélectionnez Fermer pour envoyer et fermer l’alerte.
6. L’état d’alerte passe de Ouvert à Fermé et votre motif de licenciement s’affiche.

Cette action ignore uniquement l’alerte de votre branche sélectionnée. Les autres branches qui contiennent la même vulnérabilité restent actives tant qu’elles ne sont pas ignorées. Toute alerte précédemment ignorée peut être rouverte manuellement.

Gestion des alertes d’analyse de code sur les pull requests

Si des alertes sont créées pour de nouvelles modifications de code dans une pull request, l’alerte sera signalée comme une annotation dans la section des commentaires de l’onglet Vue d’ensemble de la pull request et comme une alerte dans l’onglet Sécurité avancée du référentiel, avec un nouveau résultat de sélection de branche pour la branche de la pull request.

Vous pouvez voir les lignes de code affectées, consulter un résumé de la découverte et résoudre l’annotation dans la section Vue d’ensemble.

Pour rejeter les alertes de pull request, vous devez naviguer vers la vue détaillée de l’alerte pour fermer à la fois l’alerte et résoudre l’annotation. Sinon, le simple fait de changer le statut du commentaire (1) résout l’annotation mais ne ferme pas ou ne corrige pas l’alerte sous-jacente.

Pour voir l’ensemble des résultats de votre branche de pull request, naviguez vers Repos>Sécurité avancée et sélectionnez votre branche de pull request. La sélection de Afficher plus de détails (2) sur l’annotation vous dirigera vers la vue détaillée de l’alerte dans l’onglet Sécurité avancée.

![CONSEIL] Les annotations ne seront créées que lorsque les lignes de code affectées sont entièrement uniques à la différence de la pull request.

Dépannage de l’analyse du code

En règle générale, si vous rencontrez des erreurs avec l’exécution de CodeQL, l’interface de ligne de commande de CodeQL signale l’état de chaque commande qu’elle exécute en tant que code de sortie. Le code de sortie fournit des informations pour les commandes suivantes ou pour d’autres outils qui s’appuient sur l’interface de ligne de commande de CodeQL. Pour plus d’informations sur les détails du code de sortie, veuillez consulter la section Codes de sortie.

Erreur : commande CodeQL 'database finalize' (32)

Cette erreur indique un problème lors de la finalisation de la création de la base de données CodeQL, potentiellement lié à des erreurs d’extraction ou des étapes de génération manquantes.

Procédure de résolution :

1. Vérifier que le code existe et qu’il est compilé
   • Pour les langages compilés, vérifiez que le processus de génération compile le code et se produit entre les tâches AdvancedSecurity-Codeql-Init et les tâches AdvancedSecurity-Codeql-Analyze. Les commandes de build courantes et les indicateurs requis (tels que clean no-cache/no-daemon) sont disponibles ici lors de la spécification des commandes de build.
   • Pour les langages interprétés, vérifiez qu’il existe du code source pour la langue spécifiée dans le projet.
2. Vérifier les erreurs d’extraction
   • Vérifiez si les erreurs d’extraction affectent l’intégrité de la base de données CodeQL.
   • Passez en revue le fichier journal pour connaître les erreurs d’extraction et les avertissements afin d’évaluer l’intégrité globale de la base de données.
3. Examiner les erreurs de surcharge
   • Si la plupart des fichiers rencontrent des erreurs d’extraction, examinez plus en détail la cause racine du problème d'extraction.

Erreur : script de génération automatique (1)

Cette erreur décrit un échec de build automatique, ce qui suggère un problème lié à l’installation ou à la configuration de l’analyse du code.

Procédure de résolution :

1. Configurer les étapes de build
   • Supprimez l’étape AutoBuild et configurez plutôt des étapes de génération spécifiques pour les langages compilés dans vos pipelines.
   • Reportez-vous aux instructions de configuration figurant dans Configurer GitHub Advanced Security pour Azure DevOps.

Erreur : répertoires CodeQL introuvables dans le cache des outils de l’agent

Cette erreur indique un problème lié à l’installation de CodeQL pour les agents auto-hébergés.

Procédure de résolution :

1. Reportez-vous aux instructions d’installation ou aux scripts de configuration figurant dans Configurer GitHub Advanced Security pour Azure DevOps.

Erreur : variable de pipeline de langage non définie

Cette erreur se produit lorsqu’une tentative d’exécution de CodeQL est faite sans définir la variable de pipeline spécifiant les langages à analyser.

Procédure de résolution :

1. Définir la variable de pipeline de langage
   • Vérifiez que la variable de pipeline de langage est correctement configurée. Reportez-vous aux instructions de configuration figurant dans Configurer GitHub Advanced Security pour Azure DevOps.
   • Les langues prises en charge sont csharp, cpp, go, java, javascript, python, ruby et swift.

CodeQL ne retourne aucun résultat

Cette section fournit des conseils pour les situations où l’analyse CodeQL ne produit aucun résultat.

Procédure de résolution :

1. Vérifier les vulnérabilités détectées
   • Considérez la possibilité que votre code ne présente aucune vulnérabilité. Si des vulnérabilités sont attendues, mais qu’elles ne sont pas détectées, passez à la vérification.
2. Vérifier la configuration de la suite de requêtes
   • Vérifiez la suite de requêtes utilisée et envisagez de passer à une suite plus complète si nécessaire.
   • Vous pouvez également créer des suites de requêtes personnalisées pour une analyse personnalisée.
3. Ajuster les autorisations pour l’affichage des résultats
   • Assurez-vous que les autorisations appropriées, au moins au niveau contributeur, sont accordées pour accéder aux résultats d’analyse. Pour plus d’informations, consultez la section Autorisations Advanced Security.

Expiration de CodeQL

Si la tâche AdvancedSecurity-Codeql-Analyze@1 affiche This job was abandoned ... we lost contact with the agent et que vous utilisez un agent Microsoft hébergé, la tâche atteint la limite de six heures intégrée pour les agents hébergés payants. Vous pouvez essayer d’exécuter l’analyse sur un agent auto-hébergé à la place.

Autorisations de tâche d’analyse du code

La tâche de génération d’analyse du code utilise l’identité du pipeline pour appeler les API REST Sécurité avancée. Par défaut, les pipelines du même projet ont un accès pour charger le fichier SARIF généré en exécutant l’analyse CodeQL. Si ces autorisations sont retirées du compte de service de build ou si vous avez une configuration personnalisée (par exemple, un pipeline hébergé dans un projet différent du référentiel), vous devez accorder ces autorisations manuellement.

Procédure de résolution :

• Accordez les autorisations Advanced Security: View alerts et Advanced Security: Manage and dismiss alerts au compte de service de build utilisé dans votre pipeline qui est [Project Name] Build Service ([Organization Name]) pour des pipelines délimités par le projet et Project Collection Build Service ([Organization Name]) pour des pipelines délimités par la collection.

Installation manuelle du bundle CodeQL sur un agent auto-hébergé

Installez le bundle CodeQL dans le cache d’outils de l’agent en utilisant le script d’installation de votre architecture, disponible sur GitHub. Ces scripts nécessitent que la variable d’environnement $AGENT_TOOLSDIRECTORY soit définie sur l’emplacement du répertoire des outils d’agent sur l’agent, par exemple C:/agent/_work/_tool. Vous pouvez également implémenter manuellement les étapes suivantes :

1. Choisissez la dernière offre groupée de publication CodeQL à partir de GitHub.
2. Téléchargez et décompressez le bundle dans le répertoire suivant dans le répertoire de l'outil de l'agent, généralement situé sous _work/_tool : ./CodeQL/0.0.0-[codeql-release-bundle-tag]/x64/. À l’aide de la version actuelle de v2.16.0, le nom du dossier est intitulé ./CodeQL/0.0.0-codeql-bundle-v2.16.0/x64/. En savoir plus sur le répertoire des outils d'agent.
3. Créez un fichier vide intitulé x64.complete dans le dossier ./CodeQL/0.0.0-[codeql-release-bundle-tag]. D'après l’exemple précédent, le chemin d’accès à votre fichier x64.complete doit être ./CodeQL/0.0.0-codeql-bundle-v2.16.0/x64.complete.