Los mitos son realidad. Sé que la mayor parte de la industria piensa que esto es un truco de marketing y puedo ver por qué. Comprendido. Pero miré los hallazgos y eran malos. Estos no son: «Oh, esta línea está mal. Este es un RCE». Se trata de nuevas combinaciones de docenas de problemas que todos los escáneres SAST ya detectan y que se combinan en cascada para empeorarlos aún más. Esta es verdadera creatividad como Move 37. Este no es un gran escáner. Esa es una categoría diferente de amenaza.
En cierto modo, ni siquiera importa. Incluso si este modelo en particular es un engaño, sus características aparecerán de todos modos. Algunos días desearía que fuera un engaño. Ojalá tuviera más tiempo. Pero créame o no, depende de usted. El resto de esta publicación trata sobre lo que hacemos al respecto de todos modos, y estoy empezando ahora.
Washington ha estado siguiendo esto por un tiempo, pero no puede regular lo que la mayoría de la industria considera un engaño. Ahora que todas las salas de juntas están en modo de preparación (y lo están), DC finalmente está comenzando a considerar qué pasos pueden tomar. Está claro que necesitan desempeñar un papel, pero no está claro cómo o cuál debería ser. Y están en una posición realmente difícil.
Muy poca regulación corre el riesgo de permitir que las empresas con sede en Estados Unidos creen accidentalmente armas y pongan en peligro infraestructura crítica. Si restringimos demasiado, ocurrirá lo mismo en China. Todo parece un estudio de ganancia de función de un virus. Todos sabemos que debemos lavarnos las manos antes de salir del laboratorio, pero sólo porque lo exijamos no significa que otros países también lo harán. Ya hemos visto cómo se desarrolla esta historia en Wuhan.
Aquí hay problemas estructurales que limitan lo que el gobierno puede hacer. A pesar de los mejores intentos de Europa en materia de CRA, el código abierto no es gobernable. Las leyes y órdenes ejecutivas no se aplican a las personas de todo el mundo que publican de forma gratuita en Internet. Estados Unidos lo sabe, por eso se centra en dónde puede y debe estar: en el consumo. Esa es una intuición válida, y el resto de esta publicación pretende hacer precisamente eso.
Los ecosistemas de código abierto y los modelos de consumo no están preparados para esto
He estado lidiando con este problema todos los días durante los últimos 10 años. Durante mi tiempo en Google, ayudé a descubrir OpenSSF y Alpha-Omega. Creé Sigstore, Scorecards y el primer escáner de malware de código abierto. Presenté Rust al kernel de Linux y financié una subvención para llevar MFA a PyPI. Luego lanzamos Chainguard para hacer todo esto de forma comercial y a escala. No digo todo esto para alardear. Sino porque quiero que me creas. La forma en que el mundo utiliza el software de código abierto está fundamentalmente fallida y ninguna cantidad de mejoras incrementales podrá solucionarlo a tiempo.
No en su forma actual. Probablemente nunca antes. Eso tiene que cambiar.
La mayoría de las empresas llevan años utilizando el código abierto libremente sin pensar realmente en ello. Las aplicaciones modernas se componen de capas de dependencias, y si una de ellas sale mal, su reparación se extiende a toda la pila. Si es una organización grande con un código base heredado, no necesita pasar una tarde arreglándolo. Y avanzar ahora conlleva sus propios riesgos. La IA también impulsa los ataques a la cadena de suministro. Parchar las vulnerabilidades demasiado rápido y sin una cuidadosa consideración puede instalar malware incluso peor que el problema original.
Es aún más difícil por parte del mantenedor. Especialmente para la gran cantidad de mantenedores que se preocupan y quieren ayudar. Mucha gente no lo hace, y eso está perfectamente bien. No deben nada aguas abajo. Parte del software más importante de Internet lo mantienen una o dos personas en su tiempo libre. Los informes generados por escáneres automatizados y la IA ya llevan años atrapados en un ruido de baja calidad. Además, a diferencia del software comercial, los mantenedores de código abierto no tienen contratos ni SLA. No hay garantía de que el parche se cree y fusione, ni de que llegue a esa persona.
La Divulgación Coordinada de Vulnerabilidades fue diseñada para un mundo donde descubrir vulnerabilidades graves requiere semanas de trabajo experto y se dirige a una pequeña cantidad de proyectos bien conocidos. Los modelos ahora pueden encontrar cientos de ellos durante la noche en la cola larga. Necesita un plan de respaldo para las vulnerabilidades sin parches porque sus sistemas existentes no las cubrirán.
lo que realmente tiene que suceder
Necesitas un plan A y un plan B.
Plan A: Divulgación coordinada que realmente funcione a escala. Un grupo único y confiable para enviar informes y parches examinados en sentido ascendente y brindar soporte a los mantenedores que necesitan ayuda. Más de una docena de grupos competidores han presentado ruidosas multas. Los informes de los mantenedores aparecen en la parte superior de las bandejas de entrada de todos porque reconocen y confían en nuestro esfuerzo único y coordinado. Actualmente, Glasswing logra entregar aproximadamente el 6% de los resultados de la investigación en sentido ascendente. Este programa nunca llegará al 100%. La larga cola del código abierto no funciona de esa manera. Supongo que, como máximo para el 50% de los proyectos, las divulgaciones ajustadas normales podrían funcionar, incluso en circunstancias difíciles. Y será necesario un gran esfuerzo para llegar allí.
Plan B: Cómo lidiar con el resto. Y no es una división limpia. Hay una parte intermedia del proyecto muy complicada en la que el mantenedor responde pero no puede enviar una solución a tiempo, o el parche existe pero nadie en el nivel posterior lo recibe. Para todos estos, y para los proyectos que los mantenedores no pueden parchar o no parchean en absoluto, necesita mantenedores como último recurso. El código abierto te da derecho a bifurcar. Para emprender un proyecto, asumir la responsabilidad de la gestión y mantenerlo independiente. La bifurcación de proyectos muertos o que no responden ya ocurre todos los días. Pero en un mundo donde docenas de grupos informan cientos de vulnerabilidades, los usuarios finales necesitan una ubicación central para mantener una bifurcación confiable. Será exigente y herirá sentimientos, pero es la única manera de evitar la fragmentación.
Hace un año, esto habría sido imposible de hacer a escala. Ahora lo es. Las mismas capacidades de IA que causaron esta crisis son las que hacen viables a los mantenedores de último recurso. Esa función debe contar con financiación sostenible, dotación de personal y ubicación en un lugar neutral y confiable.
El mejor momento para arreglar su árbol de dependencia fue hace 20 años. El próximo mejor momento es ahora. Y como dice el refrán: «Si quieres ir rápido, ve solo». Si quieres llegar lejos, vayamos juntos. El problema es que necesitas hacer ambas cosas.
tres bifurcaciones en el camino
Entonces, ¿qué deberías hacer realmente? Hay tres formas en que este problema puede desarrollarse, dependiendo de cuánto de este problema creas que alguien más tiene que resolver y cuánto tiempo te lleva darte cuenta de que nadie vendrá a salvarnos y resolver el problema.
Persona ingenua: Esperanza sin hacer nada. Glasswing parchea todo lo anterior y los proveedores protegen mágicamente todas sus cargas de trabajo para que nada pueda escapar. Los equipos están reescribiendo los canales de implementación tradicionales para enviarlos cada 60 segundos, y los CISO se quedan despiertos toda la noche por primera vez desde 2014. Todos los encargados de mantenimiento responden a todas las divulgaciones dentro de las 24 horas. Cada empresa actualiza todas las dependencias el mismo día que se aplica un parche. Nadie introduce la regresión. Nadie instala malware disfrazado de parche. Quiero vivir en este mundo. No vivimos en este mundo.
Caótico: nadie lo centraliza. Todos los principales proveedores de nube han bifurcado sus propias versiones de bibliotecas críticas y cada una tiene su propio conjunto de parches. Tres proveedores de seguridad diferentes están enviando bifurcaciones competidoras del mismo marco de registro. Los equipos necesitan saber qué CVE están corregidos en qué versión de cada bifurcación y si se están introduciendo nuevos CVE. Este es el valor predeterminado si no haces nada.
Hard fork: una decisión intencional, coordinada y difícil para crear una nueva infraestructura de confianza para el uso 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 realista.
El código abierto siempre ha tenido un mecanismo para esto. Bifurcar un proyecto si no puede o no puede adaptarse. Asumes la responsabilidad, haces tu trabajo y sigues adelante. Ese es el trato. Siempre fue un 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 la presión del tiempo, el verdadero enemigo está del otro lado. Es la bifurcación más difícil en el camino que cualquiera de nosotros haya tenido que tomar.
Las mismas capacidades de IA que crearon esta crisis lo permitirán. El software está experimentando cambios que eran inimaginables hace un año y creo que el futuro es brillante.
¿Esto realmente funciona? Sinceramente, no lo sé. Pero tenemos que empezar. Como dice el mantra del programador: «No hacemos esto porque sea fácil, lo hacemos porque pensamos que era fácil cuando empezamos». Puede que esto ni siquiera parezca fácil al principio.
Manténgase actualizado con el blog Chainguard.
Nota: Este artículo fue escrito y contribuido profesionalmente por Dan Lorenc, director ejecutivo y cofundador de Chainguard.
Source link
