CI qui fuit : prévenir l’exfiltration via artefacts

On parle souvent de secrets qui « fuient » via des logs, des variables d’environnement mal gérées, ou un bucket S3 ouvert. Mais il y a un autre classique, un peu sournois, et franchement fréquent quand on fait du CI/CD à la chaîne : les artefacts.

Et oui. Ton pipeline CI produit des zip, des rapports de tests, des images Docker, des caches, des bundles front, des fichiers de debug. Tout ça est très pratique. Tout ça peut aussi transporter, parfois sans bruit, des secrets, des tokens, des URLs internes, des clés privées, des dumps de config. Et si ces artefacts sont téléchargeables par la mauvaise personne, ou simplement conservés trop longtemps, tu te retrouves avec une exfiltration « propre », presque indétectable.

Dans cet article, je vais poser le problème clairement, puis donner des mesures concrètes. Pas du bla bla. Et si tu aimes ce genre de contenu pratique, tu peux fouiller les autres posts sur Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, il y a pas mal de veille et de checklists qui vont dans ce sens.

Pourquoi les artefacts sont une voie d’exfiltration sous estimée

Un artefact CI, c’est « juste » une sortie de job. Sauf que.

Quelques exemples que je vois passer en audit, ou même en debug rapide un vendredi soir :

• un .env qui traîne dans un bundle parce que le build l’a copié « pour tester »
• un application.yml packagé dans un jar, avec un mot de passe de base de données non remplacé
• un core dump ou un heap dump Java qui contient des tokens en mémoire
• un npm pack qui inclut .npmrc et son token
• un rapport de tests qui affiche des headers HTTP complets, dont Authorization: Bearer ...
• des fichiers Terraform state (terraform.tfstate) envoyés en artefact pour « faciliter la review »
• un cache CI qui contient ~/.aws/credentials parce que quelqu’un a fait un aws configure dans un job

Et derrière, trois facteurs aggravants :

1. les artefacts sont souvent accessibles via l’interface CI à plein de monde
2. ils sont parfois publiés vers un stockage externe
3. la rétention est longue, par défaut, et personne ne nettoie

Cartographier : quels artefacts sortent vraiment de votre CI

Avant de « sécuriser », il faut voir. Vraiment voir.

Checklist rapide :

• liste tous les types d’artefacts produits : builds, rapports, exports, caches, containers
• où vont ils : stockage interne du CI, registry, bucket, serveur de fichiers
• qui peut les lire : dev, QA, prestas, externes, invités, comptes de service
• combien de temps ils vivent : rétention, tags immuables, backups automatiques
• sont ils chiffrés au repos, et en transit : TLS, KMS, chiffrement côté serveur

Astuce simple mais efficace : prends un artefact récent, dézippe le localement, et lance une recherche de patterns de secrets.

Par exemple :

bash

rg -n --hidden -S "AKIA[0-9A-Z]{16}|BEGIN PRIVATE KEY|Bearer |x-api-key|password\s*=" .

Ce n’est pas parfait. Mais tu vas souvent tomber sur un truc dès le premier run. Et ça calme.

Prévenir : règles de base qui éliminent 80 % du risque

1) Ne pas packager ce qui ne doit pas l’être

Ça paraît évident. Pourtant c’est le point numéro un.

• ajoute des .dockerignore et .gitignore corrects, et surtout un .npmignore si tu packages
• sur les builds front, vérifie la config de bundling et les « define » injectés
• bannis .env, .pem, id_rsa, credentials, *.tfstate des répertoires de sortie

Tu peux même mettre une étape CI qui échoue si certains fichiers sont présents dans l’artefact.

Exemple :

bash for f in ".env" "id_rsa" "terraform.tfstate"; do if find dist -name "$f" -print -quit | grep -q .; then echo "Fichier interdit détecté : $f" exit 1 fi done

2) Réduire la surface : artefacts minimaux, logs minimaux

Deux réflexes :

• produis des artefacts « release » séparés des artefacts de debug
• évite de publier des rapports trop verbeux si ils contiennent des données sensibles

Et attention aux erreurs. Une stacktrace peut embarquer des secrets si les exceptions incluent des URLs signées, ou des headers.

3) Durée de vie courte par défaut

Rétention courte, puis exceptions contrôlées. Pas l’inverse.

• artefacts de jobs standards : 1 à 7 jours
• artefacts de release : plus long, mais signés, versionnés, et stockés dans un endroit prévu pour
• caches : purge régulière, et segmentation par projet

Ça réduit l’impact d’un compte compromis, et ça limite aussi l’exposition « historique ».

Contrôler l’accès : permissions et séparation des rôles

Le problème n’est pas juste « est ce que l’artefact contient un secret ». C’est aussi : « qui peut le télécharger ».

Mesures concrètes :

• principe du moindre privilège sur la CI : tout le monde ne doit pas voir tous les pipelines
• sépare les pipelines internes et publics, surtout si tu as de l’open source
• bloque l’accès aux artefacts pour les forks externes, sauf cas strict
• utilise des comptes de service distincts, pas des tokens personnels
• journalise les téléchargements d’artefacts quand c’est possible

Et si ton outil le permet, impose :

