Matinale à Lyon (08/12) : 12 questions DevSecOps avant d’activer un agent IA dans GitLab

Un agent IA dans ta forge, c’est un nouveau collègue. Sauf qu’il a des accès.

Les assistants de code, tout le monde en parle. Les agents IA, c’est l’étape d’après. Ça lit le contexte projet, ça fouille des issues, ça analyse des merge requests, ça regarde des pipelines, ça propose des changements et, selon les configs, ça peut déclencher des actions.

Du point de vue RSSI, CTO, Lead DevOps, le sujet n’est pas “est-ce que ça aide les devs ?”. Le sujet, c’est “est-ce que je viens d’ouvrir une nouvelle porte sur ma chaîne logicielle ?”. Parce que la supply chain, elle se fait déjà attaquer, fort, et de plus en plus.

Une matinale à Lyon met précisément ce sujet sur la table : “IA pour les développeurs et sécurité de la chaîne logicielle”, annoncée le mardi 8 décembre 2026, de 8h30 à 14h00, au 17 Avenue Georges Pompidou, 69003 Lyon. Format sur invitation, demande à faire avant le 1er décembre 2026, selon la page d’annonce publiée par Klee Group. Source : kleegroup.com.

À noter : le même jour, Cap’IA (Minalogic) est aussi annoncé dans la métropole (Villeurbanne). Ça situe l’intensité du calendrier IA à Lyon ce 08/12. Source : minalogic.com. Et côté Lyon IA, on a déjà la fiche pratique sur Cap’IA : https://lyon-ia.com/blog/capia-2026-a-lyon-8-decembre-repars-avec-3-cas-dusage-priorises-et-un-plan-60-jours.

Pourquoi “agent IA + sécurité chaîne logicielle” devient un sujet de comex tech

Trois faits simples.

• Les attaques supply chain augmentent. Red Hat recense 137 attaques de chaîne logicielle publiquement rapportées en 2025, soit +54% vs 2024. Source : redhat.com.
• Une partie est à impact large. Red Hat classe environ 7,3% de ces attaques 2025 en “high-impact”, c’est-à-dire touchant plusieurs entités en aval. Source : redhat.com.
• Les tactiques typiques collent parfaitement aux usages dev. Artefacts malveillants, fuites de secrets, typosquatting et combosquatting font partie des techniques fréquentes citées par Red Hat. Source : redhat.com.

Ajoute un accélérateur : les secrets qui fuient. ReversingLabs rapporte une hausse de 12% des leaks de secrets développeurs et informations sensibles sur la période étudiée, et relie ce facteur à des compromissions supply chain. Source : ntsc.org (PDF).

Et ajoute le terrain : Unit 42 (Palo Alto Networks) met en avant la croissance des attaques cloud et software supply chain, sur la base de plus de 500 cas traités entre octobre 2023 et décembre 2024. Source : paloaltonetworks.com.

Maintenant, mets un agent IA au milieu. GitLab pousse des scénarios “agentiques” connectés au contexte projet (issues, merge requests, pipelines, security findings…). Source : about.gitlab.com.

Traduction RSSI : tu ajoutes une brique qui peut lire beaucoup plus qu’un humain en peu de temps, et agir vite. Si elle se fait manipuler, c’est une surface d’attaque qui scale.

Avant d’activer GitLab Duo Agent Platform ou un agent “ailleurs” : 12 questions DevSecOps

Objectif : des questions qui forcent des réponses vérifiables. Pas des promesses. Pas des “on verra”.

Tu peux les utiliser telles quelles pour cadrer un pilote IA DevSecOps Lyon, que tu sois sur GitLab, GitHub, Azure DevOps, Bitbucket ou une plateforme interne.

1) Quelles données sortent réellement de ton périmètre, et dans quels cas ?

Ne reste pas au niveau “du code”. Liste les sources de contexte possibles :

• code, diffs, MR, commentaires
• issues, descriptions, pièces jointes
• logs CI, outputs d’outils (lint, tests, scanners)
• artefacts build, SBOM, rapports de vulnérabilités
• variables CI, environnements, métadonnées projet

Ensuite : dans quels scénarios l’agent y accède (chat, workflow, tool call, exécution via runner, via IDE/CLI). C’est ça, le vrai périmètre d’exposition.

2) Quels modèles sont appelés, via quels sous-traitants, et avec quelles options de rétention ?

La question n’est pas “c’est quel LLM ?”. C’est :

• modèle par défaut et modèles alternatifs possibles
• où ça tourne (cloud fournisseur, région, sous-processeurs)
• politique de rétention et exceptions (prompt caching, logs)

