ISGroup Conseil en Cybersécurité

AWS Kiro et développement piloté par les spécifications : structure, sécurité et vérifications avant le go-live

AWS Kiro et développement piloté par les spécifications : plus de structure ne signifie pas automatiquement plus de sécurité

Kiro répond à un besoin réel des équipes ayant expérimenté le « vibe coding » : moins de chaos, plus de contexte, des spécifications plus lisibles, des tâches mieux ordonnées et une documentation plus proche du code. Le développement piloté par les spécifications (spec-driven development) apporte une discipline utile au développement assisté par l’IA, surtout lorsque le projet dépasse le stade de la simple démo pour devenir une fonctionnalité, un service, une plateforme interne ou une application destinée à des utilisateurs réels.

[Callforaction-WAPT]

Le point critique est de ne pas confondre structure et sécurité. Une spécification bien rédigée peut décrire une architecture vulnérable. Une exigence formulée en EARS peut être formellement claire tout en omettant totalement l’isolation des tenants, l’escalade de privilèges, la gestion des secrets ou les abus d’API. Un plan d’implémentation peut être ordonné tout en ne couvrant que le « chemin heureux » (happy path). Avant le déploiement, la question pertinente n’est pas de savoir si Kiro rend le code plus organisé, mais si les exigences, la conception, les tâches, les hooks, les serveurs MCP, les tests et l’implémentation contiennent des contrôles de sécurité suffisants pour connecter des données réelles, des utilisateurs, des API, le cloud et les systèmes d’entreprise.

Ce que le développement piloté par les spécifications améliore et ce qu’il ne couvre pas

Kiro fait passer l’équipe de prompts naturels à des exigences structurées, une conception et des tâches exécutables, réduisant une partie du risque typique du « vibe coding » : décisions implicites, documentation obsolète, fonctionnalités générées de manière extemporanée et difficiles à maintenir. La structure, cependant, ne garantit pas que les exigences soient justes. Si une spécification n’inclut pas les rôles, les données sensibles, les autorisations au niveau de l’objet, les limites de débit (rate limiting), les logs, la rétention, les frontières de confiance (trust boundaries), la gestion des erreurs et les cas d’abus, l’agent peut implémenter de manière cohérente un produit incomplet du point de vue de la sécurité.

Il en va de même pour les tests. Un plan bien généré peut vérifier que l’utilisateur parvient à compléter le flux prévu, mais cela ne prouve pas qu’un utilisateur d’un autre tenant ne puisse pas lire le même enregistrement, qu’une API n’accepte pas des identifiants arbitraires, qu’une politique IAM ne soit pas trop large ou qu’un hook n’exécute pas des commandes non révisées.

Le risque de la spécification parfaite mais incomplète

Les spécifications aident à rendre l’intention explicite, mais si cette intention initiale n’inclut pas la sécurité, la confidentialité et les abus, le résultat reste fragile. Une phrase comme « l’utilisateur peut visualiser ses propres documents » doit devenir vérifiable : quels documents, avec quelle identité, avec quels rôles, que se passe-t-il si l’ID est modifié, que se passe-t-il avec un jeton expiré, que se passe-t-il si un administrateur d’un tenant tente de lire un autre tenant ?

Kiro peut aider à transformer des exigences en tâches, mais la qualité du résultat dépend de la qualité des exigences elles-mêmes. C’est pourquoi chaque spécification destinée à une fonction exposée devrait inclure des critères d’acceptation négatifs : accès refusé, entrée rejetée, fichier non autorisé, rôle insuffisant, mauvais tenant, jeton expiré, callback non listé dans les autorisations, secret non journalisé. Une spécification qui ne dit rien sur ce qui doit être bloqué laisse trop de place à l’implémentation de l’agent, avec le risque de produire une documentation rassurante qui montre ce que l’application doit faire, mais pas ce qu’elle ne doit pas permettre.

Le threat modeling au sein du processus piloté par les spécifications