• artefacts privés par défaut
• accès conditionné à un groupe, pas à « tout utilisateur authentifié »

Détecter : scanner les artefacts et bloquer en amont

Prévenir c’est bien. Détecter c’est mieux.

Tu peux ajouter, selon ta stack :

• un secret scanner sur le repo : Gitleaks, TruffleHog, detect-secrets
• un scan sur le workspace avant packaging
• un scan après génération d’artefact, juste avant publication
• un scan des images Docker : Trivy, Grype, Syft, et vérif des layers

Idée simple : si un secret sort dans un artefact, le pipeline doit échouer. Pas juste « alerter ».

Tu veux du bruit au début, puis tu règles les faux positifs. Mais au moins, ça stoppe.

Cas spécifique : les caches CI, le piège discret

Les caches sont des artefacts, mais déguisés. Et parfois partagés entre branches, jobs, ou même projets si c’est mal configuré.

Règles :

• pas de cache sur $HOME complet
• pas de cache sur ~/.ssh, ~/.aws, ~/.npmrc, ~/.config
• utilise des clés de cache spécifiques par branche ou par lockfile
• purge automatique, et pas de cache global « magique »

En gros : cache le strict nécessaire, pas ta vie entière.

Conclusion : une fuite via artefacts, c’est rarement un hack spectaculaire

C’est plutôt une addition de petites décisions « pratiques ». On veut aller vite. On ajoute un zip. On garde 90 jours « au cas où ». On donne accès à l’équipe entière. Et un jour, ça sort.

Si tu dois retenir une mini checklist :

• artefacts minimaux
• rétention courte
• accès strict
• scan systématique
• caches traités comme sensibles

Je continue à publier des guides concrets dans ce style sur https://monblog-sa-abasse.blogspot.com, donc si tu veux, passe y jeter un œil et garde le site sous la main pour ta veille. Tu verras, ça évite pas mal de mauvaises surprises.

Questions fréquemment posées

Pourquoi les artefacts CI/CD représentent-ils une voie d'exfiltration de secrets sous-estimée ?

Les artefacts produits par les pipelines CI/CD, tels que les fichiers zip, rapports de tests, images Docker ou caches, peuvent contenir sans bruit des secrets comme des tokens, clés privées ou URLs internes. Ces artefacts sont souvent accessibles à un grand nombre de personnes via l'interface CI, parfois publiés sur des stockages externes et conservés trop longtemps, ce qui facilite une exfiltration discrète et difficile à détecter.

Quels types d'informations sensibles peut-on retrouver dans les artefacts CI ?

On peut trouver dans les artefacts des fichiers .env contenant des variables d'environnement, des fichiers de configuration comme application.yml avec mots de passe en clair, des dumps mémoire (core dump, heap dump) contenant des tokens, des fichiers npm pack incluant .npmrc avec tokens, des rapports de tests affichant des headers HTTP complets avec autorisations, ou encore des fichiers Terraform state (terraform.tfstate) et caches contenant des credentials AWS.

Comment cartographier efficacement les artefacts produits par votre pipeline CI ?

Pour bien sécuriser les artefacts, il faut d'abord dresser un inventaire précis : lister tous les types d'artefacts générés (builds, rapports, caches...), identifier où ils sont stockés (serveur CI interne, registry Docker, bucket cloud), déterminer qui y a accès (développeurs, QA, prestataires), évaluer leur durée de rétention et vérifier s'ils sont chiffrés au repos et en transit. Une astuce pratique est de décompresser un artefact récent localement et d'y rechercher automatiquement la présence de secrets via des expressions régulières adaptées.

Quelles règles simples permettent d'éliminer 80% du risque lié aux artefacts ?

La première règle est de ne pas packager ce qui ne doit pas l'être : utiliser correctement .dockerignore, .gitignore et surtout .npmignore pour exclure les fichiers sensibles comme .env, .pem, id_rsa, credentials ou *.tfstate. Une étape CI peut automatiser cette vérification en échouant si ces fichiers interdits se trouvent dans l'artefact. Ensuite, réduire la surface en produisant uniquement des artefacts minimaux et limiter la quantité de logs générés aide aussi à diminuer le risque.

Comment automatiser la détection de secrets dans les artefacts avant leur publication ?

Il est possible d'ajouter dans le pipeline CI une étape qui décompresse les artefacts produits puis lance une recherche via un outil comme 'rg' (ripgrep) avec des expressions régulières ciblant les patterns typiques de secrets (exemples : clés AWS 'AKIA...', clés privées 'BEGIN PRIVATE KEY', tokens 'Bearer ', 'x-api-key', ou mots de passe). Si un secret est détecté, cette étape échoue et bloque la publication ou le stockage de l'artefact.

Pourquoi est-il important de gérer correctement la rétention et l'accès aux artefacts CI ?

Parce que les artefacts peuvent contenir des informations sensibles longtemps après leur création. Une rétention trop longue augmente le risque qu'une personne non autorisée accède à ces données. De plus, si les permissions d'accès ne sont pas strictement contrôlées sur l'interface CI ou sur le stockage externe où sont envoyés ces artefacts, cela facilite une exfiltration propre et difficile à tracer. Il faut donc appliquer une politique stricte sur qui peut lire quoi et pendant combien de temps.