El entusiasmo de los inversores por la IA ha impulsado la expectativa de que esta mejorará drásticamente el desarrollo de software, la automatización y las operaciones de ciberseguridad.
La IA ya ha transformado la forma en que se crea el software, cómo se generan los ataques y la velocidad a la que ambos se propagan por las empresas. También ha elevado las expectativas para los equipos de defensa: análisis más rápidos, una mejor priorización y una toma de decisiones más automatizada.
Sin embargo, cuando tanto los atacantes como los desarrolladores operan a velocidad de máquina, la prevención depende menos de predicciones más inteligentes y más de decisiones claras y aplicables basadas en la intención.
La seguridad probabilística no es suficiente.
La mayoría de las herramientas de seguridad, especialmente aquellas que incorporan aprendizaje automático o grandes modelos de lenguaje, son probabilísticas por diseño. Generan probabilidades: este archivo es probablemente malicioso, este comportamiento parece sospechoso, esta actividad tiene una alta probabilidad de ser un ataque.
Esto funciona bien para la clasificación inicial (*triage*) y la investigación. Ayuda a los analistas a filtrar el ruido, priorizar alertas e identificar patrones que de otro modo pasarían desapercibidos. No obstante, esas fortalezas no se traducen necesariamente en decisiones de aplicación fiables.
Es posible que un sistema probabilístico no siempre proporcione el nivel de certeza necesario para determinar si un artefacto de software debe ejecutarse en un entorno de producción.
Los atacantes generan ahora código polimórfico de un solo uso. Por su parte, los desarrolladores dependen cada vez más de la automatización, las dependencias de código abierto y los componentes generados por IA que avanzan por las tuberías de despliegue (*pipelines*) sin intervención humana. En ambos casos, el volumen y la velocidad del software superan los límites del juicio humano y la fiabilidad de las puntuaciones probabilísticas.
El resultado suele ser una brecha entre la identificación del riesgo y su prevención.
Si las decisiones de seguridad no pueden tomarse con suficiente confianza en el momento de la ejecución, deben basarse en algo más estable que la probabilidad y aplicarse antes de que el código se ejecute. Esta es la base del enfoque de «Zero Trust for Code» (Confianza Cero para el Código), en el que no se confía en la ejecución del software hasta que su comportamiento se evalúa frente a una política establecida.
La necesidad de controles de seguridad explicables.
A medida que el software se vuelve más autónomo, las decisiones de seguridad también deben ser más precisas y fiables. Ya no basta con detectar anomalías o asignar puntuaciones de riesgo. Las decisiones deben ser explicables, repetibles y auditables. Los equipos de seguridad necesitan entender por qué se permitió o bloqueó un artefacto, si ese mismo artefacto produciría el mismo resultado mañana y si dicha decisión puede defenderse en un contexto de cumplimiento normativo o de análisis de incidentes.
Los modelos probabilísticos tienen dificultades en estos tres aspectos. Esto no significa que los sistemas probabilísticos sean ineficaces. Muchos programas de seguridad modernos combinan análisis predictivos con controles basados en políticas, empleando cada uno donde resulta más eficaz.
Incluso pequeñas variaciones en los datos de entrada o en el estado del modelo pueden generar resultados diferentes. Dicha variabilidad es aceptable cuando se trata de asistir a los analistas, pero no cuando se debe determinar si se permite la ejecución de código en un entorno regulado. Este riesgo se acentúa en las cadenas de suministro de software, donde las decisiones de confianza afectan no solo a un sistema, sino también a las dependencias posteriores, a los entornos de producción y a los datos de los clientes.
Incidentes recientes han puesto esto de manifiesto. En el caso de la vulneración de la cadena de suministro de LiteLLM, un paquete de Python ampliamente utilizado fue modificado brevemente para recopilar credenciales y establecer persistencia en los entornos de desarrollo. Las versiones maliciosas estuvieron disponibles solo durante unas pocas horas, pero eso fue suficiente.
El fallo no residió en la detección, sino en los tiempos y en la confianza. Para cuando se pudieron generar las alertas, el código ya se había ejecutado, los secretos habían quedado expuestos y los mecanismos de persistencia ya estaban establecidos. Un modelo probabilístico podría señalar ese comportamiento a posteriori, pero no puede revertir la decisión de ejecución.
Nada de esto resta valor a la IA en el ámbito de la seguridad. Esta destaca por su capacidad para identificar patrones en grandes conjuntos de datos, correlacionar señales, agilizar investigaciones, facilitar el análisis de causas raíz y reducir la carga de trabajo manual.
Si se utiliza correctamente, la IA puede mejorar significativamente la visibilidad y la respuesta, además de ayudar a los analistas a comprender qué acciones podría realizar el código. Sin embargo, no debería ser la autoridad definitiva a la hora de decidir si se permite la ejecución de dicho código; esa responsabilidad requiere controles deterministas basados en políticas.
Pasar de la detección a la prevención.
En lugar de preguntarse si algo es probablemente malicioso, el análisis determinista de la intención conductual se centra en qué es capaz de hacer un software y si dicho comportamiento cumple con las políticas establecidas.
El malware generado por IA puede mutar indefinidamente, modificando hashes, cadenas de texto y estructuras según sea necesario; no obstante, su intención no cambia al mismo ritmo que su apariencia. Esto se debe a que no puede alcanzar su objetivo sin llevar a cabo ciertas categorías de acciones, como acceder a datos confidenciales, modificar el estado del sistema, establecer persistencia o comunicarse con el exterior. Dichos objetivos conductuales suelen permanecer constantes, incluso cuando cambia el código subyacente.
Este es el núcleo operativo de *Zero Trust for Code* (Confianza Cero para el Código): evaluar las capacidades del software antes de su ejecución y aplicar una decisión de política coherente. Al analizar el comportamiento previo a la ejecución, las organizaciones pueden permitir el software que se ajusta a las políticas, bloquear aquel que infringe las restricciones definidas y aislar o escalar los casos que requieran una revisión más exhaustiva.
Lo más importante es que estas decisiones están diseñadas para ser coherentes. Al evaluarse bajo las mismas políticas y condiciones, los artefactos de software deben generar resultados predecibles que puedan revisarse y auditarse. Esa coherencia es lo que permite una prevención fiable. También transforma el papel de los controles de seguridad: en lugar de reaccionar ante eventos de ejecución, pasan a actuar como guardianes de la propia ejecución.
La IA no solo está perfeccionando los ataques, sino que también está acortando los plazos. Los sistemas autónomos pueden procesar dependencias, desplegar servicios e iniciar acciones sin intervención humana. En este entorno, la prevención debe producirse antes de la ejecución, no después.
*Zero Trust for Code* prioriza la aplicación de políticas junto con el análisis predictivo, basando las decisiones de seguridad en si se debe permitir o no la ejecución de un artefacto de software. De este modo, convierte la ejecución en un punto de control regido por políticas.
A medida que la IA acelera la creación y el despliegue de software, las organizaciones necesitarán modelos de seguridad capaces de seguir el ritmo sin sacrificar la rendición de cuentas. Es poco probable que el futuro implique elegir entre la IA y los controles deterministas; más bien, se tratará de una combinación de análisis inteligente y políticas aplicables que permita a las organizaciones avanzar con rapidez manteniendo la confianza.