Le threat modeling ne doit pas devenir un document lourd séparé du développement. Dans un workflow Kiro, il peut être intégré à la phase d’exigences et de conception, couvrant les actifs, les acteurs, les frontières de confiance, les données sensibles, les systèmes externes, les privilèges, les flux et les modes de défaillance. Pour chaque spécification, l’équipe doit se demander quelles données sont traitées, quels rôles existent, quelles actions sont sensibles, quelles API sont publiques, quels systèmes externes sont appelés, quels secrets sont nécessaires et quelles commandes ou ressources cloud seront touchées. Si l’application est multi-tenant, l’isolation des tenants doit être une exigence de premier niveau, et non une simple note d’implémentation.

La conception générée ou assistée par Kiro doit également être lue avec une approche offensive : comment pourrait-elle être détournée ? Un flux d’invitation peut-il être réutilisé ? Une réinitialisation de mot de passe peut-elle révéler des utilisateurs ? Une route d’administration est-elle réellement protégée côté serveur ? Un téléchargement peut-il servir des contenus actifs ? Une tâche IaC crée-t-elle des ressources accessibles depuis Internet ?

Agent Hooks : automatisation utile, surface à gouverner

Les Agent Hooks sont l’un des éléments les plus spécifiques de Kiro. Ils peuvent s’activer sur des événements tels que la soumission de prompts, l’arrêt de l’agent, l’utilisation d’outils (avant/après), la création, l’enregistrement ou la suppression de fichiers, l’exécution de tâches et les déclenchements manuels, avec des actions incluant des prompts à l’agent ou des commandes shell. Cette automatisation peut être très utile pour formater le code, mettre à jour la documentation, générer des tests, vérifier les standards, bloquer des outils ou enrichir le contexte. Cependant, elle peut devenir une surface critique si elle exécute des commandes, modifie des fichiers, installe des dépendances, lance des tests, interagit avec des CLI cloud ou modifie des configurations sans révision.

Avant d’adopter des hooks dans une équipe, il convient de faire un inventaire des fichiers .kiro/hooks, des événements qui les activent, des actions exécutées et des permissions disponibles dans le dépôt. Les commandes shell doivent être traitées comme du code opérationnel : qui les approuve, que peuvent-elles lire, que peuvent-elles écrire, quelles variables d’environnement voient-elles, peuvent-elles exécuter des déploiements, des suppressions, des migrations ou des commandes cloud ? Un hook qui s’exécute lors de l’enregistrement d’un fichier ne devrait pas pouvoir appliquer Terraform, supprimer des ressources, installer des paquets non approuvés ou envoyer des données sensibles à des systèmes externes. Les automatisations à fort impact doivent avoir des seuils, des logs et une approbation séparée.

Fichiers de pilotage (Steering files) et règles de projet

Kiro permet de guider les agents avec des fichiers de pilotage et des règles de projet, rendant explicites les conventions, les standards et les préférences. Ici aussi, les instructions persistantes deviennent une partie du périmètre de sécurité. Une règle qui pousse l’agent à « faire passer les tests », « utiliser des mocks quand des services manquent », « simplifier l’authentification » ou « procéder même si le contexte est incomplet » peut normaliser des raccourcis risqués. À l’inverse, des règles bien rédigées peuvent empêcher des modifications de l’authentification sans tests négatifs, bloquer les secrets dans le frontend, exiger une révision sur l’IAM/IaC et imposer un refus par défaut (default deny) sur les politiques.

Les fichiers de pilotage doivent être révisés comme du code. Ils doivent séparer le style, l’architecture et la sécurité, éviter les secrets et les endpoints internes inutiles, et ne pas contenir d’instructions ambiguës. Chaque modification de ces fichiers devrait passer par une révision de PR, car elle influence toutes les tâches futures.

MCP, outils externes et contexte de la spécification

Kiro prend en charge le protocole MCP (Model Context Protocol) et peut se connecter à la documentation, aux bases de données, aux API, aux outils AWS, à Terraform ou à d’autres systèmes, augmentant considérablement la qualité du contexte mais élargissant également les frontières de confiance du workflow. Si un serveur MCP donne accès à des bases de données, des tickets, des dépôts, le cloud, la documentation interne ou un registre Terraform, l’agent peut incorporer ces informations dans la spécification et les décisions d’implémentation. Le risque ne réside pas dans le MCP en soi, mais dans l’utilisation d’outils et d’identifiants trop larges : jetons partagés, permissions en lecture-écriture alors que la lecture seule suffit, accès à des données réelles pendant la conception, outils de déploiement disponibles dans des phases non contrôlées.

