Noma Labs a démontré qu'un simple ticket (issue) GitHub public peut permettre de voler du code de dépôts privés via une automatisation pilotée par l'IA. Leur preuve de concept permet à un attaquant de retourner les propres bots de workflow d'une organisation contre elle, divulguant des fichiers propriétaires sans compromettre l'authentification de GitHub.

L'attaque au vu et au su de tous

La chaîne d'événements est suffisamment simple pour être reproduite :

  • Un attaquant crée un ticket (issue) dans un dépôt public consultable par tous.
  • Un agent d'IA, intégré au pipeline d'intégration continue, lit le titre et le corps du ticket.
  • Ce même agent possède déjà des permissions de lecture pour d'autres dépôts privés au sein de l'organisation.
  • Des instructions cachées dans le ticket public indiquent à l'agent quels fichiers privés récupérer.
  • L'agent publie les fichiers récupérés en commentaire du ticket public, les exposant ainsi au monde entier.

Tout se déroule lors d'un seul cycle d'automatisation. Aucun vol d'identifiants, aucune fuite de clé API, aucune vulnérabilité GitHub. L'attaquant exploite simplement la confiance que l'organisation accorde à son propre bot.

Pourquoi c'est important aujourd'hui

Les agents alimentés par l'IA servent désormais de liant aux pipelines de développement modernes. Ils ouvrent des pull requests, exécutent des tests, déploient des builds et trient les bugs — le tout déclenché par des signaux légers tels que des commentaires de tickets. Lorsque ces agents disposent d'un accès étendu aux dépôts, la frontière entre les données de confiance et les entrées utilisateur non fiables devient floue.

Si un agent peut lire du code privé et écrire publiquement lors de la même exécution, le modèle de contrôle d'accès de l'organisation s'effondre.

La véritable faille : les permissions, pas le modèle

La démonstration n'implique pas le modèle d'IA sous-jacent. Le modèle ne fait que suivre les instructions qu'il reçoit. La vulnérabilité réside dans l'ensemble des permissions accordées à l'automatisation :

  • Accès en lecture aux dépôts privés de toute l'organisation.
  • Accès en écriture aux fils de discussion des tickets publics.
  • Déclenchement basé sur du texte public que n'importe qui peut rédiger.

Des correctifs gratuits et efficaces

L'application du principe du moindre privilège réduit considérablement la surface d'attaque :

  • Limiter le périmètre du bot au dépôt où il est nécessaire. S'il doit seulement agir sur un dépôt spécifique, refusez-lui tout autre droit de lecture.
  • Séparer les jetons de lecture et d'écriture. Utilisez un identifiant pour la récupération du code et un autre, strictement contrôlé, pour la publication de commentaires.
  • Approbation humaine avant toute publication publique. Une étape de révision légère — comme l'exigence d'un label d'approbation — ajoute un point de contrôle sans interrompre le pipeline.
  • Réduction du rayon d'impact. Concevez des workflows de manière à ce qu'une défaillance ou un usage abusif n'affecte qu'un seul dépôt au maximum, et non l'ensemble de l'organisation.

Contre-argument : surcharge opérationnelle

À surveiller ensuite

À retenir : Si une automatisation par IA peut à la fois voir du code privé et s'exprimer publiquement, le système est mal conçu. Renforcez les permissions, insérez des contrôles humains et limitez le rayon d'impact — sinon, un simple ticket public peut devenir un vecteur de fuite de données.