Los programas de IA maliciosos están obligando a extender el principio de confianza cero al código.

La seguridad del software siempre se ha basado en el desarrollo humano. Antes, los humanos escribían, revisaban y publicaban el código. Ahora, las máquinas se encargan de estas tareas.

En un reciente estudio, Anthropic informó que más del 80% del código integrado en su base de datos de productividad es obra de su modelo de IA , Cloud.

Las mismas capacidades que aumentan la productividad de los desarrolladores están cambiando la economía de los ciberataques.

Mientras los adversarios aún están identificando el objetivo, las máquinas pueden generar cargas útiles maliciosas, probar variantes, adaptar el código a diferentes entornos y repetir el proceso a una velocidad que el software de seguridad no puede seguir.

La velocidad anula los controles de seguridad.

La mayoría de los flujos de trabajo de seguridad de software empresarial presuponen un período de revisión. El código se escribe, se revisa, se prueba, se aprueba y se implementa. Si posteriormente ocurre algo sospechoso, los equipos de seguridad investigan y actúan en consecuencia.

Este modelo falla cuando el programa pasa de ser una simple guía a una ejecución en cuestión de minutos.

El código generado por IA se puede transformar casi instantáneamente en scripts, dependencias, tareas de automatización o cambios de infraestructura. Mientras tanto, los agentes de desarrollo pueden modificar archivos, resolver paquetes y ejecutar comandos.

Los revisores humanos ya no forman parte del proceso.

Los atacantes pueden usar los mismos mecanismos para generar vulnerabilidades, probar técnicas de evasión y modificar el comportamiento de las cargas maliciosas para diferentes objetivos. Esto genera una mayor versatilidad con menos indicadores estables que los defensores puedan identificar.

Si bien el análisis impulsado por IA puede mejorar la detección, a menudo produce probabilidades, no políticas. Y a la velocidad de las máquinas, un simple "probablemente sospechoso" no es suficiente. Por lo tanto, la necesidad de reglas y marcos de gobernanza para la IA se está volviendo cada vez más urgente.

Las máquinas están cambiando el modelo de ataque.

Los atacantes humanos no desaparecerán, pero una parte mayor de la cadena de ataque ahora la llevan a cabo las máquinas.

La inteligencia artificial puede automatizar el reconocimiento, acelerar el descubrimiento de vulnerabilidades, generar código de explotación, reescribir cargas útiles maliciosas y adaptar secuencias de comandos al entorno objetivo. Sin embargo, la mayoría de las medidas de defensa se basan en las limitaciones humanas: infraestructura reutilizada, atajos y patrones rastreables. Estas limitaciones no se aplican a los ataques de máquinas.

La carga maliciosa generada por la máquina puede no coincidir con una firma conocida ni tener una reputación bien establecida. Puede crearse, usarse brevemente y luego desecharse. Pero el malware impulsado por IA debe interactuar con el entorno objetivo para lograr su objetivo. Su comportamiento no puede ocultar su intención; debe acceder a los recursos y alterar el entorno de forma que impulse el ataque.

Lo que puede hacer un código malicioso es crear la señal de seguridad más duradera.

El departamento de seguridad debe plantearse una pregunta diferente.

La seguridad en la cadena de suministro de software ha mejorado, pero gran parte de ella todavía se centra en comprobar las características de impacto antes de la ejecución, en lugar de controlar la ejecución en sí misma.

Las listas de componentes de software (SBOM), las firmas y el código fuente brindan a los equipos de seguridad mayor confianza en la composición, el origen y la fecha de compilación del código. Sin embargo, conocer el código fuente no revela qué hará el programa al ejecutarse.

Un programa puede superar todas estas comprobaciones y aun así generar riesgos. Incluso un proceso de compilación legítimo podría infringir las políticas durante su ejecución, mientras que un script generado por IA podría completar su tarea de forma que comprometa datos o sistemas. Por consiguiente, una lista de dependencias impecable no garantiza un comportamiento seguro, lo que subraya la importancia de no comprometer los estándares de programación, incluso con herramientas de IA.

La divulgación de la información tras la implementación llega demasiado tarde.

La detección y la respuesta siguen siendo necesarias, pero intervienen después de que la amenaza ya se ha infiltrado en el entorno. Para cuando se detecta un comportamiento sospechoso, el malware puede haber accedido a información confidencial, alterado el estado del sistema, abierto conexiones de red o establecido puntos de continuidad.

La inteligencia artificial reduce significativamente este plazo. El código se puede crear, modificar e implementar mucho más rápido de lo que los humanos pueden revisarlo. Esperar a que surjan pruebas posteriores a la ejecución les da a los atacantes un amplio margen de maniobra.

Necesitamos adelantar el proceso de toma de decisiones. En lugar de preguntarnos: "¿Podemos controlar este software si funciona mal?", deberíamos preguntarnos: "¿Deberíamos permitir que este comportamiento ocurra en primer lugar?".

Esto no significa reemplazar los controles existentes, sino cambiar la ubicación de la puerta de seguridad crítica.

Confianza cero en las instrucciones de programación

El principio de Confianza Cero ha transformado la seguridad organizacional al rechazar la confianza implícita. Los usuarios, dispositivos, sesiones y solicitudes de acceso no son confiables simplemente porque parezcan familiares; todos deben verificarse conforme a las políticas establecidas.

La implementación del software requiere el mismo nivel de verificación.

No se debe confiar en un código simplemente porque provenga de un repositorio conocido, esté firmado por un editor reconocido, haya pasado por un proceso de compilación o no haya mostrado previamente un comportamiento malicioso. Estos son indicadores útiles, pero no concluyentes.

El principio de Confianza Cero para el Código aborda este problema. Antes de que se ejecute cualquier programa, su comportamiento esperado debe evaluarse en función de las políticas establecidas. Si el comportamiento es aceptable, la ejecución puede continuar. De lo contrario, el elemento debe bloquearse, restringirse, ponerse en cuarentena o remitirse para su revisión. Esta necesidad subraya la importancia de establecer reglas y marcos claros para la inteligencia artificial que vayan más allá de las meras políticas.

Las organizaciones pueden comenzar definiendo cada vía por la que el código ingresa al entorno o se ejecuta con privilegios significativos. Esto incluye canales de desarrollo formales como repositorios, paquetes de código abierto, contenedores y canalizaciones de integración continua/despliegue continuo (CI/CD), así como archivos adjuntos de correo electrónico, archivos descargados, macros, extensiones de navegador, instaladores de punto final, integraciones de terceros y scripts inyectados mediante herramientas de IA o automatización.

A continuación, es crucial identificar dónde estas vías dependen de la confianza heredada. Si se permite la ejecución porque el software proviene de una fuente confiable, fue firmado, se sometió a un proceso de compilación o no tiene antecedentes maliciosos, este control es incompleto. Aún es necesario evaluar el comportamiento antes de permitir la ejecución del elemento. Esto también pone de relieve la vulnerabilidad derivada de la creciente dependencia de los proveedores de IA.

A medida que la inteligencia artificial asume una mayor responsabilidad en la creación de código, tanto legítimo como malicioso, las organizaciones ya no pueden dar por sentado que el código que supera las comprobaciones actuales debe ejecutarse sin problemas. La implementación debe convertirse en una decisión de seguridad bien meditada.

Hemos recopilado las mejores suites de seguridad de Internet para PC, Mac y dispositivos móviles.