10 min de lecture - Cache GitHub Actions : tracez d’abord la frontière de confiance

Le 10 septembre 2026, GitHub a ajouté une petite propriété YAML aux conséquences importantes pour la sécurité. Le nouveau réglage cache-mode de GitHub Actions permet à un workflow ou à une tâche de lire le cache, d’y écrire, de faire les deux ou de n’effectuer aucune de ces opérations. GitHub annonce sa disponibilité générale pour toutes les offres.

Ce contrôle est utile parce qu’un cache CI traverse le temps. Une tâche de test peut enregistrer des fichiers aujourd’hui, puis une tâche de publication les restaurer demain. Si la première traite le code d’une pull request et que la seconde peut publier un paquet ou déployer une image, le cache risque de relier deux workflows qui semblaient séparés lors de la revue du dépôt.

Votre équipe doit encore déterminer quelles exécutions peuvent influencer les suivantes, quels fichiers peuvent être exécutés et où un cache manquant reste acceptable. Cartographiez ces relations avant d’ajouter cache-mode. La méthode proposée ne rapporte aucun test GitHub ni d’un environnement client d’Exceev.

Traitez l’accès au cache comme une permission

La documentation de la syntaxe cache-mode définit quatre valeurs. read autorise la restauration et bloque l’enregistrement. write autorise les deux. write-only permet l’enregistrement sans restauration, tandis que none bloque les deux opérations. Une valeur définie au niveau du workflow s’applique à toutes les tâches, sauf si l’une d’elles la remplace.

Le service applique le réglage au moyen de jetons de cache dotés de droits limités. Lorsqu’un mode interdit une opération, l’étape de cache inscrit un message dans le journal et le workflow continue. Une restauration bloquée devient un échec de cache ; un enregistrement bloqué est ignoré. Cette particularité compte pour l’exploitation, car une tâche verte ne prouve pas qu’elle a alimenté le cache.

Ne commencez pas par convertir chaque étape de cache en write. GitHub avertit qu’une attribution explicite de write ou write-only à un déclencheur peu fiable peut contourner la valeur sécurisée en lecture seule et réintroduire un risque d’empoisonnement du cache.

Cartographiez les producteurs, les consommateurs et leurs pouvoirs

Ouvrez chaque workflow dans .github/workflows. Pour toute tâche qui emploie actions/cache ou le cache de dépendances intégré à une action de configuration, consignez cinq éléments :

• l’événement qui déclenche le workflow ;
• la possibilité pour un contributeur externe d’influencer le code extrait, les expressions, les scripts ou l’installation des paquets ;
• les répertoires et types de fichiers restaurés ou enregistrés ;
• la clé du cache et les éventuels préfixes de restauration ;
• les actions permises après la restauration, notamment l’accès aux secrets, à OIDC, aux déploiements, à la signature ou à la publication de paquets.

Reliez ensuite chaque producteur à tous ses consommateurs possibles. Une clé formée du système d’exploitation et de l’empreinte du fichier de verrouillage peut être commune à une tâche de pull request et à une tâche de la branche par défaut. Des noms de fichiers de workflow distincts ne créent pas, à eux seuls, une isolation.

Examinez surtout les exécutables générés, les magasins de paquets, les sorties du compilateur et les outils téléchargés. Notez le chemin réel, car une publication qui exécute un binaire restauré ne présente pas le même risque qu’une prévisualisation de sources inertes.

La carte doit répondre à une question directe : un code contrôlé par un acteur moins fiable peut-il placer des octets là où une tâche dotée de davantage de pouvoirs les exécutera ou les publiera ? Si la réponse reste inconnue, retirez l’écriture du parcours peu fiable jusqu’à ce que l’équipe puisse retracer la relation.

Partez des valeurs par défaut liées aux déclencheurs

En juin 2026, GitHub a introduit des jetons de cache en lecture seule pour certains déclencheurs non fiables. Le changement couvre les cas où une personne sans droit d’écriture sur le dépôt peut lancer un workflow dans l’espace de cache partagé de la branche par défaut. GitHub cite notamment pull_request_target, issue_comment et certaines chaînes workflow_run issues d’un fork.

Le contrôle de septembre rend cette frontière modifiable. Si une exécution peu fiable a cessé d’enregistrer son cache après le changement de juin, créez un producteur de confiance au lieu de rétablir l’écriture pour gagner du temps.

Un workflow lancé par un push sur la branche par défaut peut, par exemple, construire et enregistrer un cache de dépendances. Les validations de pull request peuvent le restaurer avec cache-mode: read, puis effectuer une installation normale à froid si aucune entrée ne correspond. Elles bénéficient ainsi d’une entrée de confiance lorsqu’elle existe, sans pouvoir la remplacer.

cache-mode: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('**/package-lock.json') }}

Cet extrait n’illustre que la syntaxe. L’épinglage des actions, le gestionnaire de paquets et les permissions demandent leur propre revue.

Changez de mode au niveau des tâches lorsque les pouvoirs diffèrent

Un même workflow peut réunir une tâche de test et une tâche de publication. Si vous attribuez write à l’ensemble parce qu’une seule tâche doit alimenter le cache, toutes reçoivent cette capacité en l’absence de réglages plus précis.

Fixez une valeur restrictive pour le workflow, puis justifiez les exceptions. Une compilation après un push de confiance peut recevoir write. Une publication peut employer read, ou none si l’équipe exige une compilation propre. Le choix dépend du processus de publication.

