Modela las amenazas de un flujo de desarrollo con IA

Elige un escenario limitado

Empieza por un flujo que las personas puedan entender. Por ejemplo, un agente lee una incidencia, edita un repositorio, ejecuta pruebas y abre una pull request. Incluye los sistemas que hacen posibles esas acciones.

Enumera los activos relevantes: código fuente, información de clientes, credenciales, artefactos de publicación y disponibilidad del servicio. Identifica a sus responsables. Después, identifica qué personas y sistemas pueden leer o cambiar cada activo.

OWASP recomienda modelar el sistema, identificar amenazas, elegir respuestas y validar el resultado. Usa el método desde el principio y actualízalo cuando cambie el sistema. Guía de modelado de amenazas.

Dibuja los límites de confianza

Para el flujo ficticio que va de una incidencia a una PR, dibuja estas conexiones:

Issue → agent → repository → test runner → artifact store → deployment

Añade el proveedor del modelo y el almacén de secretos. Marca dónde llega contenido de una fuente menos fiable. Marca dónde una identidad adquiere una capacidad nueva, como pasar de leer una incidencia a escribir archivos del repositorio.

El diagrama de la aplicación por sí solo no muestra todo el riesgo del desarrollo. Una base de datos de producción puede ser privada mientras un job de CI expone una credencial. Incluye los entornos temporales y el acceso de soporte cuando afecten al escenario.

Escribe una vía concreta de fallo

Evita entradas como «la IA podría ser insegura». Escribe un actor, una acción, un activo afectado y una consecuencia. Incluye las condiciones necesarias para que ocurra el escenario.

Son ejemplos, no una lista completa de amenazas. Tus datos, herramientas y entorno operativo determinan los escenarios relevantes.

Elige una respuesta con responsable

Prioriza las consecuencias y la exposición creíble. No presentes una puntuación numérica como una precisión que no tienes. Registra la incertidumbre y las pruebas que podrían cambiar la prioridad.

Una respuesta puede eliminar la capacidad arriesgada, reducir su alcance, añadir un control o aceptar un riesgo residual definido. La aceptación necesita una persona responsable autorizada y un motivo. No debe ser una conclusión del agente sin revisar.

Convierte la respuesta elegida en trabajo con una condición de aceptación observable. «Mejora la seguridad del agente» es difícil de verificar. «El job de pruebas no puede leer el secreto de producción» define un límite comprobable.

Revisa después de cambios relevantes

Un nuevo conector, una ruta al modelo, un entorno o un permiso pueden cambiar el modelo de amenazas. Inclúyelos entre las condiciones de revisión. Usa también los incidentes y las evaluaciones fallidas para actualizar los supuestos.

Prueba el ejercicio de revisión de riesgos para cambiar los datos, los permisos, la audiencia y las condiciones de recuperación de un escenario. El resultado propone preguntas. No sustituye al modelo de amenazas de un sistema concreto ni autoriza el trabajo.