Cerrar el código no frena a la IA que caza vulnerabilidades. Auditar primero, sí.
Cuando una startup en pleno crecimiento cerró su código para esquivar a los atacantes con IA, interpretó mal la amenaza. El peligro del que se escondía tiene poco que ver con quién puede leer el código fuente y mucho con el código que nadie ha auditado nunca. Ese razonamiento es lo que probablemente se extienda.
Una suposición silenciosa sostiene la mayoría de los parques de software: como no ha pasado nada malo, el código debe de estar bien. Dos demostraciones de la última década deberían jubilar esa idea. En 2016, el Cyber Grand Challenge de DARPA subió a siete sistemas autónomos a un escenario de DEF CON y les hizo encontrar, demostrar y parchear vulnerabilidades en binarios compilados, sin código fuente y sin ningún humano en el bucle. Ocho años después, en noviembre de 2024, el agente Big Sleep de Google encontró un fallo de seguridad de memoria inédito y explotable en SQLite, el primero de este tipo hallado por un agente de IA en software real, según sus propios investigadores. Ninguno de los dos resultados es una nota de prensa sobre lo que podría llegar: los dos ya han pasado.
Lo que sigue a partir de aquí es una predicción, y la marco como tal. El coste de apuntar esta capacidad hacia código antiguo y nunca auditado se está desplomando hacia cero. Aplicaciones web heredadas, routers que ya no se pueden parchear, firmware de dispositivos IoT, controladores industriales, hasta microcódigo: todo lo que lleva años funcionando sin que nadie tuviera motivos para mirarlo. Ahora mirar sale barato, y una década de riesgo acumulado y nunca examinado empieza a parecer algo que un atacante motivado puede resolver en días, no en años.
El primer reflejo visible ha sido replantear la propia transparencia como el peligro. Si los atacantes pueden apuntar un modelo a cualquier repositorio público y cosechar fallos a escala, razona el argumento, entonces la visibilidad es la superficie de ataque, así que toca bajar la persiana. Cal.com hizo exactamente eso: cerró su código comercial después de que su consejero delegado argumentara que los atacantes con IA explotan la transparencia del código fuente. De momento parece un caso aislado más que una tendencia. El pánico es comprensible, pero el daño está en el razonamiento, porque es el razonamiento, no la empresa en concreto, lo que otros negocios están a punto de copiar.
¿Ocultar el código fuente protege frente a los atacantes con IA?
Empecemos por el mecanismo. Un atacante necesita comportamiento que pueda sondear, y el código fuente es solo la vía más rápida para entender ese comportamiento. Los binarios cerrados se descompilan. Las imágenes de firmware se desmontan y se emulan. Los fuzzers lanzan millones de entradas malformadas contra un servicio en marcha y anotan qué se rompe, sin ver jamás una línea de código fuente. La investigación de vulnerabilidades es anterior al software libre y pasó décadas trabajando a ciegas contra sistemas propietarios, así que lo que cambia la IA es el alcance de ese oficio antiguo: lo extiende de lleno hacia los binarios y el firmware, no solo hacia los repositorios públicos.
Concedamos la parte honesta del argumento a favor del código cerrado, porque existe de verdad: la opacidad sí eleva el coste del atacante en el margen. Leer el código fuente es más rápido y más limpio que reconstruir la lógica a partir de un descompilador o inferirla de un montón de fallos de fuzzing, así que, para un bypass de autenticación o una vía de inyección, retirar el código fuente sí compra una prima de tiempo genuina. Dos cosas estropean el trato. Esa prima se sigue reduciendo a medida que los modelos mejoran en el análisis de binarios y firmware, justamente la frontera que ya marcó el Cyber Grand Challenge de DARPA en 2016, cuando su sistema ganador trabajó directamente sobre binarios compilados sin código fuente alguno. Y esa prima se paga expulsando a los investigadores amistosos que podrían haber llegado al fallo antes que un atacante, lo que significa que el retraso comprado es precisamente el bien que más sobra en un parque de software ya sin parchear.
Cerrar el código elimina una comodidad para el atacante y renuncia a algo real para el defensor: los muchos ojos. El código abierto es código auditable, y en cuanto el auditor puede ser un modelo trabajando a escala, el valor defensivo de un código legible sube en lugar de bajar. El trato cierra un pasivo que ya se estaba reduciendo y abre uno que crece.
La variable sobre la que todos discuten, la visibilidad, no es la exposición en absoluto. La exposición es que ese código nunca se auditó. Un repositorio privado lleno de fallos sin examinar es casi tan vulnerable como uno público, salvo por la posibilidad de que un investigador amistoso llegue al fallo antes que uno hostil.
La capacidad es simétrica: la velocidad es la única ventaja
Aquí está la parte incómoda. La detección de vulnerabilidades asistida por IA no distingue de qué bando la ejecuta. El mismo modelo que descubre el fallo en el árbol de dependencias de una empresa lo descubre para quien lo apunte allí primero, así que el panorama estratégico se reduce a una sola palanca: el tiempo. La ventaja duradera pertenece a quien audite primero un sistema, porque el primer escaneo competente convierte un riesgo desconocido en un parche o en un exploit, según quién tenga las manos en el teclado cuando llegue.
Por eso esperar es la opción cara. Tratar la auditoría adversarial con IA como algo que se compra en el próximo ciclo presupuestario da por hecho, en silencio, que el adversario sigue el mismo calendario, y no es así. La postura que funciona es lanzar la auditoría sobre el propio código, las propias dependencias y los propios dispositivos conectados ahora mismo, asumiendo que alguien más puede hacerlo y acabará haciéndolo. Ayudamos a nuestros clientes a integrar justamente este tipo de garantía supervisada por humanos en el diseño y la operación de los sistemas agénticos, porque la defensa la hace la auditoría, y ninguna política sobre el código fuente la sustituye.
¿Y si no se puede auditar todo?
Auditar primero da por hecho que se puede, y muchas organizaciones no pueden. Si una empresa tiene cuatrocientas imágenes de firmware que nunca va a reconstruir, o una flota de dispositivos cuyos fabricantes ya no existen, una carrera que se decide por tiempo es una carrera que se pierde en algunos frentes antes incluso de empezar, y fingir lo contrario es como se financia el teatro de la seguridad.
Así que hay que priorizar con honestidad. Ordenar por alcance multiplicado por radio de impacto, no por lo incómodo que resulte un sistema determinado. Todo lo que da a internet, o que está a un salto de la autenticación, va al principio de la cola, porque es justo ahí donde llega primero el escaneo de un atacante. Para el resto, lo que no se puede parchear, hay que abandonar la idea de que parchear es el único control disponible: aislar esos dispositivos en segmentos que no lleguen a internet ni a los sistemas críticos, filtrar su tráfico de salida e instrumentarlos, de modo que un exploit que no se puede evitar sea, al menos, uno que se puede ver. Algunas de estas carreras se van a perder, así que conviene financiar la detección y la respuesta que decidirán cuánto cuesta realmente perderlas. Donde se pueda ir primero, la auditoría gana sin discusión; donde no, la contención y la vigilancia cargan con el peso, y un honesto «no hemos podido auditar esto» debería activar un control compensatorio, no un encogimiento de hombros.
Por qué no se puede fijar el precio con la nota de prensa de un proveedor
Nada de esto significa tragarse el marketing entero. Los proveedores ya publicitan cuántos fallos fundamentales ha encontrado un modelo afinado para seguridad, y esas cifras son, hoy por hoy, casi imposibles de verificar. Cuando Anthropic habló de los supuestos hallazgos de su modelo, solo pudo revelar una fracción, porque la mayoría de los fallos seguían sin parchear, lo que hace muy difícil la confirmación independiente. Una cifra de titular no dice cuánto trabajo hizo el modelo y cuánto los humanos que lo dirigían, ni si los fallos eran reales, novedosos o realmente alcanzables. Lo que hay que pedir es una metodología, una muestra reproducible de los hallazgos y pruebas de que fue el modelo, y no el analista, quien hizo el descubrimiento. Quien fije el precio de la capacidad a partir del folleto está pagando por una historia, una cautela que conviene aplicar a cualquier propuesta de IA de seguridad que llegue este año.
Cómo es realmente el parque de software
La avalancha de vulnerabilidades críticas no va a repartirse por igual. Se va a concentrar en los sistemas que nadie quiere tocar: el firmware de un dispositivo que salió en 2014 y nunca recibirá una actualización, el servicio interno cuyo autor se fue hace tres reorganizaciones, la dependencia enterrada seis niveles por debajo en un lockfile. Los equipos de ingeniería, ya adelgazados por el mismo ajuste de costes que dejó huérfanos esos sistemas, heredan una brecha de auditoría cada vez más ancha y con menos manos para cerrarla.
El problema en sí no es nuevo, lo único que ha cambiado es el precio. Los fallos latentes siempre han estado años sin tocarse hasta que un investigador los volvió prácticos, como cuando Dan Kaminsky convirtió debilidades ya conocidas de envenenamiento de caché DNS en un ataque demostrablemente práctico contra muchas implementaciones a la vez. Lo que la IA le hace a ese proceso de descubrimiento es lo que la cadena de montaje le hizo a la fabricación: lo industrializa.
Quitando de en medio el debate entre código abierto y cerrado, la instrucción es sencilla. Conviene hacer inventario de todo lo que corre en la organización, firmware y dependencias incluidos, por mucho que nadie los haya leído nunca. Hay que apuntar el mismo tipo de herramientas que usaría un atacante hacia el propio parque, bajo control humano, y corregir lo que aparezca antes de que otro lo publique. El debate entre abierto y cerrado es una discusión de política que se puede tener con calma; la auditoría es la parte que decide si la empresa sigue en pie. Conviene integrarla ya en la estrategia tecnológica, mientras encontrar los propios fallos primero siga siendo una ventaja al alcance de la mano.
Preguntas frecuentes
¿Es el código abierto menos seguro que el cerrado ahora que la IA puede escanearlo?
No, al menos no de forma directa. Los atacantes pueden seguir extrayendo vulnerabilidades de binarios y firmware cerrados mediante descompilación, fuzzing y emulación, así que ocultar el código fuente eleva su coste y compra tiempo, no elimina la exposición. La exposición es el código sin auditar, y el código abierto al menos mantiene ese código legible para las herramientas defensivas y los investigadores que podrían llegar antes al fallo.
¿Cómo se empieza una auditoría de seguridad de código con IA en la propia organización?
Por un inventario que incluya las dependencias y el firmware de cualquier dispositivo conectado, porque ahí es donde se concentran los fallos nunca tocados. Después, hay que lanzar detección de vulnerabilidades adversarial contra el propio parque bajo supervisión humana, priorizando los sistemas expuestos a internet y los cercanos a la autenticación, y tratar cualquier hallazgo como algo que corregir antes de que se divulgue en otro sitio. Cuando un sistema realmente no se pueda parchear, toca contenerlo y vigilarlo.
¿Se puede confiar en la cifra que da un proveedor sobre cuántos fallos ha encontrado su modelo de seguridad?
No solo con la cifra de titular. Muchos de esos totales son imposibles de verificar y no se puede atribuir el mérito al modelo frente a los investigadores que lo dirigieron. Antes de fijar el precio de la capacidad conviene pedir una metodología reproducible, una muestra de los hallazgos reales y pruebas de que el descubrimiento lo hizo el modelo.
Relacionado
- La prima de la soberanía: por qué las soluciones de IA soberana para empresas ganan por acceso, no por velocidad
- Washington ha puesto a su propio laboratorio de IA en una lista de riesgos. Así cambia el concepto de dependencia de un proveedor de IA
- Por qué los pilotos de IA empresarial no escalan: es un problema de confianza, no de capacidad
- Security & Trust
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.