Les workflows réutilisables demandent la même revue. GitHub indique qu’un appelant peut limiter l’accès au cache du workflow appelé et que ce dernier ne peut pas recevoir davantage de droits que l’appelant. Consignez le mode effectif sur la tâche d’appel, surtout si un workflow partagé traite des pull requests, des compilations planifiées et des publications.

write-only empêche un producteur de restaurer une ancienne entrée et peut convenir à une tâche d’alimentation dédiée. Il lui permet toujours d’influencer les consommateurs futurs : réservez ce pouvoir à un producteur de confiance.

Une bonne clé reste nécessaire, mais ne suffit pas

Les clés doivent couvrir les entrées qui déterminent le contenu conservé. Un cache de compilation peut dépendre du fichier de verrouillage, du compilateur et de ses options. Même précise, une clé n’indique pas qui peut enregistrer l’entrée correspondante.

Le modèle de menaces indépendant de SLSA décrit l’empoisonnement comme l’introduction d’un artefact malveillant dans un cache, ensuite choisi par une compilation légitime. Parmi les mesures citées figurent l’isolation des caches entre les compilations, des clés dérivées de toutes les entrées transitives et l’écriture réservée à un plan de contrôle de confiance, ou une provenance adaptée pour chaque entrée.

cache-mode restreint le jeton d’une tâche, mais ne prouve ni le contenu du répertoire, ni l’exhaustivité de la clé, ni l’absence d’un autre état partagé sur un runner auto-hébergé. Examinez ces mécanismes séparément.

Testez la politique sans pouvoir de production

Créez une branche jetable ou un dépôt de test avec les mêmes déclencheurs et chemins de cache, sans identifiant de déploiement. Employez un fichier marqueur inoffensif pour distinguer une entrée créée par le producteur de confiance d’un enregistrement tenté par la tâche peu fiable.

Exécutez d’abord le cas à froid. Vérifiez que la tâche réussit lorsque la restauration échoue et que l’installation des dépendances contrôle encore ses entrées. Laissez ensuite le producteur de confiance enregistrer le marqueur, puis confirmez qu’un consommateur en lecture seule peut le restaurer. Enfin, tentez un enregistrement depuis la tâche en lecture seule et vérifiez que le journal indique son abandon alors que la tâche reste verte.

Consignez la révision, l’événement, l’acteur, le mode effectif, la clé et le journal. Testez aussi le workflow réutilisable utilisé en production, sans ajouter de vrais secrets.

Comparez aussi les durées à chaud et à froid. Vous saurez ainsi si un producteur de confiance vaut son coût et quelles tâches peuvent tolérer none.

Examinez les publications comme des consommateurs distincts

Une publication mérite sa propre ligne, même sans étape cache. Une action de configuration peut masquer le cache derrière une option et un workflow réutilisable peut le restaurer ailleurs.

Le guide CodeQL de GitHub pour les workflows Actions répertorie des requêtes sur l’empoisonnement du cache à côté de contrôles portant sur l’exécution de code non fiable, l’exposition excessive de secrets et les permissions manquantes. Lancez l’analyse adaptée, puis lisez aussi la carte des workflows. Un résultat statique aide à repérer un chemin ; l’absence de résultat ne documente pas la frontière de confiance prévue.

Si l’équipe soupçonne qu’un parcours non fiable a écrit dans un cache, empêchez les consommateurs de confiance de le restaurer pendant que le responsable de l’incident en établit le périmètre. Reconstruisez l’état nécessaire avec un producteur approuvé, puis examinez les secrets ou identités de publication selon leur exposition réelle. Ce principe défensif ne signifie pas qu’un changement de cache-mode suffit à résoudre un incident.

Consignez la frontière acceptée

Nommez la tâche, le déclencheur, le chemin, le producteur, les consommateurs, le mode, le comportement à froid et le responsable. Reliez la révision et le test, puis donnez à chaque exception une condition de réexamen.

Pour une équipe répartie entre la France et le Maroc, utilisez un registre. Le déclencheur, la source du code et les pouvoirs de la tâche définissent la frontière technique ; les questions contractuelles demandent une validation. Intégrez les écarts plus larges à la revue des services.

Réexaminez la carte si un workflow reçoit OIDC, un jeton de publication, un déclencheur ou un autre chemin de cache. Une optimisation peut changer la tâche qui fournit l’état exécutable d’une publication.

Sources et limites

Nous avons ouvert et vérifié chaque source ci-dessous le 11 septembre 2026.

• L’annonce GitHub du 10 septembre établit la disponibilité générale, les quatre modes, leur application et les avertissements.
• La référence de syntaxe des workflows GitHub définit la configuration par workflow et par tâche, le traitement des opérations refusées et les contraintes des workflows réutilisables.
• La mise à jour GitHub de juin sur la lecture seule explique la valeur par défaut liée aux déclencheurs et le risque entre workflows qu’elle cherchait à réduire.
• Le modèle de menaces de SLSA apporte une recommandation indépendante sur l’isolation, les clés de cache et les producteurs de confiance.
• Le guide CodeQL de GitHub documente ses familles de requêtes sur l’empoisonnement du cache et les contrôles associés.

GitHub constitue la source primaire pour son service et sa syntaxe. SLSA ne certifie ni son implémentation, ni cette méthode. Nous n’avons pas testé le contrôle en production, mesuré son effet sur les durées ou évalué les obligations d’un client. Vérifiez la documentation et le mode effectif avant de modifier une publication.