La gouvernance MCP pour Kiro devrait inclure une liste blanche de serveurs, des jetons dédiés, des privilèges minimaux, une séparation entre projet et configurations globales, l’audit des appels d’outils et la désactivation des outils non nécessaires sur les dépôts critiques. Si des outils AWS ou Terraform sont utilisés, les modifications résultantes doivent passer par une révision IaC et une approbation avant l’application.

Terraform, IaC et cloud : quand la spécification crée de l’infrastructure

L’un des scénarios les plus délicats est l’utilisation de Kiro pour concevoir ou générer de l’infrastructure : Terraform, CloudFormation, CDK, groupes de sécurité, IAM, VPC, bases de données, stockage, équilibreurs de charge, pipelines. La spécification peut rendre le travail ordonné, mais le risque cloud reste concret. Une spécification demandant de « créer un environnement pour l’application » peut conduire à des groupes de sécurité trop larges, des buckets publics, des rôles IAM génériques, des bases de données accessibles, des sorties contenant des secrets, des environnements dev/prod peu séparés, une absence de chiffrement, de journalisation ou de sauvegarde. Le résultat peut être cohérent avec la demande tout en étant inacceptable en production.

Avant d’appliquer une IaC générée ou modifiée avec Kiro, il faut des « plan diff », des scanners IaC, une révision manuelle, un contrôle du moindre privilège, un étiquetage (tagging), une séparation des environnements, un plan de retour arrière et une approbation explicite sur les ressources critiques. L’application de l’IaC ne doit pas être un effet secondaire d’une tâche agentique ou d’un hook.

Tests générés : fonctionnels, pas nécessairement offensifs

Kiro peut aider à générer des tests liés aux exigences, mais les tests dérivés de la spécification ont tendance à vérifier que le système fait ce qui a été demandé. La sécurité exige également de démontrer que le système refuse ce qu’il ne doit pas permettre. Pour chaque fonctionnalité exposée, des tests négatifs sont nécessaires : utilisateur non authentifié, rôle insuffisant, mauvais tenant, objet d’un autre utilisateur, entrée malveillante, fichier invalide, requête hors séquence, jeton expiré, limite de débit, callback non autorisé, erreur contrôlée. Si ces cas ne figurent pas dans la spécification, il est peu probable que l’agent les couvre de manière robuste.

Les tests automatiques doivent ensuite être complétés par une révision de code et, lorsque l’application ou l’API est en ligne, par un WAPT (Web Application Penetration Test) manuel. Les vulnérabilités les plus graves ne sont souvent pas des bugs syntaxiques, mais des incohérences entre les exigences, l’implémentation et le comportement réel.

Dérive entre spécifications, implémentation et documentation

L’un des avantages du développement piloté par les spécifications est de maintenir ensemble l’intention, la conception et l’implémentation. Le risque est de croire que cette traçabilité est automatique et toujours correcte. Pendant le développement, l’agent peut découvrir que la spécification est incomplète et modifier l’implémentation ; le développeur peut accepter une solution de contournement sans mettre à jour les exigences et la conception ; un hook peut mettre à jour une documentation qui décrit ce qui devrait se passer, et non ce que le code applique réellement. La spécification peut rester ordonnée tout en devenant fausse.

Pour les domaines liés à la sécurité, la traçabilité doit être vérifiée : chaque exigence de contrôle d’accès doit avoir une implémentation, un test positif, un test négatif et un responsable. Chaque frontière de confiance doit avoir des contrôles dans la conception et dans le code. Chaque exception acceptée doit avoir une motivation et une mesure de remédiation.

Fatigue des permissions et approbations

