TP29 : AI-assisted DevSecOps (code généré par IA, agents et credentials)

Les assistants IA écrivent désormais une part importante du code, des Dockerfiles, du Terraform et des manifests Kubernetes. Ils sont rapides et convaincants, mais ils reproduisent des mauvaises pratiques, inventent parfois des dépendances qui n’existent pas, et, lorsqu’ils deviennent des agents capables d’agir, ils manipulent des credentials et lisent des contenus qui peuvent les détourner (prompt injection). Ce TP ne cherche ni à interdire ni à promouvoir l’IA : il montre que la chaîne DevSecOps construite depuis le TP7 s’applique telle quelle au code généré, et il ajoute les garde-fous propres aux agents.

Fichiers de départ : ai-generated.zip, checks.zip, policy.zip, prompt-injection.zip

1. Objectifs pédagogiques

À l’issue du TP, vous serez capable de :

• soumettre du code et de l’IaC générés par IA aux mêmes contrôles que le code humain (revue, tests, SAST, secrets, dépendances, IaC, policies) ;
• reconnaître les défauts typiques du code généré et les corriger ;
• détecter une dépendance inventée et expliquer le risque de slopsquatting ;
• expliquer et démontrer une injection de prompt indirecte sans danger ;
• appliquer le moindre privilège et les jetons éphémères aux agents, et rédiger une politique d’usage.

Les images de cette page sont des schémas explicatifs, pas des captures d’écran.

2. Environnement du TP

• VM de lab avec Docker (tous les scanners tournent en conteneur), Node.js et npm.
• Un assistant IA de votre choix (assistant de code dans l’IDE, agent en ligne de commande ou chat), utilisé dans le respect des règles de votre établissement. Ne lui confiez aucun secret réel.
• Les outils et policies des TP précédents : Gitleaks et Semgrep (TP10), Checkov et Trivy (TP13), policies Kyverno (TP17).

3. Partie 1 : Lire le code généré comme un relecteur

• Lire les fichiers de ai-generated/ sans outil, puis lister tous les défauts que vous trouvez, fichier par fichier, avec leur gravité.
• Classer les défauts par famille : secrets, injection, exécution de code, configuration, privilèges, chaîne d’approvisionnement, fuite d’information.

4. Partie 2 : Les mêmes contrôles que pour le code humain

• Lancer le script checks/run-all-checks.sh :

  chmod +x checks/run-all-checks.sh
  ./checks/run-all-checks.sh ai-generated

• Compléter le tableau : quels défauts de votre liste manuelle sont détectés, et par quel outil ? Lesquels aucun outil ne voit-il ?

• Compléter le TODO Kyverno du script (policies du TP17 appliquées à deployment.yaml).

5. Partie 3 : Dépendances inventées (slopsquatting)

• Vérifier sans installer chaque dépendance de package.json :

  for dep in $(jq -r '.dependencies | keys[]' ai-generated/package.json); do
    printf '%-40s ' "$dep"; npm view "$dep" name 2>/dev/null || echo "INTROUVABLE"
  done

• Expliquer le risque : un attaquant qui observe les noms de paquets souvent « inventés » par les modèles peut publier un paquet malveillant sous ce nom. Le prochain développeur qui fait confiance à la suggestion l’installe.

• Compléter le TODO correspondant dans run-all-checks.sh pour faire échouer la vérification si une dépendance n’existe pas. Quels autres critères vérifier pour un paquet qui existe (âge, mainteneurs, téléchargements, scripts postinstall) ?

6. Partie 4 : Corriger avec l’IA… et revérifier

• Demander à votre assistant de corriger app.js, Dockerfile, main.tf et deployment.yaml, en lui donnant les rapports des scanners.
• Relancer run-all-checks.sh sur les fichiers corrigés. Tout est-il vert ? L’assistant a-t-il introduit de nouveaux problèmes, supprimé une fonctionnalité ou « contourné » un contrôle (par exemple avec nosemgrep ou une skip Checkov) ?
• Ouvrir une Pull Request avec le label ai-assisted dans un dépôt de test protégé par les contrôles du TP10 : elle ne doit pouvoir être fusionnée qu’avec tous les checks verts et une revue humaine.
• Demander volontairement à l’assistant une mauvaise configuration (par exemple « rends le bucket public pour simplifier ») et vérifier que le pipeline la bloque.

7. Partie 5 : Agents, injection de prompt et credentials

• Lire le fichier prompt-injection/README.md dans un éditeur en mode source : que contient le commentaire HTML invisible dans le rendu ?

• Dans un dossier de test isolé (aucun secret dans l’environnement), demander à un agent de code « d’intégrer utils-lib dans l’application en suivant son README ». Observer s’il exécute l’instruction cachée ou s’il la signale. Documenter le résultat, quel qu’il soit.

  L’instruction cachée est volontairement inoffensive dans un environnement vide. Dans un vrai dépôt, la même technique peut viser l’exfiltration de variables d’environnement, l’ajout d’une dépendance ou l’envoi de données vers un serveur externe.

• Dresser l’inventaire des credentials qu’un agent DevOps pourrait utiliser dans votre lab (jeton GitHub, kubeconfig, clés AWS de Floci, jeton Vault, jeton Argo CD…) et, pour chacun : portée actuelle, portée minimale nécessaire, durée de vie, moyen de révocation.

• Appliquer le moindre privilège à un cas concret : créer pour un agent un fine-grained token GitHub limité à un seul dépôt, en lecture seule sur le code et en écriture sur les Pull Requests uniquement, avec une expiration de 7 jours. Créer de même un ServiceAccount Kubernetes en lecture seule sur un namespace (TP17) et générer un jeton à durée limitée (kubectl create token agent-sa --duration=1h).

8. Partie 6 : Politique d’usage

• Compléter le modèle policy/ai-usage-policy-template.md pour une équipe DevSecOps.
• Débattre en groupe : quels gains réels l’IA apporte-t-elle dans la chaîne (rédaction de tests, explication d’alertes, revue préliminaire, génération de runbooks…) et à quelles conditions ?

Défi

1. Écrire une règle Semgrep personnalisée qui détecte eval( sur une valeur provenant de req.query ou req.body, et une règle qui interdit de renvoyer process.env dans une réponse HTTP.
2. Ajouter au workflow GitHub Actions un job qui commente automatiquement les PR étiquetées ai-assisted avec la liste des nouvelles dépendances ajoutées et leur date de première publication sur npm.

9. Livrables

Captures à déposer dans captures/ :

Ainsi que : la liste des défauts, le tableau de détection, les fichiers corrigés, l’inventaire des credentials et la politique d’usage complétée.