Durante décadas, la reutilización del software se ha discutido con más frecuencia de lo que realmente fue. Hoy la situación es la opuesta: los desarrolladores reutilizan los programas de otras personas todos los días en forma de dependencias de software, y el problema en sí sigue siendo casi inexplorado.

Mi propia experiencia incluye una década de trabajo con el repositorio interno de Google , donde las dependencias se establecen como un concepto prioritario, así como el desarrollo de un sistema de dependencia para el lenguaje de programación Go .

Las dependencias conllevan serios riesgos que a menudo se pasan por alto. La transición a la reutilización simple de las piezas de software más pequeñas se ha producido tan rápidamente que aún no hemos desarrollado las mejores prácticas para la selección y el uso efectivos de las dependencias. Incluso para tomar decisiones cuando son apropiadas y cuando no. El propósito de este artículo es evaluar los riesgos y estimular la búsqueda de soluciones en esta área.

¿Qué es la adicción?

En el desarrollo moderno, la dependencia es un código adicional que se llama desde un programa. Agregar una dependencia evita la repetición del trabajo ya realizado: diseño, escritura, prueba, depuración y soporte de una unidad de código específica. Llamamos a esta unidad de código un paquete , aunque en algunos sistemas se usan otros términos, como una biblioteca o módulo, en lugar de un paquete.

Aceptar dependencias externas es una práctica antigua: la mayoría de los programadores descargaron e instalaron la biblioteca necesaria, ya sea PCRE o zlib de C, Boost o Qt de C ++, JodaTime o Junit de Java. Estos paquetes tienen código depurado de alta calidad que requiere una experiencia considerable para crear. Si un programa necesita la funcionalidad de dicho paquete, es mucho más fácil descargarlo, instalarlo y actualizarlo manualmente que desarrollar esta funcionalidad desde cero. Pero los grandes costos iniciales significan que la reutilización manual es costosa: los paquetes pequeños son más fáciles de escribir usted mismo.

Un administrador de dependencias (a veces llamado administrador de paquetes) automatiza la descarga e instalación de paquetes de dependencias. Debido a que los administradores de dependencias facilitan la descarga e instalación de paquetes individuales, reducir los costos fijos hace que los paquetes pequeños sean económicos de publicar y reutilizar.

Por ejemplo, un administrador de dependencias de Node.js llamado NPM proporciona acceso a más de 750,000 paquetes. Uno de ellos, escape-string-regexp , contiene una sola función que escapa a los operadores de expresiones regulares de los datos de entrada. Toda la implementación:

 var matchOperatorsRe = /[|\\{}()[\]^$+*?.]/g; module.exports = function (str) { if (typeof str !== 'string') { throw new TypeError('Expected a string'); } return str.replace(matchOperatorsRe, '\\$&'); }; 

Antes de que aparecieran los administradores de dependencias, era imposible imaginar la publicación de una biblioteca de ocho líneas: demasiados gastos generales y muy pocos beneficios. Pero NPM redujo la sobrecarga a casi cero, con el resultado de que una funcionalidad casi trivial podría empaquetarse y reutilizarse. A finales de enero de 2019, la dependencia escape-string-regexp se incorporó a casi mil paquetes de NPM, sin mencionar todos los paquetes que los desarrolladores escriben para su propio uso y no publican en el dominio público.

Ahora los administradores de dependencia han aparecido para casi todos los lenguajes de programación. Maven Central (Java), Nuget (.NET), Packagist (PHP), PyPI (Python) y RubyGems (Ruby): cada uno de ellos tiene más de 100,000 paquetes. El advenimiento de la reutilización generalizada de paquetes pequeños es uno de los mayores cambios en el desarrollo de software en las últimas dos décadas. Y si no somos más cuidadosos, esto conducirá a serios problemas.

¿Qué podría salir mal?