GitLab indique par exemple une “zero data retention policy” avec Fireworks AI, avec des exceptions (prompt caching), et précise que pour certains modèles dont OpenAI, on ne peut pas désactiver le prompt caching. Source : docs.gitlab.com.

3) Est-ce que tes données peuvent servir à entraîner un modèle, directement ou indirectement ?

C’est un point contractuel et technique. GitLab indique explicitement ne pas entraîner ses modèles génératifs sur les données clients, et que les sous-traitants sont contractuellement restreints de le faire. Source : docs.gitlab.com.

À faire : demander la clause, le périmètre, et la définition exacte de “training” (inclut-il fine-tuning, amélioration produit, rétention pour debug, évaluations internes ?).

4) Qu’est-ce qui est journalisé, et où ?

Un agent utile est souvent un agent traçable. Mais la traçabilité peut devenir une fuite si tu logges tout.

GitLab documente qu’il existe un historique de chat et de workflows (supprimable côté interface) et qu’un mode “expanded logging” peut conserver des traces. Source : docs.gitlab.com.

Point très concret : le switch “collect usage data”. Si activé, GitLab indique que ça peut journaliser le texte complet des prompts et réponses, les tool calls et leurs résultats, etc. Source : docs.gitlab.com.

Questions à poser :

• qui a accès aux logs (admins plateforme, provider, support) ?
• durée de rétention, export possible, purge possible ?
• les logs partent-ils dans ton SIEM, et avec quel filtrage ?

5) Comment est gérée la séparation des environnements (dev, CI, staging, prod) ?

Un agent qui “aide” sur des MR n’a pas besoin de credentials de prod. Basique. Pourtant, dans la vraie vie, les frontières deviennent floues via CI/CD.

Exige :

• un mode lecture seule par défaut
• des permissions différentes selon espace (projet, groupe)
• des runners dédiés et isolés pour les flows agentiques

6) Qui gère les secrets, et à quel moment ils peuvent fuiter ?

Deux risques : secrets dans le contexte envoyé au LLM, et secrets accessibles via tool calls (exemple : “lis cette variable CI”).

GitLab décrit un pré-scan de secrets basé sur Gitleaks et une suppression automatique de secrets détectés avant envoi à un LLM dans plusieurs scénarios (context transformation, tool results, Agentic Chat user input, etc.). Source : docs.gitlab.com.

Mais GitLab précise aussi que ce scanning ne s’applique pas quand on utilise Duo Chat via l’interface web. Source : docs.gitlab.com.

Donc tu demandes :

• dans quels chemins d’usage le secret scanning s’applique, et où il ne s’applique pas
• comment sont traités les faux négatifs
• quelle politique interne tu mets si l’agent n’est pas “safe by design” partout

Sur Lyon IA, on a aussi un angle “secrets + agents” à garder sous la main : https://lyon-ia.com/blog/1password-for-agents-et-gestion-des-secrets-autoriser-des-agents-ia-sans-fuite.

7) Quels outils l’agent peut appeler, et avec quel contrôle humain ?

Un agent, ce n’est pas juste du texte. C’est des actions. Et l’action, c’est là que tu perds le contrôle si tu vas trop vite.

GitLab décrit des contrôles du type human-in-the-loop, restrictions d’outils, restrictions d’accès fichiers, et contrôle des flux sortants (allowlist/denylist egress), selon les modes d’exécution. Source : docs.gitlab.com.

Questions :

• liste explicite des tool calls autorisés
• validation obligatoire avant toute écriture (push, MR, release, tag)
• validation obligatoire avant toute action externe (HTTP, tickets, registry)

8) Comment tu bloques la prompt injection dans un contexte dev ?

La prompt injection, ce n’est pas un truc de chercheurs. Dans une forge, l’attaquant peut cacher des instructions dans :

• un fichier dans le repo
• une issue
• un commentaire de MR
• un output d’outil

GitLab documente ce risque et ses impacts possibles : actions non autorisées, exfiltration, escalade, injection de code dans la supply chain. Source : docs.gitlab.com.

Ce que tu veux entendre :

• délimitation stricte des sources de vérité (système vs contenu utilisateur)
• règles d’outillage : l’agent ne doit pas obéir à une issue qui demande d’exfiltrer un secret
• tests de sécurité dédiés “prompt injection” dans le pilote

À relier avec une base utile : https://lyon-ia.com/blog/injection-de-prompt-securite.

9) Quel est le modèle d’autorisations : identité, scopes, rotation, révocation ?

Un agent doit avoir une identité distincte. Pas un token perso de dev qui traîne.

