Los peligros de la dependencia del código de terceros

Hay algunas cosas realmente buenas acerca de la forma en que el software funciona en Internet. Para empezar, hay una gran red no oficial de millones de personas que contribuyen a un gran repositorio de fragmentos de código que ayudan a impulsar muchos más millones de aplicaciones.

Cada vez que ve un pequeño enlace en la parte inferior de una página web que dice "Powered by So-And-So", está presenciando este efecto de colaboración en acción.

Y, por supuesto, la razón principal por la que a las personas les gusta este intercambio y colaboración de terceros es que puede ahorrarle muchas horas en el tiempo de desarrollo, porque no está reinventando algo que ya existe. Pero incluso con estos grandes beneficios del sistema de intercambio de código de terceros, hay muchas razones por las que podría querer evitar el uso de esos fragmentos de código, como estamos a punto de ver ...

1. Riesgos potenciales de seguridad.

Debido a que casi todos los códigos que manejan cualquier cosa en la Web son de código abierto, es una apuesta justa que si hay alguna carga útil malintencionada en una aplicación determinada, la comunidad de desarrolladores la descubrirá rápidamente y la corregirá rápidamente.

Pero muchos de estos fragmentos de código se descargan cientos o incluso miles de veces al día, y no todos los equipos administrativos están haciendo un buen trabajo al mantener un sistema de intercambio de códigos seguro.

Cuanto más grande y compleja es una aplicación, más fácil es infectarla agregando algunas líneas de código en algún lugar oscuro. Casi nadie se toma el tiempo de analizar cada línea de código en una aplicación, porque generalmente asumen que el código es confiable.

Un programador altamente calificado generalmente puede hacer un buen trabajo de ofuscar la naturaleza maliciosa del código, y solo otro programador altamente calificado descubrirá cuál es su propósito ... si se detecta el fragmento de código malicioso.

2. Tu no lo posees

Esto es en realidad una combinación de problemas. La primera es que puede estar sujeto a varios términos de licencia. Cuando tiene varios fragmentos de código utilizados en una sola página web o aplicación, puede estar sujeto a varios términos y condiciones de licencia diferentes, y algunos de ellos pueden estar en conflicto entre sí.

Por supuesto, casi nadie se molesta en leer estas tediosas listas de términos y condiciones, pero eso potencialmente puede ser un error. En particular, sería un error si alguna condición en el acuerdo de licencia causara que usted esté violando alguna ley en su país de origen o en el país donde se encuentra su servidor.

El otro problema es que si no posee código, no tiene control sobre él, y es posible que no comprenda necesariamente todo lo que hace o cómo funciona. Eso significa que si alguien realiza algún cambio en el código, es posible que se quede estancado con ese cambio, especialmente si instala fielmente actualizaciones, parches, actualizaciones y nuevas versiones tan pronto como se publiquen como estables, o si depende completamente de la entrega de contenido. Redes para sus soluciones de terceros.

3. A menudo obtienes mucho más de lo que necesitas

El código de terceros generalmente funciona para hacer el trabajo que desea, pero a veces contiene todo tipo de funciones adicionales que no necesita y que probablemente nunca usará. En algunos casos, no puede eliminar esas funciones adicionales fácilmente o incluso en absoluto. También puede tener que hacer un compromiso. La función puede hacer algo muy cercano a lo que pretende, pero no exactamente lo que desea. Estás intercambiando cosas increíbles por tener menos trabajo que hacer, y eso no siempre es un buen negocio.

4. Los múltiples niveles de dependencia de terceros pueden llevar a problemas reales

Muchos proyectos de código abierto utilizan los mismos fragmentos de código de terceros de diferentes maneras para producir su software. La mayoría de las veces eso no es malo, pero puede llevar a problemas. En estos días, muchos desarrolladores ni siquiera instalan los fragmentos que están usando, sino que los extraen en tiempo de ejecución de las redes de entrega de contenido bajo demanda. El peligro de esto fue ilustrado espectacularmente por el Incidente Left-Pad de 2016.

Cada cadena es tan fuerte como su eslabón más débil. Este encadenamiento de dependencias significa que si se rompe o compromete cualquier enlace en cualquier lugar a lo largo de la cadena, toda la cadena corre el riesgo de un mal funcionamiento. En algunas situaciones eso podría ser bastante costoso. Nadie hubiera sospechado el poder contenido en las líneas de código 11 contenidas en esa pequeña función benigna llamada Left-Pad, pero cuando ese enlace de cadena en particular falló, detuvo a muchos grandes sitios web. La mayor parte de esto fue que la mayoría de las personas que usaban Left-Pad no tenían idea de que lo estaban usando, qué hacía o cómo solucionar el problema. Como se indica en el artículo 2, si no lo posee, es posible que no lo entienda necesariamente.

Left-Pad fue una función muy simple que solo agrega algunos espacios al lado izquierdo de una línea para asegurarse de que la línea tenga la longitud correcta. Ahora el problema aquí es que cualquier programador competente podría replicar esa funcionalidad fácilmente. No hay absolutamente ninguna necesidad de que ninguna aplicación dependa de esta función de terceros, y sin embargo, miles de sitios web utilizaban el software que lo incluía, incluidos Netflix, Facebook y Reddit. Fue solo un golpe de suerte que en este caso fue una función muy simple que rompió la cadena, y no una función realmente complicada que tuviera su propia cadena de dependencias.

La conclusión es que si puedes construirlo tú mismo, ¡probablemente deberías!

En última instancia, la decisión de utilizar bloques de código de terceros en su proyecto se reduce a una serie de decisiones complicadas que nunca deben tomarse a la ligera. Los factores que debe considerar son la seguridad, la legalidad, el costo, el tiempo y la estabilidad.

Para simplificar el proceso de decisión, la siguiente condición de prueba probablemente ayude.

SI alguno de estos factores es verdadero:

  • la función que quieres es simple
  • Usted (o su equipo) tiene la capacidad de crear la función
  • Hay mucho tiempo para crear la función.
  • su aplicación necesita buena seguridad
  • Le preocupan los posibles problemas legales relacionados con la licencia de terceros.
  • Es importante que tu aplicación nunca falle.

ENTONCES debes construirlo tú mismo,

ELSE puede ser más eficiente usar las funciones de terceros, siempre que esté al tanto de los problemas potenciales y tenga una estrategia implementada para lo que hará si surgen esos problemas.

imagen del encabezado cortesía de Stephanie Tucker

Bogdan Rancea

Bogdan es miembro fundador de Inspired Mag, habiendo acumulado casi 6 años de experiencia durante este período. En su tiempo libre le gusta estudiar música clásica y explorar artes visuales. También está bastante obsesionado con los fixies. Ya es dueño de 5.