Software house y AI coding: cómo garantizar la seguridad cuando el código es generado por agentes
Para una software house, el AI coding no es solo un tema de productividad interna: es un tema de fiabilidad hacia el cliente. Si un equipo utiliza agentes para generar código, refactorización, pruebas, pipelines o configuraciones, debe poder demostrar que la velocidad no ha eliminado las revisiones, la segregación de datos, los controles de seguridad y la responsabilidad en la entrega.
La pregunta que llega de clientes, departamentos de compras y auditorías es concreta: ¿cómo saben que el código generado o modificado con IA ha sido controlado antes de la entrega? Una respuesta creíble no puede ser “confiamos en nuestros desarrolladores” o “los escáneres están en verde”. Se necesita un programa de aseguramiento: reglas internas, evidencias, revisiones, pruebas, puertas de control (gates) en la pipeline, informes y remediación.
Por qué el riesgo es diferente para una software house
Un equipo interno puede aceptar un riesgo y gobernarlo en su propio ciclo de desarrollo. Una software house, en cambio, entrega código a terceros: el cliente, los auditores, el departamento de compras, el equipo legal y el equipo de seguridad pueden pedir pruebas en cualquier momento.
El uso de AI coding añade nuevas preguntas que no solo conciernen a la calidad técnica. ¿Qué partes han sido generadas o modificadas por agentes? ¿Qué datos del cliente se han utilizado en el prompt o en el contexto? ¿Qué dependencias se han introducido y quién ha revisado el diff? ¿Qué pruebas cubren las autorizaciones, los roles y el abuso? ¿Qué hallazgos (findings) se han corregido antes de la entrega y qué riesgos residuales se han comunicado? Si estas respuestas no existen, la software house pierde el control comercial además del técnico.
Política interna para el uso de IA en proyectos de clientes
La política debe establecer qué está permitido en los proyectos de los clientes, no solo qué es cómodo para el equipo. Debe cubrir herramientas autorizadas, cuentas corporativas, datos prohibidos, repositorios permitidos, modos de agente, terminal, agentes en la nube, herramientas externas, revisiones y gestión de excepciones. Los puntos mínimos a incluir son:
- Ninguna cuenta personal en código o datos del cliente.
- Ningún secreto, log real o dato del cliente en prompts no autorizados.
- Espacios de trabajo (workspaces) separados por cliente.
- Exclusión de archivos sensibles del contexto del agente.
- Aprobación para herramientas que lean repositorios del cliente.
- Revisión obligatoria en autenticación, API, datos, pipelines y dependencias.
- Trazabilidad de las partes generadas por IA cuando sea relevante para el contrato.
La política debe ser sencilla de aplicar: si es demasiado abstracta, cada equipo la interpretará de forma diferente y los controles perderán coherencia entre proyectos.
Segregación de los datos del cliente
El riesgo más delicado no siempre es el error en el código, sino el paso no controlado de información entre clientes, herramientas y entornos. Una software house debe separar repositorios y ramas, espacios de trabajo IDE y agentes, entornos cloud, credenciales, conjuntos de datos de prueba, logs y tickets, documentación del cliente, prompts y transcripciones cuando se conserven.
Un agente que trabaja en varios proyectos no debe tener un contexto transversal innecesario. Un conjunto de datos de un cliente no debe convertirse en una fixture reutilizada en otros proyectos, y un error de producción no debe pegarse en un chat genérico con tokens, correos electrónicos o identificadores sin redactar.
Trazabilidad: desde el prompt hasta la release
No es necesario guardar cada prompt de forma indiscriminada, pero es necesario saber qué decisiones han llevado a la release. Las evidencias útiles a conservar incluyen issues o tareas de origen, PR y commits, archivos modificados por IA, revisores y aprobaciones, escáneres y pruebas ejecutadas, nuevas dependencias, cambios en CI/CD, IaC y despliegues, hallazgos y correcciones, y los riesgos residuales aceptados.
Esta trazabilidad es útil también internamente: cuando surge una vulnerabilidad, cuando el cliente pide explicaciones o cuando una regresión reaparece en una release posterior, tener un camino documentado reduce significativamente los tiempos de respuesta.
Revisión obligatoria en las áreas sensibles
No todo el código generado por IA tiene el mismo perfil de riesgo. Una modificación de texto no requiere el mismo nivel de control que una modificación en middleware, roles, consultas, API, pipelines o pagos. Una software house debería definir las áreas que requieren siempre revisión técnica:
- Autenticación, sesiones, restablecimiento de contraseñas, MFA, OAuth.
- Autorizaciones, roles, aislamiento de inquilinos (tenant isolation), políticas y middleware.
- API, consultas, exportaciones, subidas, pagos y webhooks.
- Secretos, logs, gestión de errores y configuraciones.
- Dependencias, lockfiles, licencias, Dockerfiles.
- CI/CD, IaC, cloud, IAM y despliegues.
- Prompts de ejecución, agentes de aplicación, RAG y llamadas a herramientas.
La Code Review se convierte así en una prueba de control: no solo “hemos leído el código”, sino “hemos verificado estas áreas, con este perímetro y estos resultados”.
Pruebas y escáneres: necesarios pero no suficientes
SAST, SCA, escaneo de secretos, pruebas unitarias y pruebas de integración son necesarios, pero no demuestran por sí solos que la aplicación respete la lógica de negocio, las autorizaciones, el aislamiento de inquilinos y el abuso de roles. Para los proyectos de clientes, la pipeline debería producir al menos:
- SAST con triaje de los nuevos hallazgos.
- SCA y escaneo de licencias en manifiestos y lockfiles.
- Escaneo de secretos en repositorios, logs y artefactos.
- Pruebas negativas en roles, inquilinos, entradas y modos de fallo.
- Controles en IaC, contenedores y configuraciones.
- Evidencia de correcciones y re-pruebas.
Cuando la aplicación o las API son accesibles por usuarios, socios o Internet, es necesario verificar también el comportamiento en tiempo de ejecución. En este contexto, el Web Application Penetration Testing completa la Code Review: uno analiza la causa en el código, el otro verifica si el comportamiento expuesto es explotable en el sistema real.
Dependencias, licencias y cadena de suministro
Los agentes pueden añadir paquetes para cerrar rápidamente una funcionalidad, pero para una software house una dependencia no es solo un riesgo técnico: puede convertirse en un problema de licencia, mantenimiento, vulnerabilidades conocidas, políticas del cliente o auditorías. Cada nueva dependencia debería evaluarse respecto a la motivación, versión y lockfile, licencia compatible, estado de mantenimiento, vulnerabilidades conocidas, scripts de instalación y presencia de alternativas ya existentes en el proyecto.
Para clientes empresariales, SBOM, procedencia e informes SCA pueden convertirse en evidencias contractuales. Incluso cuando no se solicitan explícitamente, saber qué entra en la release reduce los tiempos de respuesta en caso de CVE.
Informes hacia el cliente: qué mostrar
El cliente no debe recibir una narración genérica sobre la IA, sino evidencias proporcionadas al proyecto. Un informe útil puede incluir el perímetro de la release o de la revisión, las partes generadas o modificadas con IA cuando sea relevante, los controles ejecutados con escáneres y pruebas, los hallazgos bloqueantes corregidos, los hallazgos planificables, los riesgos residuales, las nuevas dependencias, los límites del perímetro y las recomendaciones para las siguientes releases.
Esto no significa exponer cada prompt o cada detalle interno, sino hacer demostrable que el código entregado no ha sido aceptado a ciegas.
Del proyecto individual al programa de aseguramiento
El verdadero salto de calidad llega cuando los controles no dependen del project manager individual. Cada proyecto con AI coding debería tener umbrales similares, informes similares, puertas de control similares y responsabilidades claras. El Software Assurance Lifecycle sirve precisamente para esto: transformar revisiones, pruebas, pipelines, remediación y reporting en un proceso repetible en diferentes equipos y clientes.
Para una software house, esto tiene un valor comercial directo: ayuda a responder a departamentos de compras, auditorías, cuestionarios de seguridad y solicitudes de evidencias sin tener que reconstruir el proceso desde cero cada vez.
Lista de verificación para software houses que usan AI coding
- Política interna sobre el uso de IA en proyectos de clientes.
- Herramientas autorizadas, cuentas corporativas y configuraciones mínimas.
- Separación de repositorios, espacios de trabajo, datos, prompts y credenciales por cliente.
- Prohibición de insertar datos del cliente, secretos o logs sensibles en herramientas no autorizadas.
- Trazabilidad de PR, commits, revisiones, escáneres, pruebas y hallazgos.
- Revisión obligatoria en autenticación, API, datos, pipelines, cloud y dependencias.
- SAST, SCA, escaneo de secretos y pruebas negativas con umbrales definidos.
- Control de licencias y nuevas dependencias.
- Verificación de CI/CD, IaC, contenedores, despliegue y rollback.
- Informe al cliente con perímetro, evidencias, correcciones y riesgo residual.
- Remediación gestionada con propietario, severidad, SLA y re-pruebas.
Cuándo involucrar a ISGroup
Una software house puede empezar con una evaluación del proceso o con una verificación en un proyecto piloto. La elección depende del riesgo y del nivel de madurez actual.
| Escenario | Riesgo principal | Control recomendado |
|---|---|---|
| Uso de AI coding en varios equipos o clientes | Controles no repetibles y auditorías difíciles | Software Assurance Lifecycle |
| PR generadas por IA en código sensible | Vulnerabilidades o regresiones en el código | Code Review |
| Aplicación o API expuesta a usuarios/clientes | Abuso en tiempo de ejecución y vulnerabilidades de aplicación | Web Application Penetration Testing |
| El cliente solicita evidencias antes de la entrega | Perímetro y riesgo residual no demostrables | Programa de aseguramiento e informe técnico |
El valor no es solo encontrar errores: es hacer defendible el proceso de entrega, documentando qué se ha controlado, por quién, con qué evidencias y con qué límites declarados.
Preguntas frecuentes
- ¿Debe una software house declarar siempre el uso de AI coding?
- Depende del contrato, los requisitos del cliente y las políticas internas. En la práctica, conviene estar preparado para explicar qué herramientas se utilizan, qué datos se excluyen y qué controles verifican el resultado.
- ¿Debe el cliente ver los prompts?
- No necesariamente. Los prompts pueden contener información sensible. A menudo son más útiles las políticas, el perímetro, las evidencias de revisión, pruebas, escáneres, hallazgos corregidos y el riesgo residual.
- ¿Cómo demostrar que el código generado por IA ha sido controlado?
- Con evidencias concretas: PR, commits, revisiones, pruebas, informes SAST/SCA, escaneo de secretos, informe de dependencias, Code Review, WAPT, hallazgos, correcciones y re-pruebas.
- ¿Cuándo se necesita una Code Review independiente?
- Cuando el código generado o modificado con IA afecta a autenticación, roles, API, datos, consultas, secretos, dependencias, pipelines, cloud o lógica de negocio crítica.
- ¿Cuándo se necesita el WAPT además de la Code Review?
- Cuando la aplicación es accesible por usuarios o clientes. La Code Review analiza el código fuente; el WAPT verifica si el comportamiento expuesto es explotable en condiciones reales.
[Callforaction-SAL-Footer]
Leave a Reply