Laravel Moat : auditer la sécurité de vos repositories GitHub

Il y a quelques jours, nous publiions un article revenant sur la compromission massive de Laravel Lang et les conséquences potentielles d'une attaque supply chain dans l'écosystème PHP.

La sécurité d'une application ne dépend plus uniquement du code que vous écrivez.

Aujourd'hui, une grande partie des attaques vise directement votre chaîne de livraison : dépendances compromises, workflows GitHub mal configurés, permissions trop larges ou secrets exposés.

Ces problèmes sont souvent invisibles jusqu'au jour où quelque chose tourne mal.

C'est précisément pour répondre à cette problématique que Laravel a récemment dévoilé Moat, un outil capable d'auditer automatiquement la configuration sécurité de vos repositories GitHub.

Moat ne cherche pas des vulnérabilités dans votre code, son objectif est différent : analyser votre posture de sécurité autour de GitHub et identifier les mauvaises pratiques avant qu'elles ne deviennent un problème.

Pourquoi Laravel Moat existe

Ces dernières années, les attaques supply chain se sont multipliées. Le principe est simple : au lieu d'attaquer directement une application, les attaquants ciblent les outils qui gravitent autour du projet.

Les vecteurs d'attaque les plus fréquents sont une GitHub Action compromise, une dépendance malveillante, un mainteneur dont le compte GitHub est piraté, des permissions CI/CD trop permissives ou encore des secrets exposés dans un workflow.

Dans beaucoup de cas, le problème ne vient même pas du code métier : une mauvaise configuration GitHub peut suffire à compromettre tout un pipeline de déploiement.

C'est là que Moat devient intéressant : il automatise une grande partie des vérifications qu'un audit sécurité GitHub demanderait normalement de faire manuellement.

Installation

Moat s'installe via Homebrew sur macOS et Linux :

1brew tap laravel/moat https://github.com/laravel/moat
2brew install laravel/moat/moat

Des binaires précompilés sont également disponibles pour les autres plateformes. Il suffit de télécharger l'archive correspondant à votre système depuis la page des releases et de placer l'exécutable moat dans votre PATH.

Une fois installe, la commande moat devient disponible dans votre terminal.

Authentification

L'outil fonctionne grâce à l'API GitHub, il résout automatiquement un token dans cet ordre de priorité :

1. La variable d'environnement GITHUB_TOKEN
2. La variable d'environnement GH_TOKEN
3. La commande gh auth token si le GitHub CLI est installe et connecte

Pour exporter votre token manuellement :

1export GITHUB_TOKEN=your-token

Pour auditer une organisation, le token doit disposer des scopes admin:org, repo et workflow. Pour un compte utilisateur seul, repo et workflow suffisent.

Auditer un repository

Moat peut analyser une organisation entière :

1moat votre-organisation

Ou un repository spécifique :

1moat owner/repository

Après l'analyse, l'outil affiche un ensemble de vérifications accompagnées d'un statut. Certaines seront marquées comme réussies, d'autres comme problématiques.

L'objectif est simple : identifier rapidement les points faibles de votre configuration GitHub.

Ce que Moat verifie

La protection des branches

Moat vérifie si vos branches sensibles sont protégées. Sans protection de branche n'importe quel contributeur possédant les droits nécessaires pourrait pousser directement du code sur votre branche principale.

Une protection correcte implique généralement d'exiger des revues de pull request, de soumettre les changements à des status checks et de restreindre les force pushes.

Ces protections constituent aujourd'hui une base indispensable sur n'importe quel projet sérieux.

Les GitHub Actions

Les workflows GitHub Actions sont devenus une cible fréquente. Une mauvaise pratique tres répandue consiste a referencer une action uniquement via un tag :

1uses: actions/checkout@v4

Ce fonctionnement semble pratique, mais il introduit un problème : le contenu réel derrière v4 peut évoluer. Lorsque tj-actions/changed-files a été compromis en 2025, l'attaquant a simplement redirigé les tags existants vers du code malveillant, et tous les workflows référencant ces tags ont instantanément exécuté le code infecté.

Moat recommande plutôt l'utilisation d'un SHA précis :

1uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608

Cette approche garantit que votre workflow exécute exactement le code attendu, quoi qu'il arrive au tag d'origine.

Les permissions des workflows

Par défaut, certaines permissions GitHub Actions peuvent être beaucoup trop larges. Un workflow capable d'écrire dans le repository ou de publier des packages représente une surface d'attaque importante. Moat vérifie notamment que les permissions sont correctement restreintes, comme par exemple :

1permissions:
2  contents: read

Sans bloc permissions: déclaré, chaque étape du workflow, y compris les actions tierces, hérite d'un accès en écriture complet. Limiter les permissions au strict nécessaire réduit considérablement les risques.

Le secret scanning

GitHub propose un système de détection automatique des secrets exposés et Moat vérifie si cette fonctionnalité est activée ainsi que la protection au push qui bloque les secrets directement au niveau de git push avant même qu'ils n'atteignent l'historique du repository. Sans cela une clé AWS ou un token accidentellement commis pourrait rester visible publiquement pendant des semaines.

Le support du 2FA