Kiro peut introduire de nombreux points d’approbation : tâches, hooks, utilisation d’outils, commandes shell, MCP, modifications de fichiers, tests, PR, IaC. Si tout exige le même niveau d’attention, l’équipe risque une « fatigue des permissions » et finit par accepter automatiquement. La solution n’est pas de tout bloquer, mais de classer le risque. Le formatage, la documentation et le refactoring local peuvent suivre un parcours léger, tandis que l’authentification, l’IAM, les secrets, les API publiques, les bases de données, le stockage, les migrations, les déploiements, les suppressions, Terraform et les CLI cloud doivent faire l’objet d’approbations plus strictes et de réviseurs compétents. Cette distinction doit être décidée avant que Kiro n’intègre le workflow de production, car si la règle est improvisée lors d’une mise en production urgente, l’équipe aura tendance à privilégier la vitesse.

Checklist Kiro avant la mise en ligne (go-live)

Spécifications et conception

  • Relisez les exigences EARS et vérifiez qu’elles incluent la sécurité, les rôles, les données, les autorisations, l’isolation des tenants, la journalisation, la gestion des erreurs, la rétention et les cas d’abus.
  • Ajoutez des critères d’acceptation négatifs pour ce qui doit être rejeté.
  • Liez chaque exigence critique à la conception, aux tâches, au code et aux tests.

Hooks, pilotage et MCP

  • Faites l’inventaire des .kiro/hooks, des déclencheurs, des commandes shell, des actions de prompt et des outils impliqués.
  • Révisez les fichiers de pilotage comme du code.
  • Recensez les serveurs MCP, les jetons, les privilèges, les données accessibles et les outils disponibles.
  • Désactivez ce qui n’est pas nécessaire sur les dépôts critiques.

Code, API et tests

  • Effectuez une révision de code sur l’authentification, le middleware, les API, la validation, la logique métier, la gestion des erreurs, les secrets et les dépendances.
  • Intégrez des tests négatifs sur les rôles, les tenants, les IDOR/BOLA, les entrées malveillantes, les sessions, les téléchargements et les limites de débit.
  • Si l’application est exposée, planifiez un WAPT sur l’environnement réel.

Cloud, IaC et production

  • Révisez Terraform, CloudFormation, CDK, les groupes de sécurité, l’IAM, le stockage, les bases de données, le réseau, les pipelines et les secrets avant l’application (apply).
  • Vérifiez le moindre privilège, la séparation des environnements, la journalisation, les sauvegardes, les retours arrière et les approbations.
  • Aucune commande de déploiement ou de destruction ne devrait être un effet automatique d’un hook ou d’une tâche sans contrôle.

Quand une révision interne suffit-elle et quand une vérification indépendante est-elle nécessaire ?

Une révision interne peut suffire si Kiro est utilisé pour des spécifications ou du refactoring non exposés, sans données réelles, sans IaC, sans API publiques et sans automatisations à fort impact. Une vérification indépendante est nécessaire lorsque les spécifications guident des fonctions traitant des données réelles, des rôles, des tenants, des paiements, des intégrations, des API publiques, de l’IaC, AWS, Terraform, MCP ou des hooks exécutant des commandes, ou lorsque l’équipe souhaite adopter Kiro de manière continue et doit définir des politiques, des seuils de révision, des responsabilités et des contrôles répétables.

Le but n’est pas de ralentir Kiro, mais de séparer ce qui peut être accéléré de ce qui doit être validé : exigences, frontières de confiance, automatisations, outils, cloud, code et comportement réel.

Comment ISGroup peut vérifier un projet développé avec Kiro

Le contrôle change en fonction de ce que Kiro a structuré, généré ou automatisé. Si le risque réside dans les exigences, le modèle de menace ou les choix architecturaux, la Secure Architecture Review aide à valider la conception, les frontières de confiance et les flux de données. Si le risque concerne AWS, Terraform, IAM, les groupes de sécurité, le stockage ou les pipelines, le Cloud Security Assessment vérifie les configurations et les privilèges. Si l’objectif est de gouverner l’adoption, les politiques et les seuils de révision, le Risk Assessment aide à définir les priorités et les responsabilités.

