GitHub Advanced Security : outils de vérification du code, détection des secrets et activation en masse de Dependabot

Accueil › Actualités › GitHub Advanced Security : outils de vérification du code, détection des secrets et activation en masse de Dependabot

30 mai 2026

GitHub Advanced Security : outils de vérification du code, détection des secrets et activation en masse de Dependabot

L’objectif de cet outil est d’aider à activer GitHub Advanced Security (GHAS) sur plusieurs dépôts de manière automatisée. Il peut arriver que vous deviez activer la vérification de code (CodeQL), la vérification de secrets, les alertes de Dependabot et/ou les mises à jour de sécurité de Dependabot sur divers dépôts, et que vous ne souhaitiez pas cliquer manuellement sur des boutons ou ajouter un flux de travail GitHub pour CodeQL dans chaque dépôt. Le faire manuellement est fastidieux et long. L’objectif de cet outil est d’automatiser ces tâches manuelles.

Contexte

La motivation principale de cet outil est CodeQL. Activer CodeQL sur plusieurs dépôts prend énormément de temps. De plus, aucune API n’offre d’accès en écriture au répertoire .github/workflow/. Cela signifie que les équipes doivent écrire plusieurs scripts avec des résultats différents. Cet outil propose une méthode éprouvée pour effectuer cela.

La vérification des secrets et Dependabot est également difficile à activer si vous souhaitez le faire seulement sur certains dépôts plutôt que sur l’ensemble. Cet outil permet de le faire facilement.

À quoi sert cet outil ?

Cet outil réalise deux actions principales :

Partie Une :

Le système collecte les dépôts qui disposent des fonctionnalités d’Analyse de Code (CodeQL), d’Analyse des Secrets, de Protection contre l’Envoi de Secrets, des Alertes de Dependabot, des Mises à jour de sécurité de Dependabot et des Actions activées. Il existe trois façons principales de collecter ces dépôts.

Si vous sélectionnez l’option 1, le script renverra tous les dépôts dans la langue spécifiée (auxquels vous avez accès). Les dépôts collectés par ce script seront stockés dans un fichier repos.json. Si vous sélectionnez l’option 2, le script renverra tous les dépôts dont vous êtes administrateur. La troisième option consiste à définir repos.json manuellement. Nous ne recommandons pas cette option, mais elle est possible. Si vous optez pour cette voie, exécutez d’abord l’une des options ci-dessus pour collecter automatiquement des informations sur les dépôts, observez la structure et créez votre liste de dépôts selon le format défini.

Partie Deux :

Parcours des dépôts trouvés dans le fichier repos.json et activation de la vérification de code (CodeQL), de la vérification de secrets, de la Protection contre l’envoi de secrets, des alertes de Dependabot et des mises à jour de sécurité de Dependabot.

Pré-requis

