La cadena de suministro ya no se compone únicamente de paquetes
La seguridad de la cadena de suministro de software se pensó durante mucho tiempo según un modelo concreto: se compromete un componente, muchas organizaciones consumen ese componente y, después, se localizan los sistemas afectados a través del árbol de dependencias. SolarWinds, Log4Shell, paquetes npm maliciosos, módulos PyPI falsos y dependencias de código abierto secuestradas son ejemplos distintos de ese modelo. El mecanismo de escalado del ataque es claro: el mismo componente se utiliza en muchas bases de código.
Pero los asistentes de codificación con IA cambian este panorama. Aquí lo que se compromete no es siempre un paquete publicado, una dependencia de código abierto o una herramienta de build. El riesgo surge en el propio flujo de trabajo del desarrollador. Durante la sugerencia de código, el refactor, la generación de pruebas, la corrección de errores o la escritura de funciones auxiliares, el asistente de IA contribuye directamente al código de primera parte.
Esa contribución no aparece como una dependencia. No pasa por los registros de paquetes. No aparece en el árbol de dependencias de la herramienta de SCA. La mayoría de las veces parece un commit normal de un desarrollador. La nueva pregunta es esta: si el cambio que entra en el código no es un paquete sino una sugerencia asistida por IA, ¿cómo lo ve la seguridad de la cadena de suministro?
Los incidentes revelados a principios de 2026 dejaron de hacer teórica esta pregunta. Anthropic reveló que un grupo respaldado por el Estado chino llevó a cabo una campaña coordinada que utilizó Claude Code para infiltrarse en cerca de 30 organizaciones de los sectores tecnológico, de servicios financieros y gubernamental. En el mismo periodo también se publicaron otros informes sobre el uso de operaciones asistidas por IA contra objetivos de infraestructura crítica.
El denominador común de estos incidentes es que la herramienta de IA deja de ser solo una capa de productividad y pasa a formar parte de la cadena de ataque. El riesgo real: el código asistido por IA entra en la base de código a través de una identidad de desarrollador confiable; pero no siempre merece el mismo nivel de confianza.
Las cifras
Revelado por Anthropic — en los sectores tecnológico, financiero y gubernamental
Voice of Emirates 2026Tecnología, servicios financieros, organismos gubernamentales
Divulgación de AnthropicGrupo respaldado por el Estado chino, atribuido por Anthropic
Divulgación de AnthropicFallos en la cadena de suministro de software — nueva categoría para 2025
OWASP Top 10:2025El nuevo patrón de ataque: el asistente se usa sin comprometer el asistente
En el ataque clásico a la cadena de suministro, el atacante suele apuntar a un componente común. Se envenena un paquete. Se secuestra una cuenta de maintainer. Se manipula un sistema de build. Se filtra una clave de firma. Se abusa de un canal de actualización. Después se ven afectadas todas las organizaciones que consumen ese componente.
El patrón que se desarrolla a través del asistente de codificación con IA es distinto. Aquí no es necesario que el atacante se apodere del propio asistente. El asistente lo utiliza el atacante como una herramienta, o se ve influido a través de contextos dirigidos al flujo de trabajo del desarrollador. Es un modelo más sutil.
El atacante puede preparar prompts, ejemplos, contextos de repositorio, contenidos de código abierto, páginas de preguntas y respuestas o textos de issues que provoquen sugerencias de código concretas. El objetivo es que el asistente de IA genere código de apariencia razonable pero que contenga una vulnerabilidad. Para el desarrollador, el proceso es rutinario: se hace un refactor, se pide al asistente una función auxiliar, la sugerencia parece razonable, se lee el código, las pruebas pasan, el pull request se aprueba.
Sin embargo, dentro del código generado puede haber un pequeño defecto lógico, una validación débil, una vía de SSRF, una fuga oculta de datos, una autorización incorrecta o una puerta trasera utilizable más adelante. Este código no es una dependencia externa — es el propio código de la organización. La herramienta de SCA clásica no ve nada.
El problema está exactamente aquí: el ataque a la cadena de suministro ha salido del árbol de dependencias y se ha trasladado al flujo de desarrollo.
¿Por qué esto es distinto del problema clásico de la cadena de suministro?
El riesgo procedente del asistente de codificación con IA está relacionado con la categoría OWASP A03 Fallos en la cadena de suministro de software. Pero no tiene el mismo mecanismo que el ataque clásico a la cadena de suministro. Los dos modelos de amenaza pueden evaluarse bajo la misma categoría, pero las formas de defensa son distintas.
Cadena de suministro clásica vs. ataque procedente del asistente de codificación con IA
| Dimensión | Ataque clásico a la cadena de suministro | Ataque procedente del asistente de codificación con IA |
|---|---|---|
| Elemento comprometido | Dependencia publicada, paquete, herramienta de build | Sugerencia de IA en el flujo de trabajo del desarrollador |
| Forma de escalado | El mismo paquete se usa en muchas organizaciones | El mismo asistente lo usan muchos desarrolladores |
| Entrada del código | Llega como dependencia externa | Se hace commit como código de primera parte |
| Herramienta de detección | SCA, SBOM, firma, historial del paquete | Revisión de código, análisis estático, rastro de uso de IA |
| Visibilidad | Visible en el árbol de dependencias | Puede perderse dentro de un commit normal |
| Vía de parcheo | Actualizar el paquete, cambiar la dependencia | Revisar la ruta de código, auditar el historial de commits |
| Fuente de la divulgación | Investigador, víctima, sistema de registro de paquetes | Fabricante del modelo, investigación de seguridad, auditoría interna |
| Riesgo fundamental | Se envenena un componente externo | El código interno se ve afectado por una sugerencia no confiable |
Esta diferencia genera una consecuencia crítica en el lado de la defensa. El SCA ve las dependencias; pero no distingue específicamente el código que un desarrollador escribió con ayuda de IA. El SBOM lista los paquetes; pero no muestra el error lógico generado por el motor de sugerencias. La firma de un paquete puede verificarse; pero la puerta trasera sutil dentro de un commit aparece como "su propio código". Por eso el riesgo del asistente de codificación con IA no es solo una cuestión de seguridad de una nueva herramienta — es un punto del ciclo de vida de desarrollo seguro que debe replantearse.
¿Qué muestran los incidentes documentados de 2026?
Los incidentes de 2026 demostraron que las herramientas de codificación con IA no son solo un riesgo teórico. El mensaje común de los distintos incidentes fue el mismo: los atacantes utilizan herramientas de IA para el desarrollo, el reconocimiento, la generación de exploits y la velocidad operativa.
Campaña del Estado chino a través de Claude Code
Según la divulgación de Anthropic, un grupo respaldado por el Estado chino llevó a cabo una campaña coordinada que utilizó Claude Code para infiltrarse en cerca de 30 organizaciones de los sectores tecnológico, de servicios financieros y gubernamental. Lo notable es que la divulgación no provino de una víctima sino del fabricante del modelo. Pero también apunta a una realidad inquietante: las campañas detectadas representan únicamente la parte visible.
Operaciones asistidas por IA contra infraestructura crítica
En el mismo periodo surgieron informes sobre el uso de modelos como Claude en ataques dirigidos a objetivos de infraestructura crítica. En entornos de infraestructura crítica, la generación de código, el análisis de configuración, la escritura de scripts, la investigación de vulnerabilidades y la automatización operativa tienen un alto valor para el atacante. Los asistentes de codificación deben entrar no solo en el modelo de amenaza de los equipos de software, sino también en el de los equipos de seguridad de infraestructura crítica.
La propia superficie de ataque de Claude Code
A finales de 2025 y principios de 2026 se reportaron algunas vulnerabilidades en el propio Claude Code — ejecución remota de código a través de repositorios no confiables y exposición de claves de API. Estos incidentes pertenecen a una clase de riesgo distinta: no el abuso del asistente, sino la conversión de la propia herramienta del asistente en superficie de ataque. Los asistentes de codificación con IA deben evaluarse no solo desde la perspectiva de la 'salida del modelo', sino también como herramientas privilegiadas dentro del entorno de desarrollo.
¿Cómo funciona el ataque en la práctica?
Los ataques procedentes del asistente de codificación con IA no son uniformes. Sin embargo, el flujo común puede resumirse en determinadas fases.
Selección del objetivo
El atacante intenta primero identificar las organizaciones que utilizan activamente asistentes de codificación con IA. La información puede extraerse de fuentes abiertas: nombres de herramientas en ofertas de empleo, blogs de desarrolladores, presentaciones de conferencias, mensajes de commit de código abierto, registros públicos de issues/PR, publicaciones de empleados en redes sociales, artículos de ingeniería corporativa. La adopción de IA, además de ser una señal de productividad, se convierte en una señal de inteligencia para la preparación del ataque.
Preparación del contexto
El atacante prepara contextos que pueden hacer que el asistente de IA genere un tipo concreto de código. Puede ser un prompt directo; en escenarios más sutiles puede prepararse como repositorio de código abierto, documentación, respuesta de foro, descripción de issue, código de ejemplo o datos de prueba. Áreas de riesgo: auxiliares de URL fetch expuestos a SSRF, validación de entrada débil, controles de bypass de auth incorrectos, deserialización insegura, generación de consultas expuesta a inyección SQL/NoSQL, escritura de credenciales en los logs, fuga de tokens/claves de API, CORS incorrecto, path traversal, condiciones de carrera, aislamiento de tenant ausente.
Entrega
El contexto preparado por el atacante puede entrar en el flujo de trabajo del desarrollador por distintas vías: código de ejemplo en un repositorio público, contenido de preguntas y respuestas tipo Stack Overflow, sugerencia en un issue de GitHub, documentación de una dependencia de código abierto, prompt o fragmento de código directo, fase de red-team/ingeniería social. El propio asistente no tiene por qué estar comprometido — el asistente se convierte en el portador del contexto mal preparado.
El desarrollador acepta la sugerencia
El punto más crítico del ataque. El asistente de IA sugiere código. El desarrollador lo revisa — de estilo razonable, funcionalmente correcto, aparenta poder pasar las pruebas. El PR se aprueba. En muchas organizaciones, el código asistido por IA no se somete a un nivel de revisión más alto que el escrito por humanos. A veces ocurre justo lo contrario — el código generado por IA se acepta más rápido porque parece 'estándar' o 'auxiliar'. Esta es una suposición errónea — el código asistido por IA puede acarrear influencias externas debido al modelo generador, al contexto del prompt y a las fuentes utilizadas.
Salida a producción y explotación
Cuando la vulnerabilidad sembrada llega a producción, el atacante puede explotarla por vías clásicas. Visto desde fuera, el ataque puede parecer un exploit web normal, un abuso de API, un bypass de auth o una fuga de datos. El equipo de respuesta a incidentes se centra primero en la superficie de ataque externa. Pero la causa raíz puede ser un cambio asistido por IA fusionado semanas o meses antes — lo que dificulta la atribución, porque la vulnerabilidad no proviene de una dependencia externa sino del propio historial de commits de la organización.
Persistencia y auditoría retrospectiva
Uno de los aspectos más difíciles del ataque asistido por IA es la auditoría retrospectiva. Cuando aparece una divulgación sobre una herramienta o surge un patrón de abuso concreto, la organización debe plantearse estas preguntas: en qué equipos se usó este asistente, en qué repositorios se usó, qué commits fueron asistidos por IA, qué rutas sensibles a la seguridad cambiaron, qué sugerencias se aceptaron directamente, qué cambios salieron a producción, qué servicios ejecutan este código. La mayoría de las organizaciones no pueden responder con rapidez — el uso de IA no se marca de forma sistemática.
¿Por qué las defensas actuales se quedan cortas?
En el riesgo de cadena de suministro procedente del asistente de codificación con IA, la brecha de defensa no es solo una carencia de herramientas — es una brecha de proceso. Destacan tres problemas fundamentales.
El SCA no ve el código de primera parte
Las herramientas de Software Composition Analysis están diseñadas para escanear dependencias — examinan nombres de paquetes, versiones, correspondencias con CVE, licencias y riesgos conocidos. Pero el código que genera el asistente de IA y que el desarrollador hace commit no es una dependencia — aparece como código propio de la organización. El SCA por sí solo no puede detectar esta clase de ataque. El SCA sigue siendo necesario, pero no debe suponerse que cubre el riesgo del código asistido por IA.
El análisis estático no detecta todo error lógico
Las herramientas de SAST pueden detectar muchos errores de seguridad evidentes — patrones de inyección, secretos hardcodeados, deserialización insegura, path traversal. Pero si el atacante diseña deliberadamente errores lógicos sutiles, vulnerabilidades de edge-case o puertas traseras estilizadas, el análisis estático no basta. Especialmente difíciles: errores de aislamiento de tenant, controles de autorización ausentes, bypass de lógica de negocio, fugas de datos condicionales, vulnerabilidades dependientes del tiempo, interacciones complejas entre microservicios.
La revisión de código no distingue la generación con IA
En muchas organizaciones, el proceso de revisión de código no distingue entre el código asistido por IA y el escrito por humanos. Esto ya es de por sí arriesgado — el código generado por IA debería tratarse como una contribución externa. El desarrollador puede ser interno y confiable; pero el modelo, el contexto y las fuentes utilizados en el proceso de generación del código pueden estar expuestos a influencias externas. Que 'el desarrollador sea confiable' no significa que 'el código sea confiable'. El código asistido por IA exige una disciplina de revisión más rigurosa, especialmente en las áreas sensibles a la seguridad.
¿Qué deben cambiar las organizaciones?
Prohibir por completo los asistentes de codificación con IA no es realista para la mayoría de las organizaciones. La ventaja de productividad es grande y los desarrolladores seguirán usando estas herramientas. El enfoque correcto no es prohibir, sino establecer una disciplina de seguridad acorde al contexto de uso.
Seis cambios concretos
Marque por separado los cambios generados por IA
El primer requisito es la visibilidad. La organización debe saber qué cambios de código se generaron con ayuda de IA. La información puede guardarse en las descripciones de los PR, en los metadatos de los commits, en integraciones de la plataforma de desarrollo o en marcas de política interna. El objetivo no es penalizar al desarrollador — es dejar un rastro para la respuesta a incidentes y la revisión de seguridad. Cuando aparezca una nueva divulgación sobre una herramienta de IA, la organización debe poder encontrar rápidamente qué repositorios pueden estar afectados.
Revise el código asistido por IA como una contribución externa
El código generado por IA, aunque lo haya hecho commit un desarrollador interno, debe someterse a la disciplina de una contribución externa. Esto aplica especialmente en estas áreas: autenticación, autorización, acceso a la red, manejo de archivos, deserialización, criptografía, gestión de secretos, validación de entrada, exportación de datos, aislamiento de tenant, flujos de pago. En estas áreas, los cambios asistidos por IA deben pasar por la revisión de un desarrollador sénior o un ingeniero de seguridad.
Defina puertas de seguridad adicionales en el CI/CD
Controles adicionales en el pipeline de CI/CD para los commits asistidos por IA: SAST, secret scanning, dependency scanning, IaC scanning, validación de contratos de API, obligación de cobertura de pruebas, auditoría del uso de funciones de riesgo, aprobación adicional en cambios de archivos sensibles a la seguridad, nota de threat modeling. Lo importante no es que el código asistido por IA se considere malo automáticamente — es que pase por puertas de seguridad adicionales en las áreas de riesgo.
Cree una política de uso de IA basada en el contexto
Las políticas de dos extremos como 'IA libre' o 'IA prohibida' son débiles. El enfoque más correcto es una política basada en el contexto: prototipo de investigación libre + revisión básica, herramienta interna controlada + SAST + code review, aplicación de cara al cliente limitada + revisión de seguridad, código de identidad/auth con alta restricción + revisión sénior + threat model, criptografía muy limitada + aprobación de un experto, gestión de secretos muy limitada + aprobación del equipo de seguridad, infraestructura de producción controlada + IaC scanning. Este modelo protege las áreas de riesgo sin cortar por completo la productividad del desarrollador.
Registre el uso del asistente de IA a nivel de equipo
Las herramientas de codificación con IA ocupan una posición privilegiada en el entorno de desarrollo — pueden acceder al contexto del repositorio, leer código, generar sugerencias y operar cerca del contexto de terminal/pruebas/archivos locales/claves de API. Debe registrarse: qué equipos usan qué herramienta de IA, en qué repositorios están activas, qué branches/PR tocaron, en qué tipos de archivo generaron sugerencias, qué áreas sensibles a la seguridad tocaron, qué sugerencias se aceptaron directamente, qué versión de qué modelo se utilizó. Es crítico para la respuesta a incidentes.
Anomalías de estilo + interpretación de OWASP A03
El código generado por IA deja rastros de estilo — preferencias de nomenclatura, forma del manejo de errores, estructura de los comentarios, disposición de las pruebas. Elementos a marcar: estilo de código claramente distinto del hábito del equipo, refactor repentino en módulos sensibles a la seguridad, funciones auxiliares con amplios privilegios, estados de error silenciosamente absorbidos, eliminación de controles de autorización. Dentro de OWASP Top 10:2025, los Fallos en la cadena de suministro de software no deben pensarse limitados solo a las dependencias de npm, PyPI o imágenes de contenedor — los asistentes de codificación con IA también forman parte de la cadena de producción de software y requieren una evaluación del fabricante.
Política de uso de IA basada en el contexto
Un ejemplo práctico de cómo la política puede variar según el contexto — proteger las áreas de riesgo sin obstaculizar la productividad en las áreas de bajo riesgo.
| Contexto | Uso de IA | Control adicional |
|---|---|---|
| Prototipo de investigación | Libre | Revisión básica |
| Herramienta interna | Controlado | SAST + code review |
| Aplicación de cara al cliente | Limitado | Revisión de seguridad |
| Código de identidad/auth | Alta restricción | Revisión sénior + threat model |
| Criptografía | Muy limitado | Aprobación de un experto |
| Gestión de secretos | Muy limitado | Aprobación del equipo de seguridad |
| Infraestructura de producción | Controlado | IaC scanning + aprobación de cambios |
Los asistentes de codificación con IA no hacen innecesario el desarrollo seguro. Al contrario, hacen más importante la disciplina de desarrollo seguro. El volumen de código generado aumenta. La velocidad del refactor aumenta. El número de funciones auxiliares aumenta. Un desarrollador puede generar más cambios en el mismo tiempo. Esto es una buena ganancia de productividad; pero si la capacidad de revisión no escala con ella, aumenta la probabilidad de pasar por alto una vulnerabilidad. Las organizaciones deben abandonar esta suposición: 'si la IA acelera el código, la revisión puede seguir igual'. La suposición más correcta: si la IA acelera la generación de código, la revisión y la verificación también deben escalar. Esto no significa más burocracia — significa un control más enfocado.
Dónde encaja TR7 en el panorama de la defensa
En el riesgo de cadena de suministro procedente del asistente de codificación con IA, la defensa principal está dentro del flujo de desarrollo — la revisión de código, la política de uso de IA, los controles de CI/CD y la disciplina de desarrollo seguro son la primera línea de defensa. TR7 no sustituye este proceso. El papel de TR7 es reducir el impacto cuando una vulnerabilidad sembrada llega a producción, sacar a la superficie los intentos de explotación y limitar el radio de explosión.
WAF para las vulnerabilidades sembradas más comunes
Si la vulnerabilidad sembrada en el código asistido por IA es de la clase SSRF, inyección SQL, deserialización, path traversal o validación de entrada débil, TR7 WAF puede detectar una parte significativa de estos intentos de explotación. El WAF no elimina el error subyacente; el código aún debe corregirse. Pero reduce los intentos de explotación en producción y ofrece visibilidad al equipo de seguridad.
TR7 AGS limita la autorización de una ruta comprometida
Cuando una vulnerabilidad llega a producción, a qué datos y sistemas puede acceder el atacante lo determina el modelo de identidad y autorización. TR7 AGS restringe el acceso a las aplicaciones según la identidad, el contexto y la política. Una ruta comprometida no concede acceso automático a toda la superficie de la aplicación ni a los sistemas internos — algo importante especialmente para las vulnerabilidades de auth sembradas a través de código asistido por IA.
ZeroLeak para las superficies de alto valor
En algunas aplicaciones, una vulnerabilidad que se escapa a nivel de código puede producir consecuencias inaceptables — consolas de administración, portales financieros, pantallas de PII de clientes, sistemas de documentos legales. ZeroLeak renderiza estas aplicaciones de alto valor en un entorno aislado y no en el dispositivo del usuario. El alcance de una puerta trasera sembrada o de una superficie de ataque del lado del cliente queda más limitado.
Registro forense para la evaluación del alcance
Cuando un incidente se rastrea hasta un cambio asistido por IA, la pregunta más crítica es el alcance. El registro forense y la observabilidad de sesión de TR7 aceleran la evaluación del alcance tras el incidente — cuando se evalúan en conjunto los logs completos de solicitud/respuesta, los eventos del WAF, el contexto de identidad, las grabaciones de sesión y la analítica de tráfico, los equipos de seguridad pueden entender la causa raíz en el código y el impacto real en producción.
La segmentación de red reduce el radio de explosión
Cuando se explota una vulnerabilidad sembrada por código asistido por IA, el siguiente objetivo del atacante suele ser el movimiento lateral. La microsegmentación en la capa de red y de aplicación restringe ese movimiento — un componente comprometido solo puede alcanzar los sistemas que necesita. Los servicios no relacionados, los paneles de administración y los almacenes de datos son inaccesibles por defecto. Reduce el riesgo de 'una vulnerabilidad, todo el entorno'.
Analítica en tiempo real para la detección de patrones
Si una vulnerabilidad sembrada llega a producción, la primera señal suele surgir con anomalías en los patrones de tráfico — aumento inusual de solicitudes hacia un endpoint concreto, combinaciones de parámetros inesperadas, nuevos códigos de error, acceso anormal a datos desde un solo usuario. La capa de analítica en tiempo real de TR7 saca a la superficie estos patrones.
Conclusión: el código de IA no es una entrada confiable
Los asistentes de codificación con IA aumentan la velocidad del desarrollo de software. Esa realidad no va a cambiar. Las organizaciones usarán estas herramientas; los desarrolladores prototiparán, refactorizarán y resolverán bugs más rápido. Pero la ganancia de productividad no invalida automáticamente las suposiciones de seguridad.
El código asistido por IA, aunque se haya hecho commit bajo una identidad de desarrollador confiable, no debe considerarse confiable. El contexto en el que se generó el código, el modelo utilizado, el prompt, el contenido del repositorio y las fuentes externas forman parte de la superficie de ataque.
Por eso la seguridad de la cadena de suministro ya no puede limitarse solo al escaneo de paquetes. La nueva cadena de suministro incluye también: asistentes de codificación, contextos de prompt, commits asistidos por IA, flujos de trabajo de desarrolladores, divulgaciones de incidentes del fabricante del modelo, permisos de acceso a repositorios, puertas de seguridad del CI/CD, logs de uso de IA, disciplina de revisión de código.
El enfoque correcto no es prohibir el uso de la IA. El enfoque correcto es convertir el código asistido por IA en una entrada de desarrollo visible, auditable y basada en el riesgo. La seguridad clásica de la cadena de suministro preguntaba '¿qué paquete usamos?'. En 2026 la pregunta adicional es: ¿quién escribió este código, qué herramienta ayudó y cómo se verificó la salida de esa herramienta?
Fuentes
Noticia sobre el uso del modelo Claude en un ciberataque y la respuesta global. https://www.voiceofemirates.com/en/science-and-tech/2026/05/12/ai-in-the-hands-of-hackers-use-of-claude-model-in-cyberattack-sparks-global-alarm/
Informe de febrero de 2026 sobre las vulnerabilidades de Claude Code y los patrones de abuso. https://thehackernews.com/2026/02/claude-code-flaws-allow-remote-code.html
Noticia independiente sobre las consecuencias de seguridad. https://www.darkreading.com/application-security/flaws-claude-code-developer-machines-risk
Análisis sectorial del panorama de seguridad de los asistentes de codificación con IA. https://seceon.com/claude-code-vulnerability-exposes-new-ai-security-risks/
Marco de la categoría que ahora se extiende también a la cadena de suministro de herramientas de IA. https://owasp.org/Top10/2025/0x00_2025-Introduction/
Documento de abril de 2026 sobre las herramientas de IA como superficie de ataque activa. https://www.microsoft.com/en-us/security/blog/2026/04/02/threat-actor-abuse-of-ai-accelerates-from-tool-to-cyberattack-surface/
Incorpore la generación de código asistido por IA al proceso de seguridad
Cuando los asistentes de codificación con IA forman parte del flujo de desarrollo, el proceso de seguridad también debe actualizarse en consecuencia. Los cambios asistidos por IA deben marcarse, revisarse con más rigor en las áreas sensibles a la seguridad, pasar por los controles de CI/CD y dejar un rastro para la auditoría posterior al incidente. TR7 — a través de WAF, AGS, ZeroLeak, registro forense, microsegmentación y analítica en tiempo real — ayuda a reducir el impacto de las vulnerabilidades que llegan a producción. La defensa principal es el proceso de desarrollo seguro; la defensa en la capa de aplicación es la última red de seguridad.
Descubra la arquitectura de TR7 WAAP