L'authentification à deux facteurs reste l'une des protections les plus efficaces contre le piratage de comptes. Moat vérifie deux choses distinctes : si votre organisation impose le 2FA à ses membres, et si tous les membres existants l'ont bien activé.

Les alertes Dependabot

Moat vérifie si Dependabot est actif pour les alertes de sécurité mais aussi pour les mises à jour automatiques. La nuance est importante : les alertes vous informent qu'une dépendance vulnérable est utilisée mais c'est la mise à jour automatique qui ouvre réellement la pull request pour corriger le problème. Sans elle, une alerte peut rester ignorée dans le tableau de bord indéfiniment.

La securite des webhooks

Moat s'assure que vos webhooks utilisent HTTPS et disposent d'un secret partagé. Un webhook en HTTP expose les payloads et les éventuels secrets qu'ils contiennent à quiconque se trouve sur le chemin réseau. Sans secret partagé, rien ne prouve que la requête provient réellement de GitHub.

Le fichier SECURITY.md

Moat vérifie également la présence d'un fichier SECURITY.md, qui permet d'indiquer comment signaler une vulnérabilité, qui contacter et quelle politique de disclosure appliquer. Sans canal privé de signalement, un chercheur en sécurité bien intentionné risque d'ouvrir une issue publique décrivant la faille avant qu'elle ne soit corrigée.

Un exemple concret

Prenons un workflow volontairement simplifie :

 1name: CI
 2 
 3on: [push]
 4 
 5jobs:
 6  tests:
 7    runs-on: ubuntu-latest
 8 
 9    steps:
10      - uses: actions/checkout@v4
11      - run: composer install
12      - run: php artisan test

À première vue, ce workflow semble correct. Pourtant, Moat pourrait relever plusieurs problèmes : absence de SHA pinning sur l'action, permissions implicites trop larges, aucune restriction particulière.

Une version plus robuste ressemblerait davantage a ceci :

 1name: CI
 2 
 3on: [push]
 4 
 5permissions:
 6  contents: read
 7 
 8jobs:
 9  tests:
10    runs-on: ubuntu-latest
11 
12    steps:
13      - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608
14      - run: composer install
15      - run: php artisan test

Ce genre de détail fait rarement partie des priorités lorsqu'on démarre un projet, mais devient crucial dès qu'une application prend de l'ampleur.

Configuration par repository

Moat supporte un fichier moat.toml à placer à la racine de chaque repository audité. Il permet de désactiver des vérifications qui ne s'appliquent pas à un projet donné. Les checks désactivés apparaissent comme SKIPPED dans la sortie et ne comptent pas dans le total des échecs.

1[checks]
2repositories_commits_are_signed = "off"
3repositories_workflow_actions_are_pinned = "off"

Il est également possible de déclarer des branches de release supplémentaires à traiter comme protégées :

1release_branches = ["0.x", "1.x"]

Ce que Moat n'est pas

Il est important de comprendre ce que fait réellement l'outil. Moat est un outil de revue en lecture seule : il ne modifie aucun paramètre, ne durcit pas vos repositories, ne prévient pas les intrusions et ne remédie pas à une compromission.

Moat n'est pas un scanner de vulnérabilités, un antivirus, un analyseur de dépendances, un outil de pentest. Il agit davantage comme une checklist automatisée de hardening GitHub, dont le rôle est de détecter des configurations dangereuses ou incomplètes.

Un rapport sans erreur ne certifie pas qu'un compte est sécurisé, et cette nuance est importante.

Integrer Moat dans son workflow

Moat devient particulièrement intéressant lorsqu'il est exécuté régulièrement : lors des audits internes, avant une release importante, après l'ajout de nouveaux workflows CI, dans un pipeline de sécurité ou sur des repositories open source.

L'objectif n'est pas forcément d'obtenir un score parfait, mais plutôt d'éviter les erreurs les plus risquées. Même sur de petits projets, certaines vérifications peuvent rapidement révéler des oublis importants.

Une approche interessante pour l'écosystème Laravel

Laravel a toujours eu une approche très pragmatique des outils développeurs, et Moat s'inscrit parfaitement dans cette philosophie : installation rapide, sortie terminale claire, vérifications concrètes et faible complexité.

L'outil ne cherche pas à remplacer une équipe sécurité. Il cherche surtout à rendre les bonnes pratiques plus accessibles aux développeurs. Et dans un contexte où les attaques supply chain deviennent de plus en plus fréquentes, ce type d'outil risque rapidement de devenir indispensable.

Conclusion

Aujourd'hui, protéger son application ne consiste plus uniquement à écrire du bon code : les workflows CI/CD, les permissions GitHub, les secrets, les dépendances et les automatisations représentent désormais une surface d'attaque entière.

Moat permet justement d'identifier rapidement les configurations dangereuses et les oublis fréquents. L'outil reste volontairement simple, mais c'est probablement ce qui fait sa force : quelques commandes suffisent pour obtenir une vue claire de la posture sécurité d'un repository. Pour beaucoup d'équipes, ce sera déjà un énorme pas en avant.

Source : https://github.com/laravel/moat

Écrit par

Ludovic Guénet

software engineer • mentor • bassist