Instructions d’installation

  1. Clonez ce dépôt sur votre machine locale.

    git clone https://github.com/NickLiffen/ghas-enablement.git

  2. Changez de répertoire vers le dépôt que vous venez d’installer.

    cd ghas-enablement

  3. Générez la stratégie d’authentification choisie. Vous pouvez utiliser une application GitHub ou un Token d’accès personnel (PAT). L’application GitHub doit disposer des permissions de read and write pour le nom <nom_de_lappli>, … Le PAT GitHub doit avoir accès uniquement à <nom_de_lappli>, <nom_de_lappli> et <nom_de_lappli>. (Si vous utilisez l’application GitHub, administration aura également besoin de Code scanning alerts du périmètre <nom_de_lappli>.)

  4. Copiez le contenu de .env.sample dans le répertoire .env. Sur Mac, cela peut être fait via la commande suivante dans le terminal :

    cp .env.sample .env

  5. Mettez à jour le champ .env avec les valeurs nécessaires. Sélectionnez l’un des modes d’authentification pour interagir avec GitHub. Vous pouvez remplir le champ GITHUB_API_TOKEN avec un PAT qui a accès à l’organisation OU remplir tous les champs requis pour une application GitHub. Remarque : il est recommandé de choisir l’option d’application GitHub si vous exécutez cet outil sur des milliers de dépôts, car cela offre davantage de requêtes API qu’un PAT.

    • Si vous utilisez une application GitHub, collez la valeur exactement telle qu’elle est dans le champ APP_PRIVATE_KEY entre guillemets doubles (la clé occupe plusieurs lignes) ou convertissez-la en une seule ligne entre guillemets doubles en remplaçant les retours à la ligne par \n (sur VS Code pour Mac, vous pouvez utiliser Ctrl + Enter pour localiser/remplacer le caractère de nouvelle ligne).

  6. Mettez à jour la valeur GITHUB_ORG trouvée dans .env. Remplacez le XXXX par le nom de l’organisation GitHub que vous souhaitez utiliser avec ce script. Note : si vous exécutez ce script sur plusieurs organisations au sein d’une entreprise, vous ne pourrez pas définir la variable GITHUB_ORG dans organizations, mais plutôt la variable GITHUB_ENTERPRISE avec le nom de l’entreprise. Ensuite, exécutez yarn run getOrgs, ce qui vous permettra d’exécuter ./organizations pour collecter dynamiquement toutes les organisations. Cela signifie que vous n’aurez pas besoin de définir manuellement une organisation. Cependant, dans la plupart des cas, il suffit de définir manuellement l’organisation spécifique dans la variable GITHUB_ORG organizations où vous souhaitez que le script s’exécute.

  7. Mettez à jour la valeur LANGUAGE_TO_CHECK trouvée dans .env. Remplacez le XXXX par le langage que vous souhaitez utiliser comme filtre lors de la collecte des dépôts. Note : assurez-vous que ces valeurs soient en minuscules, par exemple : javascript, typescript, python, go, ruby, c#, c++, java, ou kotlin.

  8. Décidez de ce que vous souhaitez activer. Mettez à jour la valeur ENABLE_ON pour choisir ce que vous souhaitez activer dans les dépôts trouvés dans repos.json. Cela peut être une ou plusieurs valeurs. Si vous activez uniquement la vérification de code (Code Scanning), vous devrez définir ENABLE_ON=codescanning; si vous activez tout, vous devrez définir ENABLE_ON=codescanning,secretscanning,pushprotection,dependabot,dependabotupdates,actions. Vous pouvez en choisir un, deux ou trois. Le format est une liste séparée par des virgules.

  9. OPTIONNEL : Mettez à jour la valeur CREATE_ISSUE true/false selon que vous souhaitiez créer une issue expliquant le but de la PR. Nous recommandons cela, car cela aidera à expliquer pourquoi la PR a été créée et fournira un contexte. Cependant, cela reste optionnel. Le texte qui se trouve dans l’issue peut être modifié et se trouve ici : ./src/utils/text/.

  10. OPTIONNEL : Si vous utilisez GHES, vous devrez définir la variable d’environnement GHES sur true, puis définir GHES_SERVER_BASE_URL sur l’URL de votre instance GHES. Exemple : https://octodemo.com.

  11. OPTIONNEL : Si vous prévoyez d’activer des fonctionnalités au niveau de l’organisation, yarn run enableOrg vous donnera aussi l’option ENABLE_ON=...,automatic pour configurer ces éléments « automatically enable for new repositories » pour chaque produit individuellement.

  12. Si vous activez l’Analyse de Code (CodeQL), vérifiez le fichier codeql-analysis.yml. Il s’agit d’un fichier d’exemple ; configurez-le selon les besoins de votre dépôt.

  13. Exécutez npm install yarn install ou npm install pour installer les dépendances nécessaires.

  14. Exécutez npm run build yarn run build ou npm run build pour bâtir le paquet JavaScript à partir de TypeScript.

Comment l’utiliser ?

Deux étapes simples pour lancer l’opération :

Étape Une

