ISGroup Consultoría de Ciberseguridad

AWS Kiro y desarrollo basado en especificaciones: estructura, seguridad y verificaciones antes del go-live

AWS Kiro y el desarrollo basado en especificaciones: más estructura no significa automáticamente más seguridad

Kiro satisface una necesidad real de los equipos que han experimentado el “vibe coding”: menos caos, más contexto, especificaciones más legibles, tareas más ordenadas y documentación más cercana al código. El desarrollo basado en especificaciones (spec-driven development) aporta una disciplina útil en el desarrollo asistido por IA, especialmente cuando el proyecto deja de ser una demo y se convierte en una función, un servicio, una plataforma interna o una aplicación destinada a usuarios reales.

[Callforaction-WAPT]

El punto crítico es no confundir estructura con seguridad. Una especificación bien redactada puede describir una arquitectura vulnerable. Un requisito en EARS puede ser formalmente claro y no decir nada sobre el aislamiento de inquilinos (tenant isolation), la escalada de privilegios, la gestión de secretos o el abuso de las API. Un plan de implementación puede estar ordenado y cubrir solo el camino feliz (happy path). Antes del despliegue, la pregunta útil no es si Kiro hace que el código esté más organizado, sino si los requisitos, el diseño, las tareas, los hooks, MCP, las pruebas y la implementación contienen controles de seguridad suficientes para conectar datos reales, usuarios, API, nube y sistemas empresariales.

Qué mejora el desarrollo basado en especificaciones y qué no cubre

Kiro lleva al equipo de prompts naturales a requisitos estructurados, diseño y tareas ejecutables, reduciendo parte del riesgo típico del “vibe coding”: decisiones implícitas, documentación no actualizada, funciones generadas de forma improvisada y difíciles de mantener. La estructura, sin embargo, no garantiza que los requisitos sean los correctos. Si una especificación no incluye roles, datos sensibles, autorizaciones a nivel de objeto, límites de tasa (rate limits), registros (logs), retención, límites de confianza (trust boundaries), gestión de errores y casos de abuso, el agente puede implementar de forma coherente un producto incompleto desde el punto de vista de la seguridad.

Lo mismo ocurre con las pruebas. Un plan bien generado puede verificar que el usuario logre completar el flujo previsto, pero esto no demuestra que un usuario de otro inquilino no pueda leer el mismo registro, que una API no acepte ID arbitrarios, que una política IAM no sea demasiado amplia o que un hook no ejecute comandos no revisados.

El riesgo de la especificación perfecta pero incompleta

Las especificaciones ayudan a hacer explícita la intención, pero si esa intención inicial no incluye seguridad, privacidad y abuso, el resultado sigue siendo frágil. Una frase como “el usuario puede visualizar sus propios documentos” debe volverse verificable: qué documentos, con qué identidad, con qué roles, qué sucede si cambia el ID, qué sucede con un token caducado, qué sucede si un administrador de un inquilino intenta leer otro inquilino.

Kiro puede ayudar a transformar requisitos en tareas, pero la calidad del resultado depende de la calidad de los requisitos mismos. Por eso, cada especificación destinada a una función expuesta debería incluir criterios de aceptación negativos: acceso denegado, entrada rechazada, archivo no autorizado, rol insuficiente, inquilino incorrecto, token caducado, callback no permitida en la lista blanca, secreto no registrado. Una especificación que no dice nada sobre lo que debe bloquearse deja demasiado espacio a la implementación del agente, con el riesgo de producir una documentación tranquilizadora que muestra lo que la aplicación debe hacer, pero no lo que no debe permitir.

Threat modeling dentro del proceso basado en especificaciones

El modelado de amenazas (threat modeling) no debe convertirse en un documento pesado separado del desarrollo. En un flujo de trabajo con Kiro, puede integrarse en la fase de requisitos y diseño, cubriendo activos, actores, límites de confianza, datos sensibles, sistemas externos, privilegios, flujos y modos de falla. Para cada especificación, el equipo debería preguntarse qué datos se procesan, qué roles existen, qué acciones son sensibles, qué API son públicas, qué sistemas externos se llaman, qué secretos son necesarios y qué comandos o recursos en la nube se verán afectados. Si la aplicación es multi-inquilino, el aislamiento de inquilinos debe ser un requisito de primer nivel, no una nota de implementación.

El diseño generado o asistido por Kiro debe leerse también con una pregunta ofensiva: ¿cómo podría ser abusado? ¿Se puede reutilizar un flujo de invitación? ¿Puede un restablecimiento de contraseña revelar usuarios? ¿Está realmente protegida una ruta de administración en el lado del servidor? ¿Puede una carga de archivos (upload) servir contenido activo? ¿Crea una tarea de IaC recursos accesibles desde internet?

Agent Hooks: automatización útil, superficie a gobernar