Si Kiro a touché… Risque principal Contrôle conseillé
Spécifications, exigences, conception, frontières de confiance, flux de données Hypothèses architecturales faibles Secure Architecture Review
AWS, Terraform, IaC, IAM, stockage, bases de données, groupes de sécurité, pipelines Mauvaise configuration cloud ou privilèges excessifs Cloud Security Assessment
Politiques internes, seuils d’approbation, gouvernance du workflow agentique Risque non classé ou contrôles non répétables Risk Assessment
Code applicatif, API, middleware, validation, secrets, dépendances Vulnérabilités ou régressions dans le code Code Review
Web app ou API publiques générées à partir des spécifications Comportements abusables depuis l’extérieur Web Application Penetration Testing

Le choix du contrôle dépend de ce qui a réellement changé : spécification, architecture, automatisation, cloud, code ou comportement exposé. Avant la mise en ligne, il convient de délimiter ce périmètre et de vérifier le risque effectif sur le produit. Avez-vous utilisé Kiro pour transformer des exigences en conception, tâches, code ou infrastructure ? ISGroup peut vous aider à vérifier si la structure produite par l’IA contient également les contrôles de sécurité nécessaires : modèle de menace, autorisations, IaC, IAM, hooks, MCP, tests et remédiation.

Évidences à préparer avant la révision

Avant d’impliquer une équipe externe, il convient de rassembler les spécifications, les exigences EARS, la conception, les tâches, le dépôt, les diffs, les tests, les fichiers .kiro/hooks, les fichiers de pilotage, les serveurs MCP configurés, les modèles IaC, les « plan diff », les comptes ou environnements impliqués, les rôles, les données traitées et les décisions déjà prises sur les risques acceptés. Ces évidences permettent de comprendre si la sécurité est présente dans la spécification, la conception, l’implémentation et les tests, et de distinguer un problème méthodologique d’une vulnérabilité applicative ou d’une mauvaise configuration cloud.

La question finale ne devrait pas être « la spécification est-elle complète ? » dans l’abstrait, mais : quelles exigences de sécurité contient-elle, quelles menaces couvre-t-elle, quelles automatisations active-t-elle, quelles ressources crée-t-elle, quelles données expose-t-elle et quels tests démontrent que les contrôles fonctionnent même contre les abus. Kiro peut apporter de l’ordre dans le développement assisté par l’IA ; la sécurité sert à éviter que cet ordre ne facilite la mise en production d’une vulnérabilité bien documentée. Le projet développé avec Kiro a-t-il été vérifié en tant que produit exposé, ou seulement en tant que spécification cohérente ?

FAQ

  • Le développement piloté par les spécifications rend-il le code plus sûr ?
  • Il rend le processus plus explicite et traçable, mais ne garantit pas la sécurité. Si les exigences n’incluent pas l’authentification, les autorisations, le modèle de menace, les données et les tests négatifs, l’agent peut implémenter de manière ordonnée un système vulnérable.
  • Les spécifications EARS suffisent-elles à couvrir les exigences de sécurité ?
  • Non. EARS aide à rédiger des exigences claires, mais il faut inclure explicitement la sécurité, les cas d’abus, le contrôle d’accès, la gestion des erreurs, la journalisation, la confidentialité et la remédiation.
  • Les Agent Hooks sont-ils risqués ?
  • Ils sont utiles, mais deviennent risqués lorsqu’ils exécutent des commandes shell, modifient des fichiers, installent des dépendances, lancent des CLI cloud ou interagissent avec des outils externes sans approbation et journalisation adéquates.
  • Quand une Secure Architecture Review est-elle nécessaire ?
  • Lorsque Kiro a contribué à des spécifications, une conception, des frontières de confiance, des flux de données, du multi-tenant, des intégrations ou des choix architecturaux qui iront en production.
  • Quand un Cloud Security Assessment est-il nécessaire ?
  • Lorsque Kiro a généré ou modifié Terraform, CloudFormation, CDK, l’IAM, les groupes de sécurité, le stockage, les bases de données, les pipelines ou des ressources AWS.

[Callforaction-WAPT-Footer]

Sources et références utiles

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *