La seguridad del software nació en un entorno de desarrollo humano: personas escribiendo, revisando y desplegando código. Hoy, las máquinas están asumiendo gran parte de esa labor. En un trabajo reciente, Anthropic informa que más del 80% del código fusionado en su base de código de producción fue generado por su modelo de IA, Claude. Estas mismas capacidades que aumentan la productividad de los desarrolladores están cambiando la economía de los ciberataques.
Si bien los atacantes siguen definiendo el objetivo, las máquinas pueden generar payloads, testear variantes, adaptar el código a distintos entornos y repetir el proceso a una velocidad que los programas de seguridad no pueden igualar.
La Velocidad Marginaliza los Controles de Seguridad
La mayoría de los flujos de seguridad del software empresarial asumen que hay tiempo para revisar. El código se escribe, escanea, prueba, aprueba y despliega. Si surge algo sospechoso, los equipos de seguridad investigan y responden.
Ese modelo se rompe cuando el software pasa de la instrucción a la ejecución en minutos. El código generado por IA puede convertirse en un script, una dependencia, una tarea de automatización o un cambio de infraestructura casi de inmediato. Mientras los agentes de desarrollo pueden modificar archivos, resolver paquetes y ejecutar comandos, los revisores humanos quedan fuera de ciclo.
Los atacantes pueden usar las mismas mecánicas para generar exploits, probar técnicas de evasión y ajustar el comportamiento de la carga útil para distintos objetivos. Esto genera más variación con menos indicadores estables para que los defensores las reconozcan. Aunque el análisis asistido por IA puede acelerar la triage, a menudo produce probabilidad, no política. A velocidad de máquina, “probablemente sospechoso” no es suficiente.
Las Máquinas Cambian el Modelo de Ataque
Los atacantes humanos no desaparecen, pero cada vez más es la cadena de ataque la que se ejecuta en máquina. La IA puede automatizar el reconocimiento, acelerar el descubrimiento de vulnerabilidades, generar código de exploits, reescribir payloads y adaptar secuencias de comandos al entorno objetivo. Pero la mayoría de las medidas defensivas están diseñadas alrededor de limitaciones humanas: infraestructuras reutilizadas, atajos y patrones rastreables. Esto no aplica a ataques de máquina.
Un payload generado por máquina puede no coincidir con una firma conocida o tener una reputación establecida. Puede crearse, usarse brevemente y ser descartado. Pero el malware de IA aún debe interactuar con el entorno objetivo para lograr su fin. Su comportamiento no puede ocultar su intención, ya que debe acceder a recursos y cambiar el entorno para avanzar el ataque. Lo que una código malicioso es capaz de hacer es una señal de seguridad más duradera.
La Seguridad Debe Formular una Pregunta Diferente
La seguridad de la cadena de suministro de software ha avanzado, pero gran parte de ella todavía valida las propiedades del artefacto antes de la ejecución en lugar de gobernar la ejecución misma. SBOMs, firmas y procedencia brindan mayor confianza en la composición, origen y historial de compilación del código. Pero saber de dónde proviene el software no revela lo que hará cuando se ejecute.
Un artefacto puede superar cada verificación y aun así generar riesgo. Incluso un artefacto producido mediante un proceso de compilación legítimo puede violar políticas en tiempo de ejecución, mientras un script generado por IA puede completar su tarea prevista de una manera que exponga datos o sistemas. Por ello, una lista de dependencias limpia no es prueba de un comportamiento seguro.
La Detección Después de la Ejecución Es Demasiado Tarde
La detección y la respuesta siguen siendo esenciales, pero intervienen después de que el riesgo ya ingresó al entorno. Cuando el comportamiento sospechoso se vuelve visible, el software puede haber accedido a secretos, cambiado el estado del sistema, abierto conexiones de red o creado persistencia.
La IA acorta esa ventana. El código puede generarse, modificarse y desplegarse más rápido de lo que los humanos pueden revisar. Esperar evidencia post-ejecución da a los atacantes demasiado espacio para operar.
Necesitamos desplazar el punto de decisión hacia la izquierda. En lugar de preguntar: “¿Podemos contener este software si se comporta mal?”, la pregunta debería ser: “¿Debe permitirse ejecutar este comportamiento en primer lugar?”
Eso no significa reemplazar controles existentes, sino cambiar dónde se sitúa la puerta de seguridad decisiva.
Zero Trust para el Código
Zero Trust cambió la seguridad empresarial al rechazar la confianza implícita. Usuarios, dispositivos, sesiones y solicitudes de acceso no deben ser confiables solo por parecer familiares; deben verificarse frente a políticas.
La ejecución de software necesita el mismo nivel de verificación. El código no debe confiarse únicamente porque provenga de un repositorio conocido, esté firmado por un editor reconocido, haya pasado por una canal de compilación o no haya mostrado comportamientos maliciosos previamente. Esos son indicadores útiles, pero no concluyentes.
Zero Trust para el Código aborda este problema. Antes de que el software se ejecute, su comportamiento esperado debe evaluarse frente a una política. Si el comportamiento es aceptable, la ejecución puede continuar. Si no, el artefacto debe ser bloqueado, restringido, aislado o escalado para revisión.
Las organizaciones pueden empezar mapeando cada camino por el que el código entra al entorno o se ejecuta con privilegios significativos. Esto incluye canales formales de desarrollo como repositorios, paquetes de código abierto, contenedores y pipelines de CI/CD, así como adjuntos de correo electrónico, archivos descargados, macros, extensiones de navegador, instaladores de endpoints, integraciones de terceros y scripts introducidos a través de herramientas de IA o automatización.
Luego identifique dónde esos caminos dependen de la confianza heredada. Si la ejecución se permite porque el software proviene de una fuente aprobada, fue firmado, pasó por un proceso de compilación o no tiene historial malicioso, ese control está incompleto. El comportamiento aún debe evaluarse antes de permitir la ejecución del artefacto.
A medida que la IA asume más parte del trabajo de crear código legítimo y malicioso, las empresas ya no pueden asumir que un código que supera las verificaciones actuales debe ejecutarse. La ejecución debe convertirse en una decisión de seguridad deliberada.
We’ve listed the best internet security suites for PCs, Macs and mobile devices ver más.
Este artículo se produjo como parte de TechRadar Pro Perspectives, nuestro canal para presentar a las mentes más brillantes de la industria tecnológica hoy.
Las opiniones expresadas aquí son del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, descubra más aquí: https://www.techradar.com/pro/perspectives-how-to-submit
from Latest from TechRadar https://ift.tt/bneAd2q
via IFTTT IA
Pacosite's Blog 