Todo el mundo parece haber anunciado una cámara de compensación en las últimas semanas. Nosotros también lo hicimos. El nuestro se llama Athena, y lo principal que lo distingue es que ya era real y estaba en funcionamiento cuando lo anunciamos: construido silenciosamente meses antes, con la cabeza gacha, tomando hallazgos y enviando correcciones, porque los clientes nos seguían pidiendo que lo hiciéramos. Sólo lo anunciamos ahora porque todos los demás empezaron a anunciar los suyos, y quedarse callados empezó a parecer algo que no era. Los demás llegaron más ruidosamente y, por lo que cualquiera ajeno a los comunicados de prensa pudo ver, aún no existían.
Esta es la parte que ninguno de esos anuncios le dirá: la cámara de compensación es lo menos importante que hay que construir.
Cuando un proyecto que habíamos mantenido deliberadamente en privado, un comunicado de prensa de cinco mil millones de dólares y la Casa Blanca recurren a la misma palabra en unas pocas semanas, eso no es una tendencia. Las tendencias son opcionales. Esta es la forma de un problema que cambia para todos a la vez. Así que permítanme explicar por qué están apareciendo estas cosas, por qué la mayoría de ellas no importan y por qué las pocas que sí lo hacen corren silenciosamente para arruinarse.
Una cámara de compensación son solo datos
Las cámaras de compensación no son nuevas en el código abierto. Los hemos tenido durante décadas.
El NVD es una cámara de compensación. También lo es la base de datos de asesoramiento de GitHub, el OSV y todas las fuentes de seguridad que haya obtenido. Cada proveedor con un portal de vulnerabilidad también ejecuta uno, enfocado a su propio software. Todos son lo mismo: un conjunto de datos de vulnerabilidad con una puerta de entrada.
Los “centros de información” que se anunciaron este verano no son una especie nueva, pero sí reúnen un nuevo tipo de datos: vulnerabilidades previas a la divulgación dispersas a lo largo de la larga cola del código abierto. Algunos en proyectos críticos, otros en proyectos pequeños de los que nadie ha oído hablar; algunos con la última versión, otros con cualquier versión anterior que se estuviera ejecutando. Se trata del proyecto de investigación de seguridad menos organizado pero más completo jamás realizado. Y debido al modelo de proceso de Unix, todos importan lo mismo: una falla en la dependencia más oscura se ejecuta exactamente con los mismos privilegios que la aplicación que la cargó, por lo que la hoja más pequeña del árbol puede encargarse de todo el proceso.
Si la piscina no es nueva, la piscina no es la historia.
La piscina nunca fue el punto
Los datos son inertes. Un hallazgo que se encuentra en una base de datos nunca ha parcheado nada. El valor, la parte que siempre ha sido difícil, es la actuación: convertir ese hallazgo en un artefacto reconstruido, probado y firmado, adaptado a la versión que realmente está ejecutando, ubicado en el registro al que ya apuntan sus herramientas. No “aquí tienes un aviso, buena suerte”. Una solución, donde la consumirás antes de ir a buscarla.
Esta es la parte que Chainguard ha hecho durante años, sentándose detrás de cada cámara de compensación pública que existe. Nuestro sistema de compilación observa miles de proyectos de código abierto y reacciona en el momento en que llega un aviso: buscar, reconstruir desde el código fuente, probar, firmar. La mayoría de los CVE se solucionan en aproximadamente dos días y la inmensa mayoría nunca toca una mano humana. Mantenemos un SLA de un día sobre las vulnerabilidades que, según CISA, se explotan activamente. Hemos remediado más de 100.000 de ellos. Los datos de la cámara de compensación siempre fueron la entrada. La fábrica era el producto.
Es exactamente por eso que Athena es la cosa menos importante que construimos. Ya teníamos la fábrica. Una cámara de compensación es sólo una nueva puerta de entrada. Hace unos meses, cuando las personas que dirigían los programas modelo de frontera nos pidieron que empezáramos a hacer esto para vulnerabilidades no públicas, eso fue todo. La misma máquina. Tubería nueva.
La inundación es un subproducto
Olvídese de las cámaras de compensación por un segundo: ¿por qué de repente hay una avalancha de vulnerabilidades privadas en el código abierto y por qué todo el mundo escanea el mismo código?
La respuesta es que nadie se lo propuso. Es un subproducto.
La mejor manera de obtener una señal real de un modelo como Mythos no es apuntar a un archivo y preguntar cortésmente. Se trata de ponerlo delante de una aplicación en ejecución (lo que realmente se está ejecutando, un depurador adjunto, un entorno limitado para jugar, la fuente en contexto) y darle un mensaje vago y contradictorio. “Rompe esto”. Y lo hace.
Encuentra las fallas en su código propio y aquellas que usted acaba de corregir. Eres dueño de ese código. No necesita una cámara de compensación para parchearse.
Pero casi nada de una aplicación real es su código. La inmensa mayoría es de código abierto, gran parte está desactualizada y al modelo no le importa la línea entre lo que escribiste y lo que importaste. Se encadena por toda la superficie. El exploit que te ofrece no se detiene en tu frontera. Atraviesa una dependencia de tres niveles más abajo de la que nunca has oído hablar y que nadie ha mantenido en años.
Ese artefacto, un exploit funcional para código que no es tuyo para arreglar, es lo que no tiene adónde ir. A eso es a lo que cada una de estas cámaras de compensación es en realidad una respuesta. También explica las dos propiedades extrañas de los datos a la vez: es privado porque es un arma cargada y aterriza en un objetivo compartido, porque las pocas docenas de bibliotecas que aparecen en las aplicaciones de todos son exactamente las pocas docenas de bibliotecas que cada uno de estos modelos está rastreando ahora. Los hallazgos en sí apenas se superponen. Pero el código en el que aparecen sí lo hace.
Esa concentración decide la siguiente pregunta.
Unos cuantos grandes
¿Cuántos de estos deberían existir?
Comience con lo que hace que el momento sea brutal. El tiempo medio de explotación se estima ahora en siete días negativos. En todas las vulnerabilidades utilizadas como arma el año pasado, la explotación comenzó, en promedio, una semana antes de que el parche fuera público. Ese número solía ser más de sesenta días. Cruzó cero en 2024. Mandiant, Google y CrowdStrike cuentan la misma historia: CrowdStrike sitúa el 42% de las vulnerabilidades explotadas antes de su divulgación pública. El atacante ya no corre por el parche; el atacante está terminando antes de que comience el parche.
Y cuando hay un parche, el parche es el mapa. Una solución publicada es una diferencia que apunta directamente al error. En nuestros propios experimentos, hemos visto cómo un aviso se convertía en un exploit funcional, sin ninguna prueba de concepto pública de la que basarse, en menos de una hora. La divulgación es el pistoletazo de salida y te disparas a ti mismo.
Entonces todo el juego se convierte en: ¿qué parte del mundo ya está protegida en el momento en que ocurre la revelación? No pueden ser todos. La solución es el mapa, por lo que la protección previa a la divulgación se extiende exactamente hasta las personas a las que se puede examinar y someter a un embargo. Pero puede ser mucha gente, y a partir de ahí, si se actúa con rapidez y cuidado, se puede proteger mucho más en el momento en que se levante el embargo. Y esa es una cuestión de escala.
Los grupos más grandes ganan, por cuatro razones que se combinan. Los hallazgos rara vez se superponen, pero se acumulan en las mismas docenas de bibliotecas que se encuentran en la pila de todos, por lo que un grupo más grande asigna mapas que comparten un puñado de manera más completa que cualquier equipo por sí solo. Cada solución a una de esas bibliotecas protege a todos los miembros que dependen de ella, por lo que la cobertura aumenta con la membresía más rápido de lo que los atacantes pueden superarla. La escala también compra apalancamiento en sentido ascendente: un mantenedor voluntario se relaciona con un equipo de seguridad reconocido, no con treinta extraños. Y la escala compra alcance de orquestación, porque solo se pueden activar las capas que están en la sala: sin CDN, sin reglas de red; sin proveedores de seguridad, sin contenido de detección; nadie toca la producción, no hay backport.
Hay una razón más silenciosa: un canal lleno de exploits no embargados es el objetivo más valioso del ecosistema, y sólo una operación bien financiada puede defenderlo hasta el nivel que lo requiere. Uno delgado no es una versión más pequeña de lo mismo. Es una llave maestra.
Pero nunca iba a serlo. El miedo a una monocultura es real y racional: un grupo que contiene las hazañas previas a la divulgación de todos es la llave maestra de todo Internet, y nadie debería sentirse cómodo con eso, incluido quien lo posee. Los reguladores no lo son: APRA, el regulador bancario de Australia, les dice a sus bancos que se muevan a la velocidad de la IA y gestionen el riesgo de concentración al mismo tiempo. Los competidores no lo son: nadie que acaba de gastar cinco mil millones de dólares anunciando una cámara de compensación los incorpora a la de otra persona. Y ningún soberano lo es: ningún país canaliza el exploit previo a la divulgación para su propia infraestructura crítica a través del fondo de otro país.
Pero si uno es imposible, docenas son un desastre. Los hallazgos aterrizan en el mismo código compartido, por lo que los ganadores no pueden ignorarse unos a otros: embargos superpuestos, soluciones que compiten entre sí, la divulgación de un grupo detona la de otro. Cada par es una negociación permanente, y esa superficie crece con el cuadrado de la cuenta. Algunos son un grupo de trabajo. Decenas es la fragmentación que todos intentaban evitar, reconstruida un comunicado de prensa a la vez.
De modo que aterriza donde siempre aterriza la infraestructura de confianza crítica: DNS raíz, proveedores de nube, las CA después de Let’s Encrypt. Ni uno, ni mil. Algunos grandes. Y algunos son estables, porque una cámara de compensación no es un proveedor de nube: no se acumula nada de lo que usted pueda ser rehén. Deje de enviar datos, envíelos a otro lugar y, un período de divulgación después, será libre. Esa no es la concentración que nadie debería temer.
Lo que significa que la mayoría de las cámaras de compensación que están a punto de anunciarse son ruido. Hay una prueba limpia para el resto, y me pondré manos a la obra.
La piscina es un flujo, no una bóveda.
Si más grande es mejor, ¿no significa más grande también que se filtre un secreto más grande?
Lo sería si la piscina fuera una bóveda. No lo es. Es un flujo. Los hallazgos llegan, se activan y se van. Lo que está expuesto a una fuga en un momento dado no es todo lo que alguna vez se ha reunido. Es sólo lo que actualmente está en fuga, bajo embargo, esperando.
Eso invierte la intuición por completo. No se reduce el riesgo de fugas si se mantiene pequeño y realiza menos hallazgos. Lo reduce actuando más rápido, de modo que cada hallazgo pase menos tiempo en el grupo. La cámara de compensación peligrosa no es la más grande. Es el lento, donde los hallazgos se acumulan bajo embargo porque el operador no puede sacar las soluciones lo suficientemente rápido. Un atraso es la superficie de fuga.
Así que aquí hay una línea a la que pueden obligarme: si nuestro grupo está creciendo, estamos fallando. Una cámara de compensación en buen estado funciona en un estado estable: lo que entra sale y el tamaño en pie se mantiene estable. Un grupo en crecimiento no es una señal de éxito. Es la alarma de que la actuación está perdiendo la carrera. El tamaño de la piscina es un termómetro, no un trofeo.
El rendimiento es al mismo tiempo valor y propiedad de seguridad. Ese es todo el juego.
De coordinado a orquestado
La divulgación coordinada de vulnerabilidades era un protocolo: un apretón de manos entre un buscador y un mantenedor, creado para un mundo donde los errores se encontraban lentamente y uno a la vez. La palabra lo delata. “Coordinado” significa que dos partes acuerdan un cronograma.
Ese mundo se ha ido. No se pueden coordinar manualmente diez mil hallazgos. Pero puedes orquestarlos. La misma automatización que permite que un modelo los encuentre a la velocidad de la máquina es la que le permite arreglarlos a la velocidad de la máquina. El cambio es de una divulgación coordinada a una divulgación orquestada: no dos partes negociando una fecha, sino un conductor que dirige cada punto de control para que aterrice en un solo tiempo fuerte.
Ya sabes cómo se ve la ausencia de eso. Parece log4j.
La divulgación funcionó. El parche existió temprano. Lo que convirtió a log4j en un mes perdido no fue una falta de divulgación. Eran cien mil equipos de seguridad que hacían la misma emergencia de forma independiente y manual. Todos buscando la misma clase, escribiendo a mano la misma regla WAF, volteando la misma bandera, buscando las mismas copias sombreadas y luego repitiendo todo de nuevo cuando el primer parche resultó estar incompleto. Ese no fue un problema de divulgación. Esa fue la ausencia de una capa de orquestación.
La divulgación orquestada es log4j, donde el conductor activa todo en el tiempo fuerte (la regla WAF, la firma de la red, el backport, los datos VEX que le indican dónde no está afectado, el contenido de detección, la solicitud de extracción ascendente) en el momento en que se levanta el embargo. El tiroteo termina antes de que la mayoría de los equipos se despierten. Es por eso que la capa importa más que el grupo y por qué el alcance es una función de quién está en la sala.
Para ser claros, la coordinación no desaparece. Se reduce a lo único que sigue siendo genuinamente humano: negociar el embargo y conseguir que se acepte la solución duradera en las fases iniciales. Todo lo que se encuentra detrás del tiempo fuerte queda orquestado.
¿Qué pasa después?
Hay un juego corto y un juego largo, y no son el mismo juego.
el juego corto
Habrá una avalancha de anuncios de la cámara de compensación. Es posible que haya habido otro mientras lees esto. Hace calor, hay dinero y titulares, y todos quieren una parte. Ignora casi todo. El lanzamiento nunca es la métrica.
Aquí está la prueba limpia que prometí, y es lo suficientemente simple como para preguntarle a cualquier proveedor que le ofrezca una cámara de compensación. Haz dos preguntas. Primero: desde el hallazgo hasta la reparación reconstruida, probada y firmada, ¿cuánto tiempo, en promedio, y qué fracción nunca toca una mano humana? Eso es rendimiento, y si no pueden darte un número, no han medido lo que importa.
Segundo: de las correcciones que envió, ¿cuántas llegaron a la fuente, en comparación con cuántas solo llegaron a las personas que las obtuvieron directamente de usted? Eso es alcance, y es la diferencia entre un proveedor que parchea a sus propios clientes y un proveedor que realmente reduce el problema. Cualquier operador en el que valga la pena confiar puede responder a ambas cosas con un número. Los que responden con el tamaño de la piscina te están diciendo que aún no han medido lo correcto. Los hallazgos son vanidad. Una solución que nadie puede alcanzar es apenas mejor que un hallazgo.
Entonces, la métrica nunca fue cuántas vulnerabilidades tienes. Es la cantidad de personas a las que realmente ayudas por mes: directamente, las que obtienen las soluciones directamente de ti, e indirectamente, las muchas más protegidas porque la solución llegó a un nivel inicial o se envió a través de un socio, personas que nunca sabrán tu nombre.
Por si sirve de algo, el nuestro ya ha recibido más de veinte mil hallazgos y ha enviado más de dos mil parches en quinientos proyectos. Sin embargo, según nuestra propia prueba, esos no son los números que cuentan. Enviar un parche a nuestro propio registro es la parte fácil; todavía es una solución posterior a la solución la que en realidad resta importancia al problema en lugar de simplemente gestionarlo: la que se acepta en sentido ascendente, en la fuente, protegiendo a todos los demás, hayan oído hablar de nosotros o no. Ese número indirecto es el que cuenta.
Así que aquí hay otra línea que pueden exigirme: vamos a publicarlo todo: el tiempo medio desde que se encuentra hasta que se envía la solución, la fracción que nunca toca una mano humana y la parte que llega río arriba. Las primeras cifras no serán buenas, ni para nosotros ni para nadie; el upstreaming a esta escala lleva semanas. Los publicaremos de todos modos, porque una prueba que usted no realiza no es una prueba.
Los que duren no serán los que estén diseñados para ganar dinero rápido. Esta es una infraestructura que se defiende porque es necesaria para sobrevivir a la ola, no porque imprima dinero este trimestre. Puedes distinguir a los serios por dónde dedican el esfuerzo por el que nadie les paga: las integraciones, las asociaciones, las solicitudes de extracción ascendentes que no generan ingresos pero sí generan confianza.
Si está decidiendo en quién confiarle esto, ese es todo el trabajo: ejecute la prueba de dos preguntas anterior con cualquiera que se presente solicitando sus datos, pregunte qué sucede con un hallazgo después de encontrarlo y no permita que el tamaño del grupo sustituya la respuesta. Si está decidiendo si construir uno usted mismo, pregunte si ya tiene la fábrica (la tubería de búsqueda, reconstrucción, prueba y señalización) porque sin ella, una cámara de compensación es un buzón que nadie revisa.
El juego largo
Todo esto es temporal. Tiene que serlo. No sabemos si la próxima generación de modelos encontrará diez veces más vulnerabilidades en el mismo código que ya hemos escaneado hasta el cansancio. La aplicación de parches de vulnerabilidad siempre ha sido una rutina. Acabamos de aumentar la velocidad y esperábamos que todos la mantuvieran durante un maratón; y seamos honestos, la mayoría de nosotros ni siquiera caminábamos sobre ella antes.
Los equipos de ciberseguridad saben desde hace una década que aplicar parches, minimizar la superficie de ataque y mantener las dependencias actualizadas es una buena higiene. Casi nadie lo hace al ritmo que juraron el 1 de enero. No estoy juzgando; He conocido mis propios árboles de dependencia.
Las cámaras de compensación son una red de seguridad detrás de la cinta de correr. Tal vez reduzcan un poco la velocidad. Pero no todos nos pondremos en forma para un maratón de la noche a la mañana, y no deberíamos tener que hacerlo. Necesitamos una salida de la cinta, no una más rápida.
La seguridad por diseño está muy lejos de eso: nuevas versiones de las bibliotecas, marcos y herramientas, reconstruidas para que clases enteras de estos ataques sean simplemente imposibles; no parcheadas después del hecho, imposible. El final no es una mejor cámara de compensación. Es una capa base de código abierto tan difícil de romper que los modelos quedan vacíos y las cámaras de compensación finalmente pueden quedarse inactivas. Ésa es la señal para los que importan: están compitiendo para volverse innecesarios.
¿Funcionará? Sinceramente, no lo sé. La seguridad por diseño ha sido la respuesta correcta durante treinta años, y el mundo ha encontrado treinta años de razones para no hacerlo. Pero la cinta de correr no tiene una línea de meta y ya no pretendo que la tenga. Nunca íbamos a ganar este por velocidad.
Este verano de cámaras de compensación no durará para siempre. Si lo hacemos bien, no será necesario.
