Mythos: cuando un modelo encuentra bugs de hace 27 años

Un modelo de Anthropic encontró bugs de seguridad que llevaban 27 años sin descubrirse en OpenBSD.

También encontró fallas en FFmpeg — una librería de video que corre en miles de millones de dispositivos.

Me crucé esta semana con la nota del equipo Frontier Red Team de Anthropic sobre Mythos, el modelo que están probando dentro de Project Glasswing. La descripción pública dice que lo están aplicando sobre software crítico, abierto y cerrado, y que los primeros hallazgos que se hicieron públicos vienen del lado del código abierto.

Y los está encontrando.

Lo que me hizo pensar de esto no es la noticia en sí. Es lo que implica para alguien que, como yo, no viene del mundo de la seguridad ofensiva sino del de marketing y negocio.

Cómo era encontrar un día cero hasta hace poco

Hasta ahora, encontrar un día cero en código maduro era trabajo de equipos de élite con años de oficio. Investigadores que se especializan en una librería, leen su código durante meses, prueban hipótesis, vuelven a leer.

Un trabajo lento, caro, con cuello de botella humano. Cada bug encontrado representaba semanas de tiempo experto. Esa lentitud era, en los hechos, parte del modelo de seguridad del software libre: lo que era difícil de auditar también era difícil de explotar.

Qué cambia si esto se sostiene

Si un modelo puede correr ese ciclo a otra escala, dos cosas cambian a la vez.

Por el lado defensivo, bugs que llevaban décadas escondidos pueden salir a la luz y parchearse antes de ser explotados. Es buena noticia para todo el stack que corre encima de librerías como OpenBSD o FFmpeg — y eso es prácticamente todo lo que usamos a diario.

Por el lado ofensivo, la misma capacidad puesta en manos de un actor malicioso encuentra los mismos bugs antes de que se reporten. Y los explota.

La carrera entre ataque y defensa cambia de velocidad cuando un modelo puede correr el ciclo completo en horas, no en años. No estoy diciendo que ya estamos ahí — estoy diciendo que el techo de lo que parecía posible se movió.

Por qué lo escribo desde marketing y no desde seguridad

No soy investigador de seguridad. Soy CMO. Pero también soy de los que decide qué software corre en la empresa, qué proveedores entran al stack, qué plazos de parcheo aceptamos, qué riesgo asumimos cuando elegimos una librería gratuita y maduras versus una solución comercial.

Hasta hace poco, esa conversación con el área de IT tenía un ritmo. Las CVE salían, se priorizaban, se parchaban. Había una cadencia razonable que dejaba tiempo para planificar.

Si la velocidad de descubrimiento se acelera, esa cadencia se acorta. Las preguntas que un CMO o un CIO le hacen al stack — ¿de dónde vienen estas dependencias? ¿quién las mantiene? ¿qué pasa el día que aparezca un CVE crítico un viernes a la tarde? — pasan de ser una conversación de fondo a una conversación de mesa de directorio.

Y eso aplica tanto para LATAM como para cualquier otro mercado. No hay un open source de primer mundo y otro de segundo: la dependencia es la misma para todos.

Lo que me deja pensando

No tengo conclusión cómoda para este post. Es uno de esos momentos en que veo el campo moverse y siento que las preguntas que vamos a tener que responder los próximos años son distintas a las que veníamos respondiendo desde marketing y negocio.

Una de las que me llevo: cuando recomendamos un stack al equipo de tecnología, ¿estamos pesando bien la capa de mantenimiento de seguridad, o seguimos eligiendo por funcionalidad y precio como hace cinco años?

¿Vos cómo lo estás viendo?