La première étape consiste à collecter les dépôts sur lesquels vous souhaitez exécuter ce script. Vous avez trois options, comme mentionné ci-dessus. L’Option 1 est automatisée et retrouve tous les dépôts au sein d’une organisation sur laquelle vous avez un accès administrateur. L’Option 2 est aussi automatisée et retrouve tous les dépôts d’une organisation en fonction de la langue que vous spécifiez. Ou, l’Option 3, qui consiste à saisir manuellement les dépôts sur lesquels vous souhaitez exécuter ce script. Voir les informations ci-dessous.

OPTION 1 (Préférence)

# Dans le fichier `.env`, définissez `LANGUAGE_TO_CHECK=` sur la langue. Par ex.: `javascript`, `typescript`, `python`, `go`, `ruby`, `c#`, `c++`, `java`, ou `kotlin`
yarn run getRepos # ou npm run getRepos

En utilisant GitHub Actions, il est fréquent de constater (surtout pour des langages qui ne nécessitent pas de compilation, comme JavaScript) que le fichier codeql-analysis.yml est répétable et cohérent sur plusieurs dépôts du même langage. Dans environ 80 % des cas, les équipes peuvent réutiliser les mêmes fichiers de flux de travail pour le même langage. Pour Java et C++, ce chiffre descend à environ 60 %. Nous recommandons d’activer la vérification de code par lot par langage, car le fichier codeql-analysis.yml proposé dans la PR a le plus de chances d’être le plus précis. Même si le fichier doit être ajusté, l’équipe qui examinera la PR n’aura probablement besoin que de très petites modifications. Nous vous recommandons d’exécuter cette commande en premier afin d’obtenir une liste de dépôts à activer la vérification de code. Après l’exécution de la commande, vous pouvez modifier le fichier ./bin/repos.json. Assurez-vous simplement que c’est un fichier JSON valide avant d’enregistrer.

Ce script ne renvoie que les dépôts pour lesquels les résultats de CodeQL n’ont pas encore été envoyés à la vérification de code. Si des résultats CodeQL ont déjà été envoyés à la vérification de code pour un dépôt, ce dépôt ne sera pas inclus dans cette liste. L’objectif est d’éviter de créer des pull requests dans des dépôts où CodeQL est déjà activé.

OPTION 2

# Dans le fichier `.env`, laissez `LANGUAGE_TO_CHECK=` vide pour récupérer tous les dépôts
yarn run getRepos # ou npm run getRepos

Tout comme l’étape précédente, une autre approche automatisée consiste à activer l’accès par l’utilisateur (c’est-à-dire activer pour tous les dépôts auxquels l’utilisateur/PAT a accès administratif). Cette approche sera légèrement moins précise, car le fichier codeql-analysis.yml devra sans doute être adapté entre un projet Python et un projet Java (si vous activez CodeQL). Mais le fichier que vous proposez sera un bon point de départ. Après exécution du commande, vous pourrez modifier le fichier ./bin/repos.json. Assurez-vous simplement que c’est un fichier JSON valide avant d’enregistrer.

Ce script ne renvoie que les dépôts pour lesquels les résultats de CodeQL n’ont pas encore été envoyés à la vérification de code. Si des résultats CodeQL ont déjà été envoyés à la vérification de code pour un dépôt, ce dépôt ne sera pas inclus dans cette liste. L’objectif est d’éviter de créer des pull requests dans des dépôts où CodeQL est déjà activé.

OPTION 3

Créez un fichier nommé organization.json dans le répertoire ./bin/. Ce fichier doit contenir un tableau d’objets d’organisation, chacun avec son propre tableau d’objets de dépôts. La structure des objets doit ressembler à ceci :

[
  {
    "login": "string <org>",
    "repos":
    [
      {
        "createIssue": "boolean",
        "enableCodeScanning": "boolean",
        "enableDependabot": "boolean",
        "enableDependabotUpdates": "boolean",
        "enablePushProtection": "boolean",
        "enableSecretScanning": "boolean",
        "enableActions": "boolean",
        "repo": "string <org/repo>",
      }
    ]
  }
]

