Audit de Sécurité GitHub Actions

Trouvez les vulnérabilités exploitables dans les workflows GitHub Actions. Chaque découverte DOIT inclure un scénario d'exploitation concret — si vous ne pouvez pas construire l'attaque, ne la signalez pas.

Cette compétence encode les modèles d'attaque des exploits GitHub Actions réels — pas de la théorie générique CI/CD.

Périmètre

Auditez les workflows fournis (fichier, diff ou repo). Explorez le codebase selon les besoins pour tracer les chemins d'attaque complets avant de signaler.

Fichiers à Auditer

.github/workflows/*.yml — toutes les définitions de workflow
action.yml / action.yaml — actions composites du repo
.github/actions/*/action.yml — actions réutilisables locales
Fichiers de configuration chargés par les workflows : CLAUDE.md, AGENTS.md, Makefile, scripts shell sous .github/

Hors Périmètre

Workflows dans d'autres repositories (notez seulement la dépendance)
Permissions d'installation GitHub App (notez si pertinent)

Modèle de Menace

Ne signalez que les vulnérabilités exploitables par un attaquant externe — quelqu'un sans accès en écriture au repository. L'attaquant peut ouvrir des PR depuis des forks, créer des issues et poster des commentaires. Il ne peut pas pousser vers des branches, déclencher workflow_dispatch ou lancer des workflows manuels.

Ne signalez pas les vulnérabilités qui nécessitent un accès en écriture pour être exploitées :

Injection d'entrée workflow_dispatch — nécessite l'accès en écriture pour déclencher
Injection d'expression dans des workflows push-uniquement sur branches protégées
Injection d'entrée workflow_call où tous les appelants sont internes
Secrets dans des workflows workflow_dispatch/schedule-uniquement

Confiance

Signalez uniquement les découvertes HAUTE et MOYENNE confiance. Ne signalez pas les problèmes théoriques.

Confiance	Critères	Action
HAUTE	Chemin d'attaque complet tracé, exploitabilité confirmée	Signalez avec scénario d'exploitation et correctif
MOYENNE	Chemin d'attaque partiellement confirmé, lien incertain	Signalez comme nécessitant vérification
BASSE	Théorique ou atténué ailleurs	Ne signalez pas

Pour chaque découverte HAUTE, fournissez les cinq éléments :