• comptes de service dédiés
• scopes minimaux
• rotation automatique
• révocation immédiate et testée

Si tu n’as pas de réponse claire sur la révocation, tu n’as pas de pilote. Tu as un pari.

10) Comment tu contrôles les dépendances et artefacts que l’agent peut introduire ?

Un agent qui “corrige” peut ajouter une lib, changer une version, modifier un Dockerfile, éditer un workflow CI. C’est exactement là que la chaîne logicielle prend feu si tu laisses passer sans garde-fou.

Questions :

• politiques de dépendances (allowlist, registries internes, miroirs)
• scans SCA et SBOM systématiques
• signature d’artefacts, provenance, règles de déploiement
• typosquatting et combosquatting : quelles détections en place ?

Rappel : Red Hat cite typosquatting et combosquatting parmi les tactiques fréquentes 2025. Source : redhat.com.

11) Quelle conformité tu déclenches quand du code et des traces partent vers un LLM ?

Ce n’est pas “RGPD ou pas RGPD”. C’est :

• classification des données (code sensible, secrets, données perso dans logs)
• base légale et information interne
• registre des traitements, DPA, transferts, sous-traitants
• durées de conservation et droit à l’effacement côté outil

Pour cadrer l’angle “agents + conformité” sans tourner en rond : https://lyon-ia.com/blog/ia-agentique-et-rgpd-ce-que-la-note-cnil-change-pour-vos-agents-check-list-a-lyon.

12) Comment tu mesures et limites le blast radius si ça part en vrille ?

Un agent compromis, ou juste mal cadré, ça doit rester petit. Très petit.

Demande :

• quotas et rate limiting (actions, appels API, coûts tokens)
• segmentation projet (pas d’accès transverse par défaut)
• kill switch (désactivation globale + par projet)
• détection d’anomalies (actions inhabituelles, exfiltration, créations massives)

Sur ce point, le sujet “traces, audit, logs” est souvent sous-estimé, alors que c’est ce qui te permet de comprendre après coup. À relier : https://lyon-ia.com/blog/agents-ia-et-cybersecurite-effacement-de-traces-audit-des-logs-et-acces-avant-dautomatiser.

Mémo “minimum acceptable” pour un pilote en entreprise

Tu veux tester vite. OK. Mais pas au prix de transformer ta forge en passoire. Voilà le minimum acceptable, version terrain, pour lancer un pilote agent IA dans GitLab ou ailleurs.

Périmètre et données

• 1 seul projet non critique, données classées “interne” maximum.
• Interdiction d’envoyer : secrets, clés API, dumps, exports clients, logs prod.
• Mapping écrit de ce qui sort vers le modèle, cas par cas (chat, MR, CI, outils).

Accès et exécution

• Identité agent dédiée, scopes minimaux, rotation et révocation testées.
• Lecture seule par défaut, écriture uniquement via MR avec review humaine.
• Runners isolés pour les flows agentiques, pas de secrets prod accessibles.

Logs, rétention, sécurité

• Logging maîtrisé : pas de collecte “full prompts” par défaut sans besoin clair.
• Rétention courte et purge possible.
• Tests prompt injection inclus dès le pilote (issues et fichiers piégés).

Chaîne logicielle

• Policy dépendances : pas d’ajout de package non approuvé.
• SCA et SBOM systématiques sur les MR créées ou modifiées avec l’agent.
• Release sous contrôle : signatures, provenance, gates CI inchangés.

Stop, rollback, responsabilité

• Kill switch clair (qui peut couper, comment, en combien de minutes).
• Rollback documenté (retour à l’état avant pilote, tokens révoqués, accès retirés).
• Owner nommé côté RSSI et côté plateforme dev (pas “tout le monde”).

Ce que tu dois préparer avant la matinale à Lyon

Si tu veux que la matinée te serve, arrive avec ces trois éléments :

• un cas d’usage précis (ex : review MR, génération de tests, tri findings, refacto) et ce que tu acceptes comme actions
• une carte des données : où sont les secrets, où sont les logs, où sont les artefacts
• une position “pilotable” : ce que tu autorises en lecture, ce que tu refuses en écriture

Et si tu veux cadrer plus large “agents en entreprise” avant de descendre au niveau GitLab Duo Agent Platform Lyon, tu peux partir de cette checklist interne : https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.

Le message à garder : un agent IA peut être un boost de productivité. Mais dans une supply chain déjà ciblée, c’est aussi un multiplicateur de risques si tu l’actives “en mode feature”. Pose les 12 questions. Exige des preuves. Et fais un pilote qui peut s’éteindre proprement.