En el contexto de esta discusión, un paquete es un código descargado de Internet. Agregar una dependencia confía el trabajo de desarrollar este código (diseño, escritura, prueba, depuración y soporte) a otra persona en Internet a la que generalmente no conoce. Con este código, expone su propio programa a los efectos de todos los bloqueos y defectos de la dependencia. La ejecución de su software ahora depende literalmente del código de un extraño de Internet. Para decirlo de esta manera, todo suena muy inseguro. ¿Por qué alguien estaría de acuerdo con esto?

Estamos de acuerdo, porque es fácil, porque todo parece funcionar, porque todos los demás también lo hacen, y lo más importante, porque parece ser una continuación natural de una práctica establecida de siglos de antigüedad. Pero hay una diferencia importante que ignoramos.

Hace décadas, la mayoría de los desarrolladores también confiaban en que otros escribieran programas de los que dependían, como sistemas operativos y compiladores. Este software fue comprado de fuentes conocidas, a menudo con algún tipo de acuerdo de soporte. Todavía hay espacio para errores o destrucción total . Pero al menos sabíamos con quién estábamos tratando y, por regla general, podíamos usar medidas comerciales o legales de influencia.

El fenómeno del software de código abierto, que se distribuye gratuitamente a través de Internet, ha suplantado en gran medida la antigua práctica de comprar software. Cuando la reutilización aún era difícil, pocos proyectos introdujeron tales dependencias. Aunque sus licencias generalmente renuncian a cualquier "garantía de valor comercial e idoneidad para un propósito particular", los proyectos construyeron una buena reputación. Los usuarios han tenido muy en cuenta esta reputación al tomar sus decisiones. En lugar de intervenciones comerciales y legales, vino el apoyo reputacional. Muchos paquetes comunes de esa época todavía gozan de una buena reputación: por ejemplo, BLAS (publicado en 1979), Netlib (1987), libjpeg (1991), LAPACK (1992), HP STL (1994) y zlib (1995).

Los administradores de lotes han reducido el modelo de reutilización de código a una simplicidad extrema: ahora los desarrolladores pueden compartir el código con precisión para funciones individuales en docenas de líneas. Este es un gran logro técnico. Hay innumerables paquetes disponibles, y un proyecto puede incluir una gran cantidad de ellos, pero los mecanismos de confianza de código comercial, legal o de reputación son cosa del pasado. Confiamos en más código, aunque hay menos razones para confiar.

El costo de hacer una mala adicción puede verse como la suma de todos los posibles malos resultados en una serie del precio de cada mal resultado multiplicado por su probabilidad (riesgo).


El precio de un mal resultado depende del contexto en el que se utiliza la dependencia. En un extremo del espectro hay un proyecto de pasatiempo personal donde el precio de la mayoría de los malos resultados es cercano a cero: solo te diviertes, los errores no tienen un impacto real, excepto por un poco más de tiempo, y la depuración de ellos puede ser incluso divertida. Por lo tanto, la probabilidad de riesgo es casi irrelevante: se multiplica por cero. En el otro extremo del espectro está el software de producción, que debe ser compatible durante años. Aquí, el costo de la dependencia puede ser muy alto: los servidores pueden caerse, los datos confidenciales pueden divulgarse, los clientes pueden sufrir, las empresas incluso pueden ir a la quiebra. En producción, es mucho más importante evaluar y minimizar el riesgo de una falla grave.

Independientemente del precio esperado, existen algunos enfoques para evaluar y reducir los riesgos de agregar dependencias. Es probable que los administradores de paquetes se optimicen para reducir estos riesgos, mientras que hasta ahora se han centrado en reducir el costo de descarga e instalación.

Verificación de dependencia

No contrataría a un desarrollador del que nunca haya oído hablar y del que no sepa nada. Primero, aprenderá algo sobre él: verifique los enlaces, realice una entrevista, etc. Antes de depender del paquete que encontró en Internet, también es aconsejable aprender un poco sobre este paquete.

