123% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.

Sécurité CI/CD

Stopper l'exfiltration depuis GitHub Actions avec une politique de trafic sortant

Un job CI détient des secrets et exécute du code téléchargé il y a une minute : des actions, des paquets et leurs scripts d'installation. Si une partie de ce code est malveillante, le moyen le plus simple de voler les secrets est de les envoyer à un serveur. Une politique de trafic sortant décide quels serveurs un job peut atteindre et bloque les autres.

Mis à jour le

Comment les secrets quittent un job CI

Un job a accès au token du dépôt, aux secrets qui lui sont transmis et aux identifiants cloud qu'il endosse. Le code qui s'exécute dans le job peut les lire. Il peut ensuite les faire sortir de plusieurs façons :

  • Par le réseau. Une requête vers un serveur contrôlé par l'attaquant. C'est le canal que ferme une politique de trafic sortant.
  • Par les logs. Les secrets sont affichés, souvent encodés, dans le log du job. En mars 2025, la CISA a indiqué que l'action compromise tj-actions/changed-files avait exposé des secrets de cette façon.
  • Par les sorties. Des artefacts, des caches ou des commits poussés avec le token du job.

Le code n'a pas besoin d'être un paquet malveillant. Un agent IA présent dans le workflow peut être détourné par une injection de prompt cachée dans une issue ou une pull request, puis utiliser les mêmes canaux.

Ce que fait une politique de trafic sortant

La plupart des jobs ont besoin d'atteindre une courte liste de destinations : registres de paquets, registres de conteneurs, hôtes de code source et quelques services. Une politique de trafic sortant autorise cette liste et bloque tout le reste. Avec une politique de refus par défaut, une requête vers un hôte inconnu échoue et les secrets restent dans le job.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

Elle ne ferme pas toutes les portes :

  • Elle n'empêche pas l'affichage de secrets dans les logs. Gardez les logs privés et épinglez les actions à des SHA de commit.
  • Une destination que vous autorisez peut toujours servir à faire sortir des données : gardez donc une liste d'autorisation restreinte.
  • Elle ne vous dit pas quels paquets étaient malveillants. C'est le rôle du filtrage des paquets et d'une SBOM.

Trois façons de l'appliquer

  • Un agent sur le runner. StepSecurity Harden-Runner s'ajoute comme première étape d'un job. Il associe chaque connexion à l'étape qui l'a établie, construit une référence en mode audit et bloque le trafic sortant vers tout ce qui ne figure pas sur une liste d'autorisation.
  • Un runner avec politique intégrée. C'est le runner CRACI lui-même qui applique la politique. D'autres fournisseurs de runners proposent aussi des contrôles réseau, comme le filtrage du trafic sortant sur les runners Linux de Depot et les politiques de trafic sortant bloquantes ou consultatives sur Namespace.
  • Votre propre réseau. Des runners auto-hébergés derrière un pare-feu ou un proxy que vous configurez et maintenez.

Déployer sans casser les builds

  1. Observer. Enregistrez chaque connexion établie par un job sur quelques exécutions.
  2. Autoriser. Construisez la liste d'autorisation à partir de ce dont le job a réellement besoin.
  3. Bloquer. Passez au refus par défaut et surveillez les violations.
  4. Examiner. Traitez chaque nouvelle violation soit comme une source manquante, soit comme un incident.

Comment CRACI procède

Sur CRACI, la politique de trafic sortant fait partie du runner. Elle est validée avant le démarrage du job, les champs inconnus sont rejetés, et elle bloque tout en cas d'échec. Des presets intégrés couvrent les sources de paquets courantes, et des sources et connexions personnalisées ajoutent le reste. La trace du job liste chaque connexion, et chaque connexion bloquée comme une violation avec sa raison. Comme le proxy comprend les paquets, ce même enregistrement devient la SBOM du job. L'API renvoie les SBOM, les traces réseau et la provenance.

CRACI n'a pas encore de mode audit dédié ; il figure sur la roadmap. Sans politique réseau, le trafic d'un job est autorisé et enregistré dans la trace : vous voyez ainsi ce dont une politique a besoin avant de l'appliquer. CRACI exécute les jobs GitHub Actions sous Linux. Voir le comparatif des outils de sécurité CI/CD et CRACI face à StepSecurity.

Politiques de trafic sortant en CI : questions fréquentes

Qu'est-ce qu'une politique de trafic sortant en CI ?

Un ensemble de règles sur les connexions réseau sortantes qu'un job CI peut établir. Le job peut atteindre les registres de paquets et les services dont il a besoin, et toute autre destination est bloquée.

Une politique de trafic sortant aurait-elle arrêté la compromission de tj-actions ?

Pas à elle seule. Dans ce cas, la CISA a indiqué que les secrets avaient été exposés dans les logs de workflow, et non envoyés à un serveur extérieur. Une politique de trafic sortant ferme le canal réseau ; épingler les actions à des SHA de commit et garder les logs privés traitent le canal des logs.

Bloquer le trafic sortant casse-t-il les builds ?

Cela peut arriver si la politique oublie une source dont le build a besoin. Commencez par enregistrer ce à quoi le job se connecte, construisez la liste d'autorisation à partir de là, puis bloquez. Sur CRACI, des presets intégrés couvrent les sources de paquets courantes, et une connexion bloquée apparaît dans la trace du job avec sa raison.

Puis-je utiliser une politique de trafic sortant sur des runners hébergés par GitHub ?

Oui, avec un agent ajouté au job, comme StepSecurity Harden-Runner. Ou bien déplacez le job vers un runner qui applique lui-même la politique, comme CRACI.

Placez un job derrière une politique de trafic sortant

Exécutez un workflow sur CRACI et voyez chaque connexion établie, celles qu'une politique de refus par défaut bloquerait et la SBOM de ce qu'il a récupéré.

Réserver une démo