Los Agent Hooks son uno de los elementos más específicos de Kiro. Pueden activarse en eventos como el envío de prompts, la detención del agente, el uso de herramientas (pre/post tool use), la creación o guardado de archivos, la eliminación de archivos, la ejecución de tareas y disparadores manuales, con acciones que incluyen prompts al agente o comandos de shell. Esta automatización puede ser muy útil para formatear código, actualizar documentación, generar pruebas, verificar estándares, bloquear herramientas o enriquecer el contexto. Sin embargo, puede convertirse en una superficie crítica si ejecuta comandos, modifica archivos, instala dependencias, lanza pruebas, interactúa con CLI en la nube o cambia configuraciones sin revisión.

Antes de adoptar hooks en un equipo, conviene hacer un inventario de los archivos .kiro/hooks, de los eventos que los activan, de las acciones ejecutadas y de los permisos disponibles en el repositorio. Los comandos de shell deben tratarse como código operativo: quién los aprueba, qué pueden leer, qué pueden escribir, qué variables de entorno ven, si pueden ejecutar despliegues, eliminaciones, migraciones o comandos en la nube. Un hook que se ejecuta al guardar un archivo no debería poder aplicar Terraform, eliminar recursos, instalar paquetes no aprobados o enviar datos sensibles a sistemas externos. Las automatizaciones de alto impacto deben tener umbrales, registros y aprobación separada.

Steering files y reglas de proyecto

Kiro permite guiar a los agentes con archivos de dirección (steering files) y reglas de proyecto, haciendo explícitas las convenciones, estándares y preferencias. Aquí también, sin embargo, las instrucciones persistentes se convierten en parte del perímetro de seguridad. Una regla que empuja al agente a “hacer pasar las pruebas”, “usar mocks cuando falten servicios”, “simplificar la autenticación” o “proceder aunque el contexto esté incompleto” puede normalizar atajos riesgosos. Por el contrario, reglas bien escritas pueden impedir modificaciones en la autenticación sin pruebas negativas, bloquear secretos en el frontend, requerir revisión en IAM/IaC e imponer una política de denegación por defecto (default deny).

Los steering files deben revisarse como código. Deben separar estilo, arquitectura y seguridad, evitar secretos y endpoints internos innecesarios, y no contener instrucciones ambiguas. Cada modificación a estos archivos debería pasar por una revisión de PR (Pull Request), porque influye en todas las tareas futuras.

MCP, herramientas externas y contexto de la especificación

Kiro admite MCP y puede conectarse a documentación, bases de datos, API, herramientas de AWS, Terraform u otros sistemas, aumentando mucho la calidad del contexto pero ampliando también los límites de confianza del flujo de trabajo. Si un servidor MCP da acceso a bases de datos, tickets, repositorios, nube, documentación interna o registro de Terraform, el agente puede incorporar esa información en la especificación y en las decisiones de implementación. El riesgo no es MCP en sí, sino el uso de herramientas y credenciales demasiado amplias: tokens compartidos, permisos de lectura-escritura cuando basta con solo lectura, acceso a datos reales durante el diseño, herramientas de despliegue disponibles en fases no controladas.

La gobernanza de MCP para Kiro debería incluir listas blancas de servidores, tokens dedicados, privilegios mínimos, separación entre proyecto y configuraciones globales, auditoría de las llamadas a herramientas y desactivación de herramientas innecesarias en repositorios críticos. Si se utilizan herramientas de AWS o Terraform, las modificaciones resultantes deben pasar por una revisión de IaC y aprobación antes de su aplicación.

Terraform, IaC y nube: cuando la especificación crea infraestructura

Uno de los escenarios más delicados es usar Kiro para diseñar o generar infraestructura: Terraform, CloudFormation, CDK, grupos de seguridad, IAM, VPC, bases de datos, almacenamiento, balanceadores de carga, tuberías (pipelines). La especificación puede hacer que el trabajo sea ordenado, pero el riesgo en la nube sigue siendo concreto. Una especificación que pide “crear un entorno para la aplicación” puede llevar a grupos de seguridad abiertos, buckets públicos, roles IAM genéricos, bases de datos alcanzables, salidas con secretos, entornos de desarrollo/producción poco separados, ausencia de cifrado, registro o copias de seguridad. El resultado puede ser coherente con la solicitud y, aun así, no ser aceptable en producción.

Antes de aplicar IaC generada o modificada con Kiro, se necesitan diffs de planes, escáneres de IaC, revisión manual, control de privilegios mínimos, etiquetado, separación de entornos, planes de reversión y aprobación explícita en recursos críticos. La aplicación de la IaC no debe ser un efecto secundario de una tarea del agente o de un hook.

Pruebas generadas: funcionales, no necesariamente ofensivas