Una comprobación básica puede dar una idea de la probabilidad de problemas al intentar usar este código. Si se encuentran problemas menores durante la inspección, puede tomar medidas para eliminarlos. Si el cheque revela problemas serios, puede ser mejor no usar el paquete: puede encontrar uno más adecuado, o tal vez necesite desarrollarlo usted mismo. Recuerde que los paquetes de código abierto son publicados por los autores con la esperanza de que sean útiles, pero sin garantizar la usabilidad o el soporte. En el caso de un fallo de producción, depende de usted depurarlo. Como advirtió la primera Licencia Pública General de GNU , “todo el riesgo asociado con la calidad y el rendimiento del programa recae en usted. Si el programa resulta defectuoso, usted correrá con los costos de todo el mantenimiento, reparación o corrección necesarios ".

A continuación, describimos algunas consideraciones para verificar el paquete y decidir si depender de él.

Diseño

¿Está clara la documentación del paquete? ¿La API tiene un diseño claro? Si los autores pueden explicar bien la API y el diseño a una persona, esto aumenta la probabilidad de que también expliquen bien la implementación de la computadora en el código fuente. Escribir código para una API clara y bien diseñada es más simple, más rápido y probablemente menos propenso a errores. ¿Han documentado los autores lo que esperan del código del cliente para ser compatible con futuras actualizaciones? (Los ejemplos incluyen documentos de compatibilidad de C ++ y Go ).

Calidad del código

¿Está bien escrito el código? Lee algunos fragmentos. ¿Los autores parecen ser cuidadosos, concienzudos y consistentes? ¿Se parece al código que desea depurar? Puede que tenga que hacer esto.

Desarrolle sus propias formas sistemáticas para verificar la calidad del código. Algo simple, como compilar en C o C ++ con advertencias importantes del compilador activadas (por ejemplo, -Wall ), puede dar una idea de qué tan en serio trabajaron los desarrolladores para evitar varios comportamientos indefinidos. Los idiomas recientes, como Go, Rust y Swift, usan la palabra clave unsafe para denotar código que viola el sistema de tipos; mira cuánto código inseguro hay. También son útiles herramientas semánticas más avanzadas como Infer o SpotBugs . Las linters son menos útiles: debe ignorar los consejos estándar sobre temas como el estilo de paréntesis y centrarse en cuestiones semánticas.

No se olvide de los métodos de desarrollo con los que puede no estar familiarizado. Por ejemplo, la biblioteca SQLite viene como un archivo único con 200,000 códigos y un encabezado de 11,000 líneas, como resultado de la fusión de múltiples archivos. El tamaño de estos archivos levanta inmediatamente la bandera roja, pero una investigación más exhaustiva conducirá al código fuente real para el desarrollo: un árbol de archivos tradicional con más de cien archivos fuente C, pruebas y scripts de soporte. Resulta que la distribución de un solo archivo se crea automáticamente a partir de las fuentes originales: esto es más fácil para los usuarios finales, especialmente aquellos que no tienen administradores de dependencias. (El código compilado también funciona más rápido porque el compilador ve más opciones de optimización).

Prueba

¿Hay alguna prueba en el código? ¿Puedes controlarlos? ¿Pasan? Las pruebas establecen que la funcionalidad principal del código es correcta, y señalan que el desarrollador está tratando seriamente de mantenerlo. Por ejemplo, el árbol de desarrollo SQLite contiene un conjunto de pruebas increíblemente detallado con más de 30,000 casos de prueba individuales. Existe documentación para desarrolladores que explica la estrategia de prueba. Por otro lado, si hay pocas o ninguna prueba, o si las pruebas fallan, esto es una señal de alerta seria: es probable que los cambios futuros en el paquete conduzcan a regresiones que podrían detectarse fácilmente. Si insiste en las pruebas en su código (¿verdad?), Debe proporcionar pruebas para el código que pasa a otros.

