Tenemos un año para arreglar la seguridad en todas partes
Los avances en los modelos de lenguaje grandes están intensificando el temor de que pronto las herramientas automatizadas puedan encontrar y explotar vulnerabilidades de software a escala, convirtiendo la postura de seguridad ya frágil de hoy en un entorno mucho más peligroso. Los comentaristas debaten si las respuestas tradicionales —parches, lenguajes seguros frente a la memoria y verificación formal— pueden seguir el ritmo, o si se necesitan cambios más profundos, como sistemas basados en microkernels, reducción agresiva de dependencias, infraestructura crítica aislada y una regulación más estricta. Muchos también ven usos defensivos sólidos para la IA, pero sostienen que los incentivos, la gobernanza y la complejidad del mundo real hacen poco probable que las defensas avancen tan rápido o se desplieguen tan ampliamente como los nuevos ataques automatizados.
Los LLM como aceleradores de la seguridad ofensiva
- Varios comentaristas informan que los LLM encuentran vulnerabilidades reales en minutos cuando se les apunta a bases de código en producción.
- Preocupa que los modelos locales baratos y sin censura hagan viables los “ataques de for-loop”: explorar logs de CT, repos de altcoins, stacks de comercio electrónico, etc.
- Temor de que la “larga cola” de errores oscuros en software y electrodomésticos empresariales se vuelva explotable a escala.
- Algunos creen que el plazo de “un año” es demasiado generoso; otros señalan que llevamos décadas en un modo similar de “última oportunidad para arreglar la seguridad”.
Usos defensivos y sus límites
- Los LLM pueden ayudar con fuzzing, pruebas de propiedades, revisión de código y pruebas formales, pero los defensores se enfrentan a fricción organizativa: aprobaciones, pruebas, parches de proveedores.
- Asimetría: los atacantes necesitan un solo exploit exitoso; los defensores deben gestionar todos los riesgos de forma continua.
- Se sugiere que la “seguridad básica” futura podría mejorar una vez que los LLM hayan eliminado el fruto al alcance de la mano.
Sistemas, modelos de SO y superficie de ataque
- Fuerte defensa de los microkernels, los sistemas de capacidades, los air-gaps, los diodos de datos y la minimización del código de confianza; Linux/Windows se ven como fundamentalmente demasiado grandes y basados en autoridad ambiental.
- Otros enfatizan el endurecimiento práctico de lo que existe: defensa en profundidad, sandboxing, zero trust, listas blancas de aplicaciones, exposición estricta a la red.
Web, CMS y expansión de dependencias
- WordPress, plataformas de comercio electrónico y plugins/módulos son ejemplos frecuentes de seguridad frágil; muchos recomiendan sitios estáticos o enfoques de “headless CMS”.
- Objeciones: los usuarios no técnicos dependen de plataformas ricas; las herramientas estáticas/JAMstack y los flujos de trabajo centrados en Git todavía no cubren sus necesidades.
Lenguajes, mitigaciones de hardware y C/C++
- Muchos respaldan lenguajes seguros frente a la memoria y funciones de hardware como el memory tagging; otros argumentan que la adopción es demasiado lenta.
- Debate recurrente entre “no escribas C/C++ nuevos” y “C/C++ están bien si tienes cuidado”; se elogia RAII en C++, pero se critica la complejidad del lenguaje y las trampas heredadas.
Regulación, incentivos y cultura del riesgo
- Observación frecuente: las brechas rara vez tienen consecuencias serias, así que las empresas optimizan para auditorías y cumplimiento de casillas, no para una resiliencia real.
- Algunos piden notificación obligatoria de brechas y responsabilidad, similar a la auditoría financiera; otros señalan la dificultad práctica de detectar e informar todas las brechas.
Riesgos más amplios de la IA y la sociedad
- El hilo deriva hacia preocupaciones sobre ingeniería social habilitada por IA, riesgos biológicos, terrorismo y escenarios de “gran filtro”/ASI, con un fuerte desacuerdo sobre cuán realistas o inminentes son.