Comme vous pouvez le voir, l’objet accepte plusieurs clés booléennes : createIssue true, enableCodeScanning false, enableDependabot false, enableDependabotUpdates false, enablePushProtection false, enableSecretScanning true, et enableActions ainsi qu’une seule clé chaîne de caractères, repo. Définissez repo comme le nom du dépôt sur lequel vous souhaitez exécuter ce script. Définissez enableDependabot sur true si vous souhaitez activer également les Alertes de Dependabot dans ce dépôt ; définissez-le sur false si vous ne voulez pas les activer. Il en va de même pour enableDependabotUpdates pour dependabot_security_updates, enableSecretScanning pour dependabot_secret_scanning, pushprotection pour dependabot_secret_scanning_push_protection, enableCodeScanning pour dependabot_code_scanning_code_ql et enableActions pour activer les Actions. Enfin, définissez createIssue sur true si vous souhaitez créer une issue dans le dépôt avec le texte trouvé dans le fichier ./src/utils/text/issueText.ts afin d’accompagner la PR.

NOTE : Le compte qui a généré le PAT doit disposer des droits d’écriture ou de privilèges supérieurs sur tout dépôt inclus dans la clé repos.

Étape Deux

Exécutez le script qui active la vérification de code (et/ou les alertes de Dependabot/mises à jour de sécurité de Dependabot/vérification des secrets) dans votre dépôt, en lançant la commande suivante :

yarn run start // ou npm run start

Cela exécutera un script et vous devriez voir le texte de sortie apparaître à l’écran.

Après l’exécution du script, accédez au répertoire ~/Desktop sur votre ordinateur et supprimez le dossier tempGitLocations qui a été créé automatiquement.

Exécuter ceci via la CLI

Ce cli.sh est un script Bash qui englobe les fonctionnalités de cet outil. Il vise à étendre les capacités de l’outil et à le rendre plus facile à utiliser afin d’obtenir une mise en œuvre maîtrisée du GHAS. Le script se trouve dans le répertoire racine de ce dépôt.

L’interface en ligne de commande (CLI) aide à répondre à les cas d’utilisation suivants :

Cas d’utilisation 1 : Activer le GHAS sur tous les dépôts de toutes vos organisations.

  1. Créez un token d’accès personnel (PAT) GitHub.
  2. Lancez la CLI en exécutant la commande ./cli.sh dans le répertoire racine de ce dépôt.
  3. Sélectionnez l’option 5. Configure option pour créer votre fichier .env.
  1. Sélectionnez l’option 1. Get Organizations in your Enterprise pour obtenir une liste de toutes vos organisations.
  2. Sélectionnez l’option 2. Enable features for Organization - For all repos at once pour activer les ressources GHAS sélectionnées.
  3. Lorsqu’on vous demande de choisir une organisation, tapez all pour sélectionner toutes les organisations.
  4. Sélectionnez l’option 4. Print progress pour vérifier la progression et confirmer que toutes les organisations ont été traitées.

Cas d’utilisation 2 : Activer le GHAS sur tous les dépôts de manière contrôlée : organisation par organisation.

  1. Créez un token d’accès personnel (PAT) GitHub.
  2. Lancez la CLI en exécutant la commande ./cli.sh dans le répertoire racine de ce dépôt.
  3. Sélectionnez l’option 5. Configure option pour créer votre fichier .env.
  1. Sélectionnez l’option 1. Get Organizations in your Enterprise pour obtenir une liste de toutes vos organisations.
  2. Sélectionnez l’option 2. Enable features for Organization - For all repos at once pour activer les ressources GHAS sélectionnées.
  3. Lorsque vous êtes invité à sélectionner une organisation, saisissez next pour voir les 10 organisations suivantes sur lesquelles GHAS n’a pas encore été activé.
  4. Saisissez le nom de l’organisation sur laquelle vous souhaitez activer les ressources GHAS sélectionnées.
  5. Sélectionnez l’option 4. Print progress pour vérifier la progression et confirmer que toutes les organisations ont été traitées.
  6. Répétez les étapes 5 à 7 jusqu’à ce que toutes les organisations aient été traitées.