Suponiendo que existan pruebas, ejecute y pase, puede recopilar información adicional ejecutando herramientas para analizar la cobertura del código, detectar condiciones de carrera , verificar la asignación de memoria y detectar pérdidas de memoria.

Depuración

Encuentra el rastreador de errores para este paquete. ¿Hay muchos mensajes de error abiertos? ¿Cuánto tiempo han estado abiertos? ¿Cuántos errores se corrigieron? ¿Hay algún error solucionado recientemente? Si hay muchas preguntas abiertas sobre errores reales, especialmente no cerrados durante mucho tiempo, esta es una mala señal. Por otro lado, si los errores son raros y se solucionan rápidamente, eso es genial.

Apoyo

Mira la historia de los commits. ¿Cuánto tiempo se ha mantenido activamente el código? ¿Se apoya activamente ahora? Es probable que los paquetes que han sido respaldados activamente durante un largo período de tiempo sigan siendo compatibles. ¿Cuántas personas están trabajando en el paquete? Muchos paquetes son proyectos personales que los desarrolladores crean para el entretenimiento en su tiempo libre. Otros son el resultado de miles de horas de trabajo para un grupo de desarrolladores pagados. En general, los paquetes del segundo tipo generalmente corrigen los errores más rápidamente, introducen constantemente nuevas funciones y, en general, están mejor soportados.

Por otro lado, algunos códigos son realmente "perfectos". Por ejemplo, escape-string-regexp de NPM puede que nunca necesite cambiarse nuevamente.

Uso

¿Cuántos paquetes dependen de este código? Los administradores de paquetes a menudo dan tales estadísticas, o puede ver en Internet con qué frecuencia otros desarrolladores mencionan este paquete. Un mayor número de usuarios significa al menos el hecho de que para muchos el código funciona bastante bien, y los errores en él se notarán más rápidamente. El uso generalizado también es una garantía parcial de servicio continuo: si un paquete ampliamente utilizado pierde su mantenedor, es muy probable que un usuario interesado asuma su rol.

Por ejemplo, las bibliotecas como PCRE, Boost o JUnit son increíblemente ampliamente utilizadas. Esto hace que sea más probable, aunque ciertamente no garantiza, que los errores que pueda haber encontrado ya estén corregidos porque otros los encontraron antes que usted.

Seguridad

¿Funcionará este paquete con entradas inseguras? Si es así, ¿qué tan resistente es a los datos maliciosos? ¿Tiene errores que se mencionan en la National Vulnerability Database (NVD) ?

Por ejemplo, cuando en 2006 Jeff Dean y yo comenzamos a trabajar en Google Code Search ( grep para bases de códigos públicos), la popular biblioteca de expresiones regulares PCRE parecía ser la opción obvia. Sin embargo, en una conversación con el equipo de seguridad de Google, aprendimos que PCRE tiene una larga historia de problemas, como desbordamientos de búfer, especialmente en el analizador. Nosotros mismos estábamos convencidos de esto buscando PCRE en NVD. Este descubrimiento no nos llevó inmediatamente a abandonar PCRE, sino que nos hizo pensar más cuidadosamente sobre las pruebas y el aislamiento.

Licencia

¿El código tiene la licencia correcta? ¿Tiene siquiera una licencia? ¿La licencia es aceptable para su proyecto o empresa? Una parte sorprendente de los proyectos de GitHub no tiene una licencia clara. Su proyecto o empresa puede imponer restricciones adicionales a las licencias de dependencia. Por ejemplo, Google prohíbe el uso de código bajo licencias como AGPL (demasiado estricto) y tipo WTFPL (demasiado vago).

Dependencias

¿Este paquete tiene sus propias dependencias? Las deficiencias en las dependencias indirectas son tan perjudiciales como las desventajas en las dependencias directas. Los administradores de paquetes pueden enumerar todas las dependencias transitivas de un paquete dado, y cada una de ellas idealmente debería verificarse como se describe en esta sección. Un paquete con muchas dependencias requerirá mucho trabajo.

