Apache tuvo que luchar a principios de diciembre de 2021 para estar listo para lanzar parches para Log4Shell cuando reveló públicamente la situación el 9 de diciembre del año pasado. Como resultado, los investigadores encontraron rápidamente casos extremos y soluciones para los parches, y Apache se vio obligado a lanzar múltiples iteraciones, lo que aumentó la confusión.
“Esta cosa estaba en todas partes, realmente en todas partes”, dice Jonathan Leitschuh, investigador de seguridad de código abierto. “Los atacantes saltaban sobre él, la comunidad de seguridad saltaba sobre él, las cargas útiles volaban por todas partes”.
Sin embargo, los investigadores dicen que la respuesta general de Apache fue sólida. Nalley agrega que Apache realizó cambios y mejoras en reacción a la saga Log4Shell y contrató personal dedicado para expandir el soporte de seguridad que puede ofrecer a los proyectos de código abierto para detectar errores antes de que se envíen en código y responder a incidentes cuando sea necesario.
“En un corto período de tiempo, dos semanas, tuvimos arreglos, lo cual es genial”, dice Nalley. “De alguna manera, esta no es una situación nueva para nosotros, y me encantaría decir que la manejamos a la perfección. Pero la realidad es que, incluso en Apache Software Foundation, esto resaltó la responsabilidad que tenemos con todos los que consumen nuestro software”.
En el futuro, el aspecto más preocupante de la situación es que, incluso un año después, aproximadamente una cuarta parte o más de las descargas de Log4j del repositorio de Apache Maven Central y otros servidores del repositorio todavía están llenas de versiones vulnerables de Log4j. En otras palabras, los desarrolladores de software aún mantienen activamente los sistemas que ejecutan versiones vulnerables de la utilidad o incluso crean un nuevo software que es vulnerable.
«La realidad es que la mayoría de las veces, cuando las personas eligen un componente de software de código abierto vulnerable, ya hay una solución disponible», dice Brian Fox, cofundador y director de tecnología de la empresa de cadena de suministro de software Sonatype, que opera Maven. Central y también es un proveedor de repositorio de Apache de terceros. «He estado en esto durante mucho tiempo y estoy cansado, pero eso es realmente impactante. Y la única explicación es que la gente realmente no entiende lo que hay dentro de su software». .”
Fox dice que después de la lucha inicial para abordar Log4Shell, las descargas de versiones en Maven Central y otros repositorios llegaron a un estante donde aproximadamente el 60 por ciento de las descargas eran de versiones parcheadas y el 40 por ciento todavía eran de versiones vulnerables. Durante los últimos tres meses, Fox y Nalley de Apache dicen que han visto caer los números por primera vez a una división de aproximadamente 75/25 por ciento. Sin embargo, como dice Fox, «después de un año, una cuarta parte de las descargas sigue siendo bastante terrible».
“Algunas personas sienten que Log4j fue un gran despertar para la industria, un enloquecimiento y un despertar colectivo”, dice. “Y realmente nos ha ayudado a ampliar el mensaje sobre la seguridad de la cadena de suministro de software, porque ya no había gente que lo negara. Lo que todos hablábamos era real ahora, todos lo estábamos viviendo. Pero solo la presión de los compañeros de Log4j debería haber obligado a todos a actualizar, así que si no podemos hacer que este esté al 100 por ciento, ¿qué pasa con todos los demás?
Para los investigadores de seguridad, la cuestión de cómo abordar la cola larga de una vulnerabilidad siempre está presente. Y el problema se aplica no solo al software de código abierto, sino también a los sistemas propietarios. Solo piense en cuántos años tomó sacar al último 10 por ciento de los usuarios de Windows de XP.
«Con estos escenarios del peor de los casos, eventos de cisne negro en código abierto, simplemente sabes que van a seguir ocurriendo, porque la comunidad ha mejorado mucho en reaccionar, pero el ritmo del desarrollo de código abierto es aún más rápido». Lorenc de ChainGuard dice. “Así que tenemos que encontrar el equilibrio entre la prevención y la mitigación, y seguir realizando esfuerzos para reducir la frecuencia tanto como sea posible. Es como Los Simpsons meme cuando Bart dice: ‘Este es el peor día de mi vida’. Y Homer dice que no, ‘El peor día de tu vida’ hasta aquí.’”