Kiro puede ayudar a generar pruebas vinculadas a los requisitos, pero las pruebas derivadas de la especificación tienden a verificar que el sistema haga lo que se solicitó. La seguridad requiere también demostrar que el sistema rechace lo que no debe permitir. Para cada función expuesta, se necesitan pruebas negativas: usuario no autenticado, rol insuficiente, inquilino incorrecto, objeto de otro usuario, entrada maliciosa, archivo no válido, solicitud fuera de secuencia, token caducado, límite de tasa, callback no permitida, error controlado. Si estos casos no entran en la especificación, difícilmente el agente los cubrirá de forma robusta.

Las pruebas automáticas deben ir acompañadas de revisiones de código (Code Review) y, cuando la aplicación o API estén en línea, de un WAPT manual. Las vulnerabilidades más graves a menudo no son errores sintácticos, sino incoherencias entre requisitos, implementación y comportamiento real.

Desviación (drift) entre especificación, implementación y documentación

Una de las ventajas del desarrollo basado en especificaciones es mantener unidos la intención, el diseño y la implementación. El riesgo es creer que esta trazabilidad es automática y siempre correcta. Durante el desarrollo, el agente puede descubrir que la especificación está incompleta y modificar la implementación; el desarrollador puede aceptar una solución alternativa (workaround) sin actualizar los requisitos y el diseño; un hook puede actualizar documentación que describe lo que debería suceder, no lo que el código aplica realmente. La especificación puede mantenerse ordenada y volverse falsa.

Para las áreas de seguridad, la trazabilidad debe verificarse: cada requisito de control de acceso debe tener implementación, prueba positiva, prueba negativa y responsable. Cada límite de confianza debe tener controles en el diseño y en el código. Cada excepción aceptada debe tener una motivación y una remediación.

Fatiga de permisos y aprobaciones

Kiro puede introducir muchos puntos de aprobación: tareas, hooks, uso de herramientas, comandos de shell, MCP, modificaciones de archivos, pruebas, PR, IaC. Si todo requiere el mismo nivel de atención, el equipo corre el riesgo de sufrir fatiga de permisos y termina aceptando automáticamente. La solución no es bloquear todo, sino clasificar el riesgo. El formato, la documentación y la refactorización local pueden tener un camino ligero, mientras que la autenticación, IAM, secretos, API públicas, bases de datos, almacenamiento, migraciones, despliegues, eliminaciones, Terraform y CLI en la nube deben tener aprobaciones más fuertes y revisores competentes. Esta distinción debe decidirse antes de que Kiro entre en el flujo de trabajo de producción, porque si la regla se improvisa durante una versión urgente, el equipo tenderá a privilegiar la velocidad.

Lista de verificación de Kiro antes de la puesta en marcha (go-live)

Especificaciones y diseño

  • Relee los requisitos EARS y verifica que incluyan seguridad, roles, datos, autorizaciones, aislamiento de inquilinos, registro, manejo de errores, retención y casos de abuso.
  • Añade criterios de aceptación negativos para lo que debe ser rechazado.
  • Vincula cada requisito crítico al diseño, tareas, código y pruebas.

Hooks, dirección y MCP

  • Haz un inventario de .kiro/hooks, disparadores, comandos de shell, acciones de prompt y herramientas involucradas.
  • Revisa los steering files como código.
  • Censa servidores MCP, tokens, privilegios, datos accesibles y herramientas disponibles.
  • Desactiva lo que no sea necesario en repositorios críticos.

Código, API y pruebas

  • Realiza una revisión de código sobre autenticación, middleware, API, validación, lógica de negocio, manejo de errores, secretos y dependencias.
  • Integra pruebas negativas sobre roles, inquilinos, IDOR/BOLA, entradas maliciosas, sesiones, cargas de archivos y límites de tasa.
  • Si la aplicación está expuesta, planifica un WAPT en el entorno real.

Nube, IaC y producción

  • Revisa Terraform, CloudFormation, CDK, grupos de seguridad, IAM, almacenamiento, bases de datos, redes, tuberías y secretos antes de aplicar.
  • Verifica el principio de menor privilegio, separación de entornos, registro, copias de seguridad, reversión y aprobaciones.
  • Ningún comando de despliegue o destrucción debería ser un efecto automático de un hook o tarea sin control.

Cuándo basta una revisión interna y cuándo se necesita una verificación independiente

Una revisión interna puede bastar si Kiro se utiliza para especificaciones o refactorizaciones no expuestas, sin datos reales, sin IaC, sin API públicas y sin automatizaciones de alto impacto. En cambio, se necesita una verificación independiente cuando las especificaciones guían funciones con datos reales, roles, inquilinos, pagos, integraciones, API públicas, IaC, AWS, Terraform, MCP o hooks que ejecutan comandos, o cuando el equipo quiere adoptar Kiro de forma continua y debe definir políticas, umbrales de revisión, responsabilidades y controles repetibles.