Muchos desarrolladores nunca han mirado la lista completa de dependencias transitivas de su código y no saben de qué dependen. Por ejemplo, en marzo de 2016, la comunidad de usuarios de NPM descubrió que muchos proyectos populares, incluidos Babel, Ember y React, dependen indirectamente de un pequeño paquete llamado left-pad de una función de 8 líneas. Descubrieron esto cuando el autor de left-pad eliminó el paquete de NPM, rompiendo inadvertidamente la mayoría de los ensamblados de los usuarios de Node.js. Y el left-pad no left-pad excepcional en este sentido. Por ejemplo, el 30% de los 750,000 paquetes en NPM dependen, al menos indirectamente, de escape-string-regexp . Adaptando la observación de Leslie Lamport de los sistemas distribuidos, el administrador de paquetes crea fácilmente una situación en la que una falla del paquete, cuya existencia ni siquiera conocía, podría inutilizar su propio código.

Pruebas de adicción

El proceso de verificación debe incluir la ejecución de sus propias pruebas de paquetes. Si el paquete pasó la prueba y usted decide hacer que su proyecto dependa de él, el siguiente paso debería ser escribir nuevas pruebas enfocadas específicamente en la funcionalidad de su aplicación. Estas pruebas a menudo comienzan como programas cortos e independientes para garantizar que pueda comprender el paquete API y que haga lo que piensa (si no puede entender o no hace lo que necesita, ¡deténgase de inmediato!). Entonces vale la pena el esfuerzo adicional para convertir estos programas en pruebas automatizadas que se ejecutarán con nuevas versiones del paquete. Si encuentra un error y tiene una solución potencial, puede reiniciar fácilmente estas pruebas para un proyecto específico y asegurarse de que la solución no rompa nada más.

Se debe prestar especial atención a las áreas problemáticas identificadas durante la revisión de línea de base. Para la búsqueda de código, por experiencia previa, sabíamos que PCRE a veces tarda mucho tiempo en ejecutar ciertas expresiones regulares. Nuestro plan inicial era crear grupos de hilos separados para expresiones regulares "simples" y "complejas". Una de las primeras pruebas fue un punto de referencia que comparó pcregrep con varias otras implementaciones de grep . Cuando descubrimos que pcregrep era 70 veces más lento que el grep más rápido para un caso de prueba básico, comenzamos a repensar nuestro plan para usar PCRE. A pesar de que finalmente abandonamos por completo PCRE, esta prueba permanece en nuestra base de código hoy.

Abstracción de dependencia

La dependencia del paquete es una solución de la que puede optar en el futuro. Quizás las actualizaciones llevarán el paquete en una nueva dirección. Se pueden encontrar serios problemas de seguridad. Quizás aparezca la mejor opción. Por todas estas razones, vale la pena simplificar la migración del proyecto a una nueva dependencia.

Si se llama a un paquete desde muchos lugares en el código fuente del proyecto, deberá realizar cambios en todos estos lugares diferentes para cambiar a una nueva dependencia. Peor aún, si el paquete se presenta en la API de su propio proyecto, la migración a una nueva dependencia requerirá realizar cambios en todo el código que llama a su API, y esto puede estar fuera de su control. Para evitar tales costos, tiene sentido definir su propia interfaz junto con un envoltorio delgado que implementa esta interfaz utilizando una dependencia. Tenga en cuenta que el contenedor debe incluir solo lo que el proyecto necesita de la dependencia, y no todo lo que ofrece la dependencia. Idealmente, esto le permite reemplazar más tarde otra dependencia igualmente adecuada, cambiando solo el contenedor.La migración de las pruebas para que cada proyecto use la nueva interfaz verifica la implementación de la interfaz y los contenedores, y también simplifica la prueba de cualquier posible reemplazo para la dependencia.

