Los mitos son reales. Sé que una gran parte de la industria piensa que es un truco de marketing y entiendo por qué. Lo entiendo. Pero he visto los hallazgos y son malos. Estos no son «vaya, esta línea de aquí está mal, y ese es RCE». Son combinaciones novedosas de unas pocas docenas de problemas entre miles de cosas que cada escáner SAST ya encuentra, encadenadas en algo mucho peor. Es verdadera creatividad, como Move 37. Ese no es un mejor escáner. Esa es una categoría diferente de amenaza.
En cierto modo, ni siquiera importa. Incluso si este modelo específico fuera un engaño, la capacidad llegará de todos modos. Algunos días desearía que fuera un engaño. Tendríamos más tiempo. Pero puedes creerme o no. El resto de esta publicación trata sobre lo que hacemos al respecto de cualquier manera, y estoy comenzando ahora.
Washington ha estado siguiendo esto por un tiempo, pero no se puede regular algo que la mayoría de la industria cree que es inventado. Ahora que todas las salas de juntas están en modo de preparación (y lo están), DC finalmente puede comenzar a pensar qué pasos pueden tomar. Está claro que necesitan desempeñar un papel, pero no está claro cómo o qué debería ser. Y están en una situación realmente difícil.
Si se reglamenta muy poco, se corre el riesgo de que una empresa con sede en EE. UU. cree accidentalmente un arma que ponga en riesgo nuestra infraestructura crítica. Si se regula demasiado, sucede lo mismo en China. Todo esto parece una investigación de ganancia de función sobre virus. Todo el mundo sabe que debes lavarte las manos antes de salir del laboratorio, pero el hecho de que lo hagamos obligatorio no significa que el resto del mundo lo hará. Ya hemos visto cómo va esa historia en Wuhan.
He aquí el problema estructural que limita lo que cualquier gobierno puede hacer: a pesar de los mejores intentos de Europa con la CRA, el código abierto no es gobernable. Las leyes y órdenes ejecutivas no se aplican a personas de todo el mundo que suben contenido a Internet de forma gratuita. Estados Unidos se da cuenta de esto, por lo que se está centrando donde puede y donde debe: en el consumo. Ese es el instinto correcto, y es exactamente hacia donde se dirige el resto de esta publicación.
El ecosistema de código abierto y el modelo de consumo no están preparados para esto
He estado trabajando en este problema todos los días de mi vida durante la última década. Ayudé a fundar el AbiertoSSF y Alfa-Omega mientras estaba en Google. yo creé tienda de firmas, Cuadros de mandoy los primeros escáneres de malware de código abierto. Financiaré las subvenciones que pusieron Rust en el kernel de Linux y MFA en PyPI. Luego comencé Chainguard para hacer todo esto comercialmente, a escala. Les digo todo esto no para alardear, sino porque necesito que me crean cuando digo: la forma en que el mundo consume software de código abierto está fundamentalmente rota, y ninguna mejora incremental podrá solucionarlo a tiempo.
No en su forma actual. Quizás nunca. Va a tener que cambiar.
La mayoría de las empresas llevan años consumiendo código abierto libremente sin pensar realmente en ello. Las aplicaciones modernas son capas de dependencias, y cuando algo sale mal en una de ellas, arreglarlo puede afectar a toda una pila. Para organizaciones grandes con bases de código heredadas, esa no es una solución de la tarde. Y actuar rápido ahora tiene sus propios riesgos. La IA también ha potenciado los ataques a la cadena de suministro. Si se apresura a corregir una vulnerabilidad sin una revisión cuidadosa, podría instalar malware peor que el problema original.
El lado del mantenedor es aún más difícil. Especialmente para la gran cantidad de mantenedores que se preocupan y quieren ayudar. Muchos no lo hacen, y eso está completamente bien. No deben nada a sus aguas abajo. Parte del software más importante de Internet lo mantienen una o dos personas en su tiempo libre. Los escáneres automatizados y los informes generados por IA ya los han estado enterrando en ruido de baja calidad durante años. Y a diferencia del software comercial, los mantenedores de código abierto no tienen contratos ni SLA. No hay garantía de que un parche se escriba, se fusione o de que se pueda localizar a la persona.
La divulgación coordinada de vulnerabilidades fue diseñada para un mundo donde encontrar una vulnerabilidad grave requería semanas de trabajo experto y los objetivos eran un pequeño conjunto de proyectos bien conocidos. Un modelo ahora puede encontrar cientos de ellos de la noche a la mañana en la cola larga. El sistema existente no va a mantenerse al día y todos necesitamos un plan de respaldo para las vulnerabilidades que no se reparan.
Lo que realmente tiene que suceder
Necesitamos un Plan A y un Plan B.
Plan A: divulgación coordinada que realmente funcione a escala. Un grupo único y confiable que envía informes y parches completamente examinados en sentido ascendente y brinda soporte a los encargados de mantenimiento que desean ayuda. Ni una docena de grupos rivales presentando ruidosas multas. Un esfuerzo coordinado que los mantenedores reconocen y en el que confían, por lo que sus informes aparecen en la parte superior de cada bandeja de entrada. En este momento, Glasswing ha logrado que alrededor del 6% de sus hallazgos se transmitan. Este programa nunca llegará al 100%. No es así como funciona la larga cola del código abierto. Mi mejor suposición es que podemos lograr que la divulgación coordinada normal funcione, en momentos de crisis, tal vez para el 50% de los proyectos en el mejor de los casos. Y va a hacer falta mucho trabajo para llegar allí.
Plan B: cómo nos ocupamos del resto. Y no es una división limpia. Hay una gran cantidad de proyectos en los que el mantenedor responde pero no puede enviar una solución a tiempo, o donde existe un parche pero nadie en el nivel posterior lo recoge. Para todos ellos, y para los proyectos donde los mantenedores no pueden o no quieren aplicar ningún parche, necesitamos un mantenedor de último recurso. El código abierto te da derecho a bifurcar. Para emprender un proyecto, asumir la responsabilidad y mantenerlo vivo de forma independiente. La bifurcación de proyectos muertos o que no responden ya ocurre todos los días. Pero en un mundo con cientos de vulnerabilidades reportadas por docenas de grupos, necesitamos centralizarnos en un solo lugar para mantener esas bifurcaciones en las que los usuarios finales pueden confiar. Va a implicar decisiones difíciles y sentimientos heridos, pero es la única manera de evitar la fragmentación.
Hace un año, esto no habría sido posible a escala. Ahora lo es. Las mismas capacidades de IA que crean esta crisis son las que hacen viable un mantenedor de último recurso. Esa función debe residir en un lugar con financiación sostenible, personal, neutral y confiable.
El mejor momento para arreglar un árbol de dependencia fue hace 20 años. El próximo mejor momento es ahora. Y dice el refrán: si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado. El problema es que necesitamos hacer ambas cosas.
Tres bifurcaciones en el camino
Entonces, ¿qué hacemos realmente? Hay tres formas en que esto se desarrolla, dependiendo de cuánto de este problema crees que alguien más debe resolver y cuánto tiempo nos lleva darnos cuenta de que nadie vendrá a salvarnos y realmente arreglar nuestras cosas.
El ingenuo: no haces nada y esperas. Glasswing parchea todo en sentido ascendente, su proveedor protege mágicamente cada carga de trabajo para que nada pueda escapar, su equipo reescribe su canal de implementación heredado para enviarlo cada sesenta segundos y su CISO duerme toda la noche por primera vez desde 2014. Cada mantenedor responde a cada divulgación dentro de las 24 horas. Cada empresa actualiza cada dependencia el día que llega un parche. Nadie introduce una regresión. Nadie instala malware disfrazado de parche. Quiero vivir en este mundo. No vivimos en este mundo.
La caótica: nadie centraliza. Cada proveedor importante de nube crea sus propias versiones de bibliotecas críticas, cada una con sus propios conjuntos de parches. Tres proveedores de seguridad diferentes envían bifurcaciones competitivas del mismo marco de registro. Su equipo debe intentar averiguar qué versión de qué bifurcación tiene qué CVE corregidos y si alguno de ellos introdujo otros nuevos. Este es el valor predeterminado si no hacemos nada.
El hard fork: una decisión deliberada, coordinada y dolorosa para construir una nueva infraestructura de confianza para el consumo de código abierto. Un canal de divulgación que funciona a escala. Un lugar confiable para horquillas mantenidas. Decisiones difíciles sobre qué proyectos se bifurcan y cuáles sobreviven. Esta es la opción más difícil y la única real.
El código abierto siempre ha tenido un mecanismo para esto. Cuando un proyecto no puede o no quiere adaptarse, lo bifurcas. Asumes la responsabilidad, haces el trabajo y sigues adelante. Ese es el trato. Siempre ha sido el trato.
Lo que es diferente ahora es la escala. No estamos hablando de bifurcar un proyecto. Estamos hablando de construir la infraestructura para bifurcar, mantener y distribuir miles de ellos. Bajo presión de tiempo, con verdaderos adversarios del otro lado. Esa es la bifurcación más difícil que cualquiera de nosotros haya tenido que hacer.
Las mismas capacidades de IA que crearon esta crisis son las que la hacen posible. El software va a cambiar de maneras que hubieran sido inimaginables hace un año, y creo que hay un futuro mejor del otro lado.
¿Algo de esto realmente va a funcionar? Sinceramente no tengo idea. Pero tenemos que empezar y, como dice el Credo del Programador: «Hacemos esto no porque sea fácil, sino porque pensamos que sería fácil cuando empezamos». Este ni siquiera parece fácil al principio.
Obtenga lo último sobre el Blog de guardacadenas.
Nota: Este artículo está escrito y contribuido por expertos de Dan Lorenc, director ejecutivo y cofundador de Chainguard.