El punto no es ralentizar a Kiro, sino separar lo que puede acelerarse de lo que debe validarse: requisitos, límites de confianza, automatizaciones, herramientas, nube, código y comportamiento real.

Cómo ISGroup puede verificar un proyecto desarrollado con Kiro

El control cambia según lo que Kiro haya estructurado, generado o automatizado. Si el riesgo está en los requisitos, en el modelo de amenazas o en las decisiones arquitectónicas, la Secure Architecture Review ayuda a validar el diseño, los límites de confianza y los flujos de datos. Si el riesgo se refiere a AWS, Terraform, IAM, grupos de seguridad, almacenamiento o tuberías, el Cloud Security Assessment verifica configuraciones y privilegios. Si el objetivo es gobernar la adopción, las políticas y los umbrales de revisión, el Risk Assessment ayuda a definir prioridades y responsabilidades.

Si Kiro ha tocado… Riesgo principal Control recomendado
Especificaciones, requisitos, diseño, límites de confianza, flujos de datos Suposiciones arquitectónicas débiles Secure Architecture Review
AWS, Terraform, IaC, IAM, almacenamiento, bases de datos, grupos de seguridad, tuberías Configuración errónea en la nube o privilegios excesivos Cloud Security Assessment
Políticas internas, umbrales de aprobación, gobernanza del flujo de trabajo del agente Riesgo no clasificado o controles no repetibles Risk Assessment
Código de aplicación, API, middleware, validación, secretos, dependencias Vulnerabilidades o regresiones en el código Code Review
Aplicaciones web o API públicas generadas a partir de las especificaciones Comportamientos abusables desde el exterior Web Application Penetration Testing

La elección del control depende de lo que realmente ha cambiado: especificación, arquitectura, automatización, nube, código o comportamiento expuesto. Antes de la puesta en marcha, conviene delimitar ese perímetro y verificar el riesgo efectivo en el producto. ¿Has usado Kiro para transformar requisitos en diseño, tareas, código o infraestructura? ISGroup puede ayudarte a verificar si la estructura producida por la IA contiene también los controles de seguridad necesarios: modelo de amenazas, autorizaciones, IaC, IAM, hooks, MCP, pruebas y remediación.

Evidencias a preparar antes de la revisión

Antes de involucrar a un equipo externo, conviene recopilar especificaciones, requisitos EARS, diseño, tareas, repositorio, diffs, pruebas, archivos .kiro/hooks, steering files, servidores MCP configurados, plantillas de IaC, diffs de planes, cuentas o entornos involucrados, roles, datos procesados y decisiones ya tomadas sobre riesgos aceptados. Estas evidencias permiten entender si la seguridad está presente en la especificación, en el diseño, en la implementación y en las pruebas, y distinguir un problema metodológico de una vulnerabilidad de la aplicación o de una configuración errónea en la nube.

La pregunta final no debería ser “¿la especificación está completa?” en abstracto, sino: qué requisitos de seguridad contiene, qué amenazas cubre, qué automatizaciones habilita, qué recursos crea, qué datos expone y qué pruebas demuestran que los controles funcionan incluso contra el abuso. Kiro puede aportar orden en el desarrollo asistido por IA; la seguridad sirve para evitar que ese orden haga más fácil llevar a producción una vulnerabilidad bien documentada. ¿El proyecto desarrollado con Kiro ha sido verificado como producto expuesto, o solo como especificación coherente?

FAQ

  • ¿El desarrollo basado en especificaciones hace que el código sea más seguro?
  • Hace que el proceso sea más explícito y rastreable, pero no garantiza la seguridad. Si los requisitos no incluyen autenticación, autorizaciones, modelo de amenazas, datos y pruebas negativas, el agente puede implementar de forma ordenada un sistema vulnerable.
  • ¿Las especificaciones EARS bastan para cubrir los requisitos de seguridad?
  • No. EARS ayuda a escribir requisitos claros, pero hay que incluir explícitamente seguridad, casos de abuso, control de acceso, manejo de errores, registro, privacidad y remediación.
  • ¿Son riesgosos los Agent Hooks?
  • Son útiles, pero se vuelven riesgosos cuando ejecutan comandos de shell, modifican archivos, instalan dependencias, lanzan CLI en la nube o interactúan con herramientas externas sin aprobación y registro adecuados.
  • ¿Cuándo se necesita una Secure Architecture Review?
  • Cuando Kiro ha contribuido a especificaciones, diseño, límites de confianza, flujos de datos, multi-inquilino, integraciones o decisiones arquitectónicas que irán a producción.
  • ¿Cuándo se necesita un Cloud Security Assessment?
  • Cuando Kiro ha generado o modificado Terraform, CloudFormation, CDK, IAM, grupos de seguridad, almacenamiento, bases de datos, tuberías o recursos de AWS.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

In

, , ,