Para la búsqueda de código, hemos desarrollado una clase abstracta Regexpque define la interfaz de búsqueda de código necesaria desde cualquier motor de expresión regular. Luego escribieron una envoltura delgada alrededor de PCRE que implementa esta interfaz. Este método facilitó la prueba de bibliotecas alternativas y evitó la introducción accidental del conocimiento de los componentes internos de PCRE en el resto del árbol de origen. Esto, a su vez, asegura que, si es necesario, será fácil cambiar a otra dependencia.

Aislamiento de dependencia

También puede ser apropiado aislar la dependencia en tiempo de ejecución para limitar el posible daño causado por errores en ella. Por ejemplo, Google Chrome permite a los usuarios agregar dependencias al navegador: código de extensión. Cuando Chrome se lanzó por primera vez en 2008, introdujo una función crítica (ahora estándar en todos los navegadores) para aislar cada extensión en un entorno limitado que se ejecuta en un proceso separado del sistema operativo. Un posible exploit en una extensión mal escrita no tenía acceso automático a toda la memoria del navegador.y no pudo hacer llamadas inapropiadas al sistema. Para la búsqueda de código, hasta que descartamos el PCRE por completo, el plan era aislar al menos el analizador PCRE en un entorno limitado similar. Hoy, otra opción sería un sandbox ligero basado en hipervisor, como gVisor . El aislamiento de dependencia reduce los riesgos asociados de ejecutar este código.

Incluso con estos ejemplos y otras opciones listas para usar, aislar código sospechoso en tiempo de ejecución sigue siendo demasiado complicado y rara vez se realiza. El verdadero aislamiento requerirá un lenguaje completamente seguro para la memoria, sin chocar con un código sin tipo. Estos son complejos no solo en lenguajes completamente inseguros, como C y C ++, sino también en lenguajes que proporcionan restringir operaciones inseguras, como Java cuando JNI está activado, o como Go, Rust y Swift cuando habilita sus funciones inseguras. Incluso en un lenguaje seguro para la memoria como JavaScript, el código a menudo tiene acceso a mucho más de lo que necesita. En noviembre de 2018, resultó que la última versión del paquete npm event-stream(una API de transmisión funcional para eventos JavaScript) contiene código malicioso confusoagregó hace dos meses y medio. El código recopiló billeteras bitcoin de los usuarios de la aplicación móvil Copay, obtuvo acceso a recursos del sistema completamente ajenos al procesamiento de flujos de eventos. Una de las muchas formas posibles de protegerse contra este tipo de problemas sería un mejor aislamiento de la dependencia.

Abandono de la adicción.

Si la adicción parece demasiado arriesgada y no puede aislarla, la mejor opción puede ser abandonarla por completo, o al menos excluir las partes más problemáticas.

Por ejemplo, cuando entendemos mejor los riesgos de PCRE, nuestro plan para Google Code Search cambió de "usar la biblioteca PCRE directamente" a "usar PCRE, pero poner el analizador en la caja de arena", luego en "escribir un nuevo analizador de expresiones regulares, pero guardar el motor PCRE", luego en "escriba un nuevo analizador y conéctelo a otro motor de código abierto más eficiente". Más tarde, Jeff Dean y yo reescribimos el motor también, por lo que no quedaban dependencias y descubrimos el resultado: RE2 .

Si solo necesita una pequeña parte de la dependencia, la forma más fácil es hacer una copia de lo que necesita (por supuesto, mantener los derechos de autor relevantes y otros avisos legales). Usted asume la responsabilidad de la corrección de errores, el mantenimiento, etc., pero también está completamente aislado de los riesgos mayores. Hay un dicho en la comunidad de desarrolladores de Go : "Un poco de copia es mejor que un poco de dependencia".

Actualización de dependencia

