Les GitHub Actions sont devenues l'épine dorsale CI/CD de la majorité des éditeurs SaaS B2B. Et chacune d'elles est du code tiers exécuté dans votre runner, souvent avec accès à vos secrets, à votre registry, à votre infrastructure cloud. La compromise d'une action peut donner à l'attaquant un accès complet à votre supply chain — comme l'a démontré l'incident tj-actions/changed-files de 2023. Voici comment auditer et durcir.
Pourquoi c'est sous-estimé
Une pipeline CI typique 2026 :
```yaml
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- uses: pnpm/action-setup@v3
- uses: actions/cache@v4
- uses: docker/login-action@v3
- uses: docker/build-push-action@v5
- uses: aws-actions/configure-aws-credentials@v4
- uses: hashicorp/setup-terraform@v3
- uses: tj-actions/changed-files@v40
- uses: codecov/codecov-action@v4
```
Dix actions. Chacune contient potentiellement des dizaines de milliers de lignes de JavaScript/Python. Personne dans votre équipe ne les a lues. Et chacune a accès aux variables d'environnement du job.
Si l'une est compromise — par un mainteneur malveillant, un compte mainteneur volé, un fork malveillant qui devient officiel —, l'attaquant peut :
- Exfiltrer vos
GITHUB_TOKEN, AWS credentials, registry tokens. - Modifier les artefacts publiés sans laisser de trace.
- Empoisonner les builds suivants.
C'est arrivé : tj-actions/changed-files compromise en mars 2023, exposant des secrets de plus de 23 000 organisations.
L'audit en 3 phases
Phase 1 — Inventaire
Lister toutes les actions utilisées dans votre organisation.
```bash # Au niveau d'un repo grep -rh "uses:" .github/workflows/ | grep -v '^\s*#' | sort -u
# Au niveau d'une org GitHub avec gh CLI gh repo list myorg --limit 1000 --json nameWithOwner | \ jq -r '.[].nameWithOwner' | \ while read repo; do gh api "repos/$repo/contents/.github/workflows" 2>/dev/null | \ jq -r '.[].download_url' | \ while read url; do curl -s "$url" | grep "uses:" | head -20 done done | sort -u ```
Output type : 30-150 actions différentes pour une organisation de taille moyenne.
Phase 2 — Classification par criticité
Pour chaque action, déterminer :
- Officielle : maintenue par GitHub (
actions/*) ou un éditeur reconnu (Microsoft, Google, AWS, HashiCorp, Docker). - Tierce reconnue : éditeur de référence (Snyk, Codecov, Datadog, Sentry).
- Communauté : maintenue par un individu ou petite équipe.
- Inconnue : pas de mainteneur clairement identifié.
Risque croissant du haut vers le bas. Les actions communauté et inconnues sont la priorité.
Phase 3 — Durcissement
#### A. Pinning par SHA, pas par tag
Au lieu de :
```yaml
- uses: actions/checkout@v4
```
Utiliser le SHA du commit exact :
```yaml
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
```
Pourquoi : un tag (v4) est mutable. Un mainteneur compromis peut rétroactivement le déplacer vers un commit malveillant. Un SHA est immuable.
Dependabot peut vous aider à maintenir les SHA à jour automatiquement.
#### B. Allowlist au niveau organisation
Settings → Actions → General → "Allow specified actions and reusable workflows".
Activez :
- "Allow actions created by GitHub" → uniquement les
actions/*officielles. - Allowlist explicite des autres actions autorisées.
Effet : un dev qui ajoute une action non-allowlistée verra son CI bloquée. Force le passage par une review.
#### C. Limiter les secrets accessibles
Au niveau d'un job, ne fournir que les secrets nécessaires :
``yaml jobs: publish: permissions: contents: read packages: write env: NPM_TOKEN: ${{ secrets.NPM_TOKEN }} steps: - uses: actions/checkout@SHA - uses: third-party-action@SHA # n'a accès qu'à NPM_TOKEN, pas aux autres ``
Et utiliser permissions: strict au niveau workflow (par défaut, GitHub donne maintenant contents: read mais à confirmer dans vos repos legacy).
#### D. OIDC plutôt que long-lived secrets
Pour les credentials AWS, GCP, Azure, Vault — utilisez OIDC (id-token: write) au lieu de stocker des credentials persistants. La compromise d'une action n'expose pas un secret long-vie utilisable hors-CI.
```yaml permissions: id-token: write contents: read
steps: - uses: aws-actions/configure-aws-credentials@SHA with: role-to-assume: arn:aws:iam::123456789:role/GitHubActions aws-region: eu-west-1 ```
#### E. Self-hosted runners pour les workflows critiques
Pour les déploiements production, considérer des self-hosted runners éphémères (nouvelle VM par job) plutôt que les runners GitHub partagés. Avantage : isolation réseau possible (VPC private).
#### F. Auditer le code des actions tierces
Pour les actions critiques (publication d'artefacts, déploiement prod), faire une revue manuelle du code. Les actions GitHub sont des dépôts publics, leur code est lisible.
Indices d'alerte :
- Téléchargement de binaires depuis URL non-officielle.
- Eval de strings provenant de variables d'environnement.
- Network calls vers des endpoints non documentés.
- Mainteneur récent qui a fait beaucoup de changements en peu de temps.
Phase 4 — Détection runtime
Outils 2026 pour monitorer les actions en cours :
- StepSecurity Harden Runner : détecte en runtime les comportements anormaux (network calls inattendus, lecture de secrets, etc.).
- Datadog GitHub Actions monitoring : visibilité.
- Custom audit logs : si vous avez GitHub Enterprise, exploitez l'audit log API.
Le cas particulier des reusable workflows
Les reusable workflows (uses: ./.github/workflows/... ou cross-org) sont aussi du code tiers ou interne. Mêmes principes : pinning par SHA, permissions strictes, allowlist.
Politique d'organisation
Au-delà de l'audit ponctuel, mettre en place :
- Review obligatoire sur tout changement d'action utilisée (CODEOWNERS sur
.github/workflows/). - CI dédiée à la CI : un workflow qui scanne les autres workflows pour détecter les régressions de sécurité (actions non-pinnées, permissions manquantes).
- Formation des devs : ils choisissent les actions, ils doivent comprendre le risque.
Articulation avec SBOM et CRA
Les actions utilisées dans votre CI font partie de votre supply chain. Pour la conformité CRA en 2027, votre SBOM devra inclure votre stack CI.
C'est de moins en moins théorique : les auditeurs commencent à demander la liste des actions utilisées et leur posture de durcissement.
