Agent de sécurité en CI : scanner secrets, deps et configs à chaque PR
Agent de sécurité en CI : scanner secrets, dépendances et configs à chaque PR, trier les alertes et laisser un humain valider l'irréversible.
On a déjà traité deux faces du sujet. Black October parle de sécuriser les agents IA eux-mêmes. Agents IA pour durcir un SaaS présente une flotte (secrets, dépendances, IAM, review). Ici, on zoome sur un seul maillon : l'agent de sécurité qui tourne dans votre CI, à chaque pull request. Il lit les scanners de secrets, de dépendances et de configs, trie ce qui touche vraiment le diff, prépare le correctif, et laisse un humain sur ce qui est irréversible.
Pourquoi la CI est devenue le vrai goulot
Selon Octoverse 2026, plus de 40 % des pull requests démarrées en septembre 2026 l'étaient avec un premier jet d'agent (17 % en mars). Les agents poussent, corrigent le rouge, repoussent. Et la boucle ne se fatigue pas.
Owen Gretzinger (Boardy) l'a décrit dans How I made our CI 20x faster : une PR qui attendait jusqu'à 40 minutes de CI est passée à 2 minutes, parce que « chaque PR est écrite avec des coding agents » et que les agents « ne se lassent pas de pousser ». Quand l'écriture accélère et que la vérif stagne, la vérif devient le goulot. Ça vaut pour les tests. Ça vaut aussi pour la sécurité : si le scan secrets/deps/configs reste une file d'alertes que personne ne lit, les agents accélèrent surtout le risque.
GitHub a poussé la détection : la push protection a fait 5,8 milliards de scans sur la période Octoverse, près de quatre fois le rythme de 2025. Plus de 30 millions de PR Dependabot ont été mergées. La détection passe à l'échelle. Le tri et le correctif, beaucoup moins.
Ce que l'agent ajoute aux scanners de la CI
Les outils existent déjà. Secret scanning + push protection, Dependabot ou Renovate, SAST, checks d'infra as code. Ce qui coince, c'est la suite de l'alerte.
Le State of Secrets Sprawl 2026 de GitGuardian compte 28,65 millions de nouveaux secrets en clair dans les commits publics GitHub en 2025 (+34 %). Les commits co-écrits avec un assistant IA fuyaient environ deux fois plus que la moyenne. 64 % des secrets valides détectés en 2022 étaient encore exploitables en janvier 2026. Détectés, pas rotés. OWASP range ça dans CICD-SEC-6 : Insufficient Credential Hygiene : secrets poussés dans le SCM, credentials trop larges dans le pipeline, logs qui les impriment, clés jamais rotées.
| Sur chaque PR | Scanner classique | Agent de sécurité en CI |
|---|---|---|
| Secrets | Bloque ou alerte sur un motif | Relie la clé au service, au propriétaire, au risque si elle est encore valide ; prépare la PR de retrait + la rotation |
| Dépendances | Ouvre ou signale une montée de version | Vérifie si la fonction vulnérable est appelée dans le diff / le graphe ; lit le changelog ; corrige le code cassé ; regroupe les bumps mineurs |
| Configs / IaC | Signale un écart générique | Explique l'écart sur cette PR (bucket public, rôle élargi, secret en dur dans un workflow) ; propose le moindre privilège |
| Suivi | Check rouge, ticket oublié | Résume ce qui bloque le merge, ce qui peut attendre, ce qui attend une décision humaine |
Règle qu'on garde : l'agent propose et prépare, un humain valide l'irréversible. Rotation d'un secret de prod, élargissement de droits, merge d'un diff auth : décision humaine.
Le pipeline type, du hook local à la revue par risque
1. Avant le push
Hook local (secrets + lint/typecheck rapides) et push protection côté forge. L'agent n'a pas besoin d'être là pour bloquer un token AWS en dur. Il intervient quand le signal est ambigu ou qu'il faut préparer la suite.
2. À chaque PR : trois lectures sur le même diff
- Secrets : findings du scanner + historique proche du diff. L'agent ignore le bruit (faux positifs évidents, fixtures documentées) et priorise ce qui ressemble à une clé encore utilisable.
- Dépendances : CVE ou bump lié aux fichiers touchés. Pas vingt PR Dependabot : une explication utile sur cette PR.
- Configs : workflows CI, Terraform/Pulumi, Docker, variables d'environnement déclarées. C'est là que CICD-SEC-6 se joue souvent : secret injecté trop large,
pull_request_targetdangereux, permissionwrite-allsur un job.
Puis l'agent commente le diff. Il ne bloque que sur des règles écrites (secret en dur, contrôle d'accès retiré, permission CI élargie sans justification). Le reste, c'est de l'aide pour le relecteur humain.
3. Revue par niveau de risque
Tout le monde n'a pas le même coût d'attente. Une PR qui touche auth/, la crypto, les policies cloud ou les workflows GitHub Actions mérite une revue humaine obligatoire, même si l'agent a mis un avis favorable. Une PR de copy ou de dépendance transitive mineure peut passer plus vite, avec l'agent en premier filtre. Octoverse le rappelle autrement : « review is where developers shape what comes back » (la revue, c'est là que les développeurs façonnent ce qui revient). Les agents écrivent plus. Les humains doivent choisir où poser leur attention.
4. Nuit et semaine
La nuit : l'agent deps traite les nouvelles CVE hors diff du jour. La semaine : un résumé pour le CTO ou le RSSI (corrigé / en attente / bloqué sur décision). Sans ce suivi, la CI ne produit que du rouge.
Ce que la CI ne voit pas (et pourquoi ça compte)
Le 29 octobre 2026, Cursor a signalé des versions malveillantes de l'extension Anthropic.claude-code (2.1.312 et 2.1.313) sur son marketplace, pendant quelques heures. Microsoft Threat Intelligence a confirmé une tentative de backdoor SSH persistante, limitée à ce marketplace (pas le VS Code Marketplace Microsoft ni le paquet npm officiel Anthropic).
Ce n'est pas un finding de pipeline. C'est la machine du développeur et sa chaîne d'outils. GitGuardian note aussi que, dans l'analyse Shai-Hulud 2, 59 % des machines compromises étaient des runners CI/CD, pas seulement des laptops. L'agent de sécurité en CI reste nécessaire, mais il ne suffit pas. Il faut aussi des skills de review des configs d'extensions, un inventaire des outils autorisés et une rotation si un poste ou un runner est exposé. Pour cadrer un outil comme Claude Code côté entreprise, voir Déployer Claude Code en entreprise. Le harness (sandbox, droits, boucles) est détaillé dans Agent harness en entreprise.
Skills versionnés plutôt que prompts jetables
« Secret en dur », « workflow trop permissif », « dépendance atteignable » ont une définition maison : vos frameworks, vos exceptions, vos repos. On les écrit en skills versionnés, revus en PR comme du code. Tous les dépôts partagent la même base. Une règle améliorée arrive partout le jour même.
C'est la logique qu'on applique avec Theodo : des Software Factories pour des centaines de développeurs, avec outils, agents et skills standardisés, plus la formation pour les adopter. The Vibe Company peut renforcer Theodo sur ce type de chantier (experts, agile, intégration d'équipe). La sécurité en CI est un des endroits où cette standardisation paie le plus vite : une règle oubliée dans un seul workflow suffit.
Par où commencer
- Inventaire : dépôts, workflows CI, coffres de secrets, scanners déjà branchés.
- Activer push protection + secret scanning là où c'est possible. Mesurer le volume d'alertes avant d'ajouter de l'agent.
- Brancher l'agent en lecture / commentaire sur un ou deux repos critiques. Pas de merge autonome.
- Écrire 5 à 10 règles maison en skills (secrets, permissions Actions, deps atteignables).
- Étendre deps + configs. Garder l'humain sur auth, secrets de prod, IAM.
Si vous sortez d'un POC agent, la même discipline « droits minimaux + validation humaine » s'applique : Du POC agent IA à la production.
Pour l'offre (cartographie, déploiement, intégration CI), voir Agents IA pour durcir produit et SI.
FAQ
Un agent de sécurité en CI remplace-t-il Dependabot ou le secret scanning ?
Non. Il s'appuie dessus. Sans scanner fiable, l'agent n'a rien de solide à lire. Il trie, explique et prépare.
Peut-il merger tout seul quand le check est vert ?
On ne le recommande pas sur les changements sensibles. L'agent peut regrouper des bumps mineurs et préparer la PR. Le merge auth, secrets et IAM reste humain.
Faut-il le faire tourner sur toutes les PR ?
Oui pour le scan de base (secrets / deps touchées / configs CI). La profondeur de commentaire et l'obligation de revue humaine doivent suivre le risque du diff.
Quelle différence avec Black October et l'article « durcir un SaaS » ?
Black October parle de protéger l'agent. « Durcir un SaaS » décrit la flotte. Cet article creuse le maillon CI à chaque PR.
Mettre un agent de sécurité dans votre CI
The Vibe Company est une agence IA à Paris. On déploie des agents et des skills dans votre CI pour scanner secrets, dépendances et configs à chaque PR, avec des droits minimaux et un humain pour valider.