Notes :

Exécuter ceci dans un Codespace ?

Il y a quelques points importants à considérer si vous exécutez ce script dans un Codespace GitHub  :

  1. Vous devrez ajouter le fragment suivant au fichier .devcontainer/devcontainer.json :
  "codespaces": {
    "repositories": [
      {
        "name": "<ORG_NAME>/*",
        "permissions": "write-all"
      }
    ]
  }

La raison d’insérer ce fragment dans votre fichier .devcontainer/devcontainer.json est que le GITHUB_TOKEN du Codespace lié devra accéder à d’autres dépôts au sein de votre organisation, avec lesquels ce script peut interagir. Vous aurez besoin de créer un nouveau Codespace après avoir ajouté le code ci-dessus et l’avoir poussé dans votre dépôt.

Vous n’avez pas besoin de suivre ce qui précède si vous n’exécutez pas le code à partir d’un Codespace.

Exécution via un flux de travail GitHub (planifié)

Comme cet outil utilise un PAT ou une authentification d’application GitHub chaque fois que l’authentification est nécessaire, il peut être exécuté de façon automatisée. Vous pouvez voir ci-dessous un exemple illustrant l’exécution de l’outil dans un flux de travail GitHub planifié. Au lieu d’utiliser le fichier .env, vous pouvez configurer toutes les variables dans le fichier .env.sample directement comme des variables d’environnement. Cela vous permettra d’utiliser (facilement) des secrets d’Actions pour les identifiants PAT ou de l’application GitHub.

on:
  schedule:
    - cron: "5 16 * * 1"

env:
  APP_ID: ${{ secrets.GHAS_ENABLEMENT_APP_ID }}
  APP_CLIENT_ID: ${{ secrets.GHAS_ENABLEMENT_APP_CLIENT_ID }}
  APP_CLIENT_SECRET: ${{ secrets.GHAS_ENABLEMENT_APP_CLIENT_SECRET }}
  APP_PRIVATE_KEY: ${{ secrets.GHAS_ENABLEMENT_APP_PRIVATE_KEY }}
  ENABLE_ON: "codescanning,secretscanning,pushprotection,dependabot,dependabotupdates,actions"
  DEBUG: "ghas:*"
  CREATE_ISSUE: "false"
  GHES: "false"
  # Variables spécifiques à l’organisation
  APP_INSTALLATION_ID: "12345678"
  GITHUB_ORG: "my-target-org"

jobs:
  enable-security-javascript:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          repository: NickLiffen/ghas-enablement
      - name: Get dependencies and configure
        run: |
          yarn
          git config --global user.name "ghas-enablement"
          git config --global user.email "[email protected]"
      - name: Enable security on organization (javascript)
        run: |
          npm run getRepos
          npm run start
        env:
          LANGUAGE_TO_CHECK: "javascript"
          TEMP_DIR: ${{ github.workspace }}

Vous pouvez dupliquer l’étape finale pour les autres langages couramment utilisés dans votre entreprise/organisation. Si vous n’avez pas configuré l’outil comme une application GitHub, vous pouvez retirer toutes les configurations APP_* et utiliser l’exemple du fichier GITHUB_API_TOKEN. Ci-dessus, nous avons utilisé le fichier CodeQL d’exemple pour JavaScript inclus dans ce dépôt. Sinon, vous pouvez ajouter ce workflow dans un dépôt contenant vos fichiers CodeQL personnalisés et les utiliser pour remplacer les exemples.

Vous avez trouvé un problème ?

Fabien Delpont

Auteur

Fabien Delpont

Fabien Delpont, développeur et créateur du site Python Doctor.