GitHub étend le secret scanning aux logs de GitHub Actions

GitHub a annoncé le 9 novembre 2026 l’arrivée en préversion publique d’une détection de secrets dans les journaux d’exécution de GitHub Actions. Jusqu’ici, le secret scanning couvrait le code source et quelques autres emplacements, mais laissait de côté les logs générés par les workflows eux-mêmes, un vecteur de fuite pourtant courant lorsqu’une étape de build affiche par mégarde une variable sensible.

#Pourquoi ce point aveugle comptait

Un workflow CI/CD manipule en permanence des jetons, des clés d’API et des identifiants de déploiement. Une simple commande de débogage, un print oublié ou une erreur mal gérée suffisent à faire apparaître ces valeurs dans un log public ou partagé, sans qu’aucun des outils de scan habituels ne les détecte puisqu’ils ne sont pas commités dans le dépôt.

#Comment la fonctionnalité fonctionne

Une fois activée, GitHub analyse les journaux de chaque run après son exécution complète ; les runs passés ne sont pas repris rétroactivement. Les secrets détectés remontent dans la liste d’alertes de secret scanning du dépôt, au même titre que les alertes issues du code, avec un lien direct vers l’emplacement dans le log. Des vérifications de validité s’appliquent aux types de secrets qui le permettent, et les alertes restent consultables même après suppression des journaux correspondants.

#Activer la détection

L’activation se fait au niveau de l’entreprise, dans les paramètres : Policies, puis Advanced Security, où il faut positionner Secret scanning for Actions workflow logs sur Enabled pour l’ensemble des dépôts concernés. La fonctionnalité ne s’applique qu’aux dépôts sur lesquels le secret scanning classique est déjà actif.

name: build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: |
          # une commande de debug qui fuiterait la variable finirait
          # desormais aussi dans la liste d'alertes de secret scanning
          ./build.sh

Les journaux déjà existants ne sont pas réanalysés rétroactivement : seuls les runs terminés après l’activation sont couverts.

#Les limites de cette préversion

La couverture reste partielle : seuls les motifs de fournisseurs connus sont détectés, à l’exclusion des motifs génériques ou personnalisés et des secrets identifiés par des méthodes heuristiques. L’absence de notification pendant la phase de préversion impose aussi de consulter manuellement la liste d’alertes du dépôt plutôt que de compter sur une relance automatique. Le sujet reste proche de celui déjà documenté dans le guide sur le socle minimal de durcissement, où la discipline d’activation précède toujours la détection.

#Ce qu’il faut retenir

Cette extension comble un angle mort connu des équipes qui opèrent des pipelines GitHub Actions, sans pour autant remplacer les bonnes pratiques de base : masquage systématique des secrets, rotation régulière, et limitation du périmètre des jetons utilisés en CI/CD. Le sujet s’inscrit dans la continuité du blocage par défaut de pull_request_target, une autre évolution récente de la plateforme destinée à réduire la surface d’attaque des workflows.

#Pour aller plus loin

Source primaire : le changelog officiel de GitHub, 9 novembre 2026.