Durante mucho tiempo, la sabiduría generalmente aceptada en el software fue: "Si funciona, no toque nada". La actualización conlleva el riesgo de introducir nuevos errores; sin recompensa: si no necesita una nueva función, ¿por qué arriesgarse? Este enfoque ignora dos aspectos. Primero, el costo de una actualización gradual. En el software, la complejidad de realizar cambios en el código no se escala linealmente: diez pequeños cambios son menos trabajosos y más fáciles que un gran cambio correspondiente. En segundo lugar, la dificultad de detectar errores ya corregidos. Especialmente en el contexto de seguridad, donde los errores conocidos se explotan activamente, todos los días sin actualizar aumentan los riesgos de que los atacantes puedan aprovechar los errores en el código anterior.

Por ejemplo, considere la historia de Equifax 2017, que los ejecutivos contaron en detalle en testimonios ante el Congreso. El 7 de marzo, se descubrió una nueva vulnerabilidad en Apache Struts y se lanzó una versión parcheada. El 8 de marzo, Equifax recibió una notificación de US-CERT sobre la necesidad de actualizar cualquier uso de Apache Struts. Equifax lanzó un escaneo del código fuente y la red el 9 y 15 de marzo, respectivamente; ni una sola exploración encontró servidores web vulnerables abiertos en Internet. El 13 de mayo, los atacantes encontraron servidores que los expertos de Equifax no encontraron. Utilizaron la vulnerabilidad Apache Struts para piratear la red Equifax y robaron información personal y financiera detallada sobre 148 millones de personas en los próximos dos meses. Finalmente, el 29 de julio, Equifax notó un hack y lo anunció públicamente el 4 de septiembre. A fines de septiembre, el CEO de Equifax, así como el CIO y CSO, habían renunciado y se había iniciado una investigación en el Congreso.

La experiencia de Equifax lleva al hecho de que, aunque los administradores de paquetes conocen las versiones que usan durante la compilación, necesita otros mecanismos para rastrear esta información durante la implementación en producción. Para el lenguaje Go, estamos experimentando con la inclusión automática del manifiesto de manifiesto en cada binario para que los procesos de implementación puedan escanear los binarios en busca de dependencias que requieran actualización. Go también hace que esta información esté disponible en tiempo de ejecución, para que los servidores puedan acceder a las bases de datos de errores conocidos e informar de manera independiente al sistema de monitoreo cuando necesiten actualizarse.

Una actualización rápida es importante, pero actualizar significa agregar un nuevo código al proyecto, lo que debería significar actualizar la evaluación de riesgos del uso de la dependencia en función de la nueva versión. Como mínimo, desea ver las diferencias que muestran los cambios realizados desde la versión actual a las versiones actualizadas, o al menos leer las notas de la versión para identificar las áreas problemáticas más probables en el código actualizado. Si cambia mucho código, por lo que las diferencias son difíciles de entender, esta también es información que puede incluir al actualizar su evaluación de riesgos.

Además, debe volver a ejecutar las pruebas escritas específicamente para el proyecto para asegurarse de que el paquete actualizado sea al menos tan adecuado para el proyecto como la versión anterior. También tiene sentido volver a ejecutar sus propias pruebas de paquetes. Si el paquete tiene sus propias dependencias, es posible que la configuración del proyecto use otras versiones de estas dependencias (más antiguas o más nuevas) que las utilizadas por los autores del paquete. La ejecución de sus propias pruebas de paquetes le permite identificar rápidamente problemas específicos de la configuración.

Nuevamente, las actualizaciones no tienen que ser completamente automáticas. Antes de implementar versiones actualizadas , asegúrese de que sean apropiadas para su entorno .

Si el proceso de actualización implica volver a ejecutar las pruebas de integración y calificación ya escritas, en la mayoría de los casos la demora en la actualización es más riesgosa que una actualización rápida.

La ventana para actualizaciones críticas de seguridad es especialmente pequeña. Después de que Equifax pirateó, los equipos forenses de seguridad encontraron evidencia de que los atacantes (posiblemente diferentes) explotaron con éxito la vulnerabilidad Apache Struts en los servidores afectados el 10 de marzo, solo tres días después de que se divulgara públicamente. Pero solo lanzaron un equipo allí whoami.

Cuida tus adicciones

Incluso después de todo esto, el trabajo no está terminado. Es importante continuar monitoreando las dependencias y, en algunos casos, incluso abandonarlas.

Primero, asegúrese de seguir usando versiones específicas de paquetes. La mayoría de los administradores de paquetes ahora le permiten grabar fácil o incluso automáticamente el hash criptográfico del código fuente esperado para una versión dada del paquete, y luego verificar este hash cuando el paquete se descarga nuevamente a otra computadora o en un entorno de prueba. Esto garantiza que la compilación utilizará el mismo código fuente de dependencia que probó y probó. Dichos controles impidieron al atacanteevent-stream, inyecta automáticamente código malicioso en la versión ya lanzada 3.3.5. En cambio, el atacante tuvo que crear una nueva versión 3.3.6 y esperar a que la gente se actualice (sin mirar cuidadosamente los cambios).

También es importante monitorear la aparición de nuevas dependencias indirectas: las actualizaciones pueden introducir fácilmente nuevos paquetes, de los cuales ahora depende el éxito de su proyecto. También merecen su atención. En el caso, el event-streamcódigo malicioso estaba oculto en otro paquete flatMap-stream, que event-streamse agregó como una nueva dependencia en la nueva versión .

Las dependencias progresivas también pueden afectar el tamaño del proyecto. Durante el desarrollo de Google Sawzall- Lenguaje de procesamiento de registros JIT: en diferentes momentos, los autores descubrieron que el binario del intérprete principal contiene no solo JIT Sawzall, sino también intérpretes PostScript, Python y JavaScript. Cada vez, el culpable resultó ser dependencias no utilizadas declaradas por alguna biblioteca de Sawzall, combinadas con el hecho de que el sistema de compilación de Google utilizó completamente la nueva dependencia. Es por eso que el compilador Go genera un error al importar un paquete no utilizado.

La actualización es el momento natural para revisar su decisión de utilizar una dependencia cambiante. También es importante revisar periódicamente cualquier adicción que noestá cambiando ¿Parece plausible que no haya problemas de seguridad u otros errores que corregir? ¿Se abandona el proyecto? Tal vez es hora de planificar un reemplazo para esta dependencia.

También es importante verificar dos veces el registro de seguridad de cada dependencia. Por ejemplo, Apache Struts reveló serias vulnerabilidades en la ejecución remota de código en 2016, 2017 y 2018. Incluso si tiene muchos servidores que lo inician y lo actualizan rápidamente, este historial sugiere si vale la pena usarlo.

Conclusión

La era de la reutilización del software finalmente ha llegado, y no quiero minimizar los beneficios: trajo una transformación extremadamente positiva para los desarrolladores. Sin embargo, aceptamos esta transformación sin considerar completamente las posibles consecuencias. Las razones anteriores para confiar en las dependencias pierden relevancia al mismo tiempo cuando tenemos más dependencias que nunca.

El análisis crítico de dependencias específicas que describí en este artículo representa una cantidad significativa de trabajo y sigue siendo la excepción más que la regla. Pero dudo que haya desarrolladores que realmente estén trabajando duro para hacer esto para cada posible nueva adicción. Solo hice parte de este trabajo para algunas de mis propias dependencias. Básicamente, toda la solución se reduce a lo siguiente: "veamos qué sucede". Con demasiada frecuencia, algo más parece demasiado esfuerzo.

Pero los ataques de Copago y Equifax son advertencias claras de problemas reales en la forma en que usamos las dependencias de software hoy en día. No debemos ignorar las advertencias. Ofrezco tres recomendaciones generales.

1. . , , , . , .
2. . , , . , , . , , , .
3. . . . , . , , . , , API. .

Hay muchos buenos programas. Trabajemos juntos y descubramos cómo usarlo de manera segura.