En la vida, como en los negocios, lo que importa no es sólo de quién dependes, sino también de quién dependen ellos. Y, al igual que en las relaciones humanas, los ecosistemas de software comprenden una vasta red de relaciones. Algunos de estos lazos son muy profundos, mientras que otros son más superficiales. Pero el hecho permanece: el desarrollo moderno de software basado en código abierto (OSS) implica un gran árbol de dependencia con raíces largas y profundas que tocan riesgos conocidos y desconocidos.
Un informe reciente de Endor Labs encontró que el 95% de las dependencias vulnerables son transitivas. Estas dependencias transitivas son componentes integrados profundamente en la cadena de software, lo que las hace más difíciles de evaluar y alcanzar. Y no es necesariamente que estos paquetes vulnerables estén muy desactualizados: el 25 % de los paquetes lanzados en 2022 todavía tienen entre una y 18 vulnerabilidades conocidas.
Las nuevas vulnerabilidades en torno a las dependencias de código abierto continúan presentándose a diario. El reciente caos de la cadena de suministro de software agrega otra capa a las cargas de mantenimiento del “infierno de la dependencia”. Y aunque las organizaciones sin fines de lucro y los organismos gubernamentales han buscado mejorar la seguridad del código abierto e introducir regulaciones sobre la seguridad del software de terceros, la industria aún está muy lejos de tener los estándares y las técnicas necesarias para detener la marea.
El estudio 2022 State of Dependency Management de Endor analiza las complejidades del desarrollo moderno basado en código abierto y ofrece orientación. A continuación, resumiré los puntos principales del estudio para comprender mejor el estado de la gestión de la dependencia y cómo deben responder los profesionales de la ciberseguridad.
Comprender las dependencias transitivas
Una dependencia directa es cuando una aplicación depende directamente de una determinada biblioteca o paquete para funcionar. Una dependencia transitiva, por otro lado, es una dependencia incrustada dentro de un paquete. Como se puede imaginar, podría haber múltiples niveles de dependencias transitivas que los desarrolladores de aplicaciones insertan sin saberlo en sus aplicaciones al incluir otras dependencias. El gráfico 8 del informe muestra visualmente cómo las dependencias transitivas cobran vida dentro de las aplicaciones posteriores:
En la vida, como en los negocios, lo que importa no es solo de quién dependes, sino también de quién dependen ellos . Y al igual que en las relaciones humanas, los ecosistemas de software comprenden una vasta red de relaciones. Algunos de estos lazos son muy profundos, mientras que otros son más superficiales. Pero el hecho permanece: el desarrollo moderno de software basado en código abierto (OSS) implica un gran árbol de dependencia con raíces largas que tocan riesgos conocidos y desconocidos.
Un informe reciente de Endor Labs encontró que el 95 % de las dependencias vulnerables son transitivas . Estas dependencias transitivas son componentes integrados profundamente en la cadena de software, lo que los hace más difíciles de evaluar y alcanzar. Y no es necesariamente que estos paquetes vulnerables estén muy desactualizados: el 25 % de los paquetes lanzados en 2022 todavía tienen entre una y 18 vulnerabilidades conocidas.
Las nuevas vulnerabilidades en torno a las dependencias de código abierto continúan presentándose a diario. El reciente caos de la cadena de suministro de software agrega otra capa a las cargas de mantenimiento del “infierno de la dependencia”. Y aunque las organizaciones sin fines de lucro y los organismos gubernamentales han buscado mejorar la seguridad de código abierto e introducir regulaciones sobre la seguridad del software de terceros, la industria aún está muy lejos de tener los estándares y las técnicas necesarias para detener la marea.
El estudio 2022 State of Dependency Management de Endor analiza las complejidades del desarrollo moderno basado en código abierto y ofrece orientación. A continuación, resumiré los puntos principales del estudio para comprender mejor el estado de la gestión de la dependencia y cómo deben responder los profesionales de la ciberseguridad .
Comprender las dependencias transitivas
Una dependencia directa es cuando una aplicación depende directamente de una determinada biblioteca o paquete para funcionar. Una dependencia transitiva, por otro lado, es una dependencia incrustada dentro de un paquete. Como se puede imaginar, podría haber múltiples niveles de dependencias transitivas que los desarrolladores de aplicaciones insertan sin saberlo en sus aplicaciones al incluir otras dependencias. El gráfico 8 del informe muestra visualmente cómo las dependencias transitivas cobran vida dentro de las aplicaciones posteriores:
El informe encontró que la profundidad promedio está a dos pasos de distancia, pero podría llegar hasta siete en algunos casos.
Para este estudio, Endor Labs tomó un conjunto de datos del informe Census II, que proporcionó una lista del software libre de código abierto (FOSS) más popular y lo enriqueció con otras fuentes. Los datos, de código abierto en GitHub, representan un análisis de las aplicaciones de producción que cubren distribuciones populares como npm, maven, nugget, pipit y ruby gems.
De los 254 paquetes distintos de Maven mencionados en el conjunto de datos del Censo II, la mayoría tiene un promedio de 14 dependencias. Esto puede no parecer muy alto, pero dado que la mayoría de las aplicaciones tienen docenas, si no cientos de dependencias, la probabilidad de que una aplicación posea dependencias transitivas afectadas aumenta exponencialmente.
Como tal, hay un 32% de posibilidades de que un paquete Maven aleatorio tenga una o más vulnerabilidades conocidas ocultas en su árbol de dependencias. Algunos valores atípicos tienen muchas más dependencias, lo que aumenta las posibilidades de vulnerabilidades potenciales. Por ejemplo, log4j-core v2.19.0 tenía 141 dependencias, y se descubrió que aws-java-sdk v1.12.316 tenía 331 dependencias.
Soluciones y consejos para administrar dependencias
En un mundo de proveedores de servicios en la nube (CSP), la responsabilidad de la seguridad es compartida. El CSP protege la infraestructura y el consumidor protege las aplicaciones y los medios construidos sobre él. Sin embargo, en el mundo del código abierto, la carga de la seguridad recae en gran medida en manos del consumidor de software.
“Los consumidores de OSS mantienen la responsabilidad general y deben abordar los riesgos de seguridad de acuerdo con sus circunstancias específicas”.
Dicho esto, hemos visto un movimiento sustancial de los organismos reguladores para establecer más estándares relacionados con las dependencias de terceros. Estos incluyen el Programa de Certificación de Ciberseguridad Candidato de la UE para Servicios en la Nube, la Orden Ejecutiva 14028 de la Casa Blanca y las pautas de NIST, NITIA y ENISA.
Además, los grupos sin fines de lucro como OpenSSF, CNCF y OWASP continúan difundiendo las mejores prácticas y desarrollando herramientas de seguridad relevantes. Sin embargo, los proveedores de software aún deben asumir la responsabilidad de garantizar que sus árboles de dependencia sean estables y estén libres de vulnerabilidades importantes.
Aquí hay algunos consejos, seleccionados del informe, sobre cómo responder:
Contribuir a proyectos de código abierto. Como he cubierto anteriormente, demasiadas empresas usan código abierto sin contribuir a los proyectos. El código abierto requiere un esfuerzo de grupo para mejorar, pero en proporción a sus altas tasas de uso, pocas organizaciones realmente los apoyan y reportan vulnerabilidades de seguridad.
Cree una cultura más inteligente en torno a la adquisición de software y la gestión de dependencias. Los proveedores de software deben sumergirse más profundamente en el “infierno de la dependencia” para auditar su área de superficie y descubrir en qué confían. Esto también significa actualizar los componentes antiguos en el árbol de dependencias y ser más selectivo durante la adquisición para evitar paquetes maliciosos.
Eliminar dependencias no utilizadas. Si un programa no invoca una dependencia en un proyecto ascendente, es mejor eliminarlo. Esto puede reducir la probabilidad de vulnerabilidades ocultas y también minimizar la hinchazón. Como dice el informe, las herramientas de análisis de composición de software (SCA) deben priorizar el análisis de las dependencias que realmente se mostrarán en producción, no las que se usan únicamente con fines de prueba.
Priorice las vulnerabilidades de alto riesgo y alcanzables. Es probable que desee corregir rápidamente las vulnerabilidades con puntajes CVSS altos. Sin embargo, también considere la accesibilidad de la vulnerabilidad, ya que los piratas informáticos pueden apuntar a las de bajo riesgo simplemente si son más fáciles de explotar.
Programe bien sus actualizaciones. El estudio encontró que solo el 9% de las actualizaciones requieren un cambio de versión importante. ¡Sin embargo, el 20,1% de los lanzamientos no importantes causan cambios importantes! La depuración de las actualizaciones de dependencia puede llevar tiempo y esfuerzo, pero dejarlas sin abordar puede hacer que las principales vulnerabilidades sean propensas a ataques. Por lo tanto, es bueno configurar una cadencia de actualización regular que funcione para su equipo.
El software envejece como la leche, no como el vino
En los últimos años, hemos sido testigos de grandes exploits como SolarWinds, Log4j y Spring4Shell, y este año la Vulnerabilidad de texto de Apache Commons y el protestware tomaron relevancia. Es probable que los ataques de confusión de dependencia y ocupación tipográfica continúen en el próximo año, junto con vectores de ataque imprevistos.
Y con todo lo que sabemos ahora, responder a estos riesgos requerirá una vigilancia constante. Porque desafortunadamente, si se deja reposar, el software se pudre rápidamente. “El software es como la leche: se agria rápidamente”, como dice una línea del informe. Sabiendo cuán interconectado está el árbol de dependencia moderno, es esencial mantener la supervisión del número creciente de dependencias, y sus vulnerabilidades, que conforman los ecosistemas de software modernos.
Autor: Bill Doerrfeld
Artículo original aquí