Point d'entrée — Comment l'attaquant entre-t-il ? (PR fork, commentaire issue, nom de branche, etc.)
Payload — Qu'envoie l'attaquant ? (code/YAML/entrée réelle)
Mécanisme d'exécution — Comment le payload s'exécute-t-il ? (expansion d'expression, checkout + script, etc.)
Impact — Qu'obtient l'attaquant ? (vol de token, exécution de code, accès en écriture repo)
Croquis PoC — Étapes concrètes qu'un attaquant suivrait

Si vous ne pouvez pas construire les cinq, signalez comme MOYENNE (nécessite vérification).

Étape 1 : Classifier les Déclencheurs et Charger les Références

Pour chaque workflow, identifiez les déclencheurs et chargez la référence appropriée :

Déclencheur / Motif	Charger Référence
`pull_request_target`	`references/pwn-request.md`
`issue_comment` avec analyse de commande	`references/comment-triggered-commands.md`
`${{ }}` dans des blocs `run:`	`references/expression-injection.md`
PATs / clés de déploiement / credentials élevées	`references/credential-escalation.md`
Checkout code PR + chargement de fichier config	`references/ai-prompt-injection-via-ci.md`
Actions tierces (surtout non épinglées)	`references/supply-chain.md`
Bloc `permissions:` ou utilisation de secrets	`references/permissions-and-secrets.md`
Runners auto-hébergés, cache/artifact	`references/runner-infrastructure.md`
Toute découverte confirmée	`references/real-world-attacks.md`

Chargez les références sélectivement — uniquement ce qui est pertinent pour les déclencheurs trouvés.

Étape 2 : Vérifier les Classes de Vulnérabilité

Vérification 1 : Pwn Request

Le workflow utilise-t-il pull_request_target ET checkout du code fork ?

Cherchez actions/checkout avec ref: pointant vers la tête PR
Cherchez les actions locales (./.github/actions/) qui viendraient du fork
Vérifiez si une étape run: exécute du code depuis la PR checkoutée

Vérification 2 : Injection d'Expression

Des expressions ${{ }} sont-elles utilisées dans des blocs run: dans des workflows déclenchables de l'extérieur ?

Mappez chaque expression ${{ }} dans chaque étape run:
Confirmez que la valeur est contrôlée par l'attaquant (titre PR, nom de branche, corps commentaire — pas IDs numériques, SHAs ou noms de repository)
Confirmez que l'expression est dans un bloc run:, pas if:, with:, ou env: au niveau du job

Vérification 3 : Exécution de Commande Non Autorisée

Un workflow déclenché par issue_comment exécute-t-il des commandes sans autorisation ?

Y a-t-il une vérification author_association ?
N'importe quel utilisateur GitHub peut-il déclencher la commande ?
Le gestionnaire de commande utilise-t-il aussi des expressions injectables ?

Vérification 4 : Escalade de Credentials

Des credentials élevées (PATs, clés de déploiement) sont-elles accessibles à du code non fiable ?

Quel est le rayon d'explosion de chaque secret ?
Un workflow compromis pourrait-il voler des tokens longue durée ?

Vérification 5 : Empoisonnement de Fichier de Configuration

Le workflow charge-t-il de la configuration depuis des fichiers fournis par la PR ?

Instructions d'agent IA : CLAUDE.md, AGENTS.md, .cursorrules
Configuration de build : Makefile, scripts shell

Vérification 6 : Chaîne d'Approvisionnement

Les actions tierces sont-elles sécurisées épinglées ?

Vérification 7 : Permissions et Secrets

Les permissions du workflow sont-elles minimales ? Les secrets sont-ils correctement limités en portée ?

Vérification 8 : Infrastructure de Runner

Les runners auto-hébergés, caches ou artifacts sont-ils utilisés sécurisément ?

Motifs Sûrs (Ne Signalez Pas)

Avant de signaler, vérifiez si le motif est réellement sûr :

Motif	Pourquoi Sûr
`pull_request_target` SANS checkout du code fork	N'exécute jamais le code attaquant
`${{ github.event.pull_request.number }}` dans `run:`	Numérique uniquement — non injectable
`${{ github.repository }}` / `github.repository_owner`	Le propriétaire du repo contrôle ceci
`${{ secrets.* }}`	Pas un vecteur d'injection d'expression
`${{ }}` dans les conditions `if:`	Évalué par le runtime Actions, pas shell
`${{ }}` dans les entrées `with:`	Passé comme paramètres string, non évalué shell
Actions épinglées au SHA complet	Référence immuable
Déclencheur `pull_request` (pas `_target`)	S'exécute dans le contexte fork avec token en lecture seule
N'importe quelle expression dans `workflow_dispatch`/`schedule`/`push` vers branches protégées	Nécessite accès en écriture — hors modèle de menace

Distinction clé : ${{ }} est dangereux dans les blocs run: (expansion shell) mais sûr dans if:, with: et env: au niveau job/étape (évaluation runtime Actions).

Étape 3 : Valider Avant de Signaler

Avant d'inclure toute découverte, lisez le YAML du workflow réel et tracez le chemin d'attaque complet :

Lisez le workflow complet — ne vous fiez pas à la sortie grep seule
Tracez le déclencheur — confirmez l'événement et vérifiez les conditions if: qui contrôlent l'exécution
Tracez l'expression/checkout — confirmez qu'elle est dans un bloc run: ou référence réellement du code fork
Confirmez le contrôle attaquant — vérifiez que la valeur correspond à quelque chose que l'attaquant externe fixe
Vérifiez les mitigations existantes — enveloppe de var env, vérifications author_association, permissions restreintes, épinglage SHA

Si un lien est cassé, marquez MOYENNE (nécessite vérification) ou abandonnez la découverte.

S'il n'y a aucune découverte, signalez zéro découverte. N'inventez pas de problèmes.

Étape 4 : Signaler les Découvertes

## Audit de Sécurité GitHub Actions

### Découvertes

#### [GHA-001] [Titre] (Sévérité : Critique/Haute/Moyenne)
- **Workflow**: `.github/workflows/release.yml:15`
- **Déclencheur**: `pull_request_target`
- **Confiance**: HAUTE — confirmée par traçage du chemin d'attaque
- **Scénario d'Exploitation**:
  1. [Attaque étape par étape]
- **Impact**: [Ce que l'attaquant gagne]
- **Correctif**: [Code qui corrige le problème]

### Nécessite Vérification
[Éléments de confiance MOYENNE avec explication de ce à vérifier]

### Auditées et Validées
[Workflows auditées et confirmées sûres]

S'il n'y a pas de découvertes : "Aucune vulnérabilité exploitable identifiée. Tous les workflows auditées et validées."

gha-security-review