Los peligros de la dependencia del código de terceros

Si se suscribe a un servicio desde un enlace en esta página, Reeves and Sons Limited puede ganar una comisión. Vea nuestro Declaración de Ética.

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 "Desarrollado por Fulano de Tal", es testigo de este efecto de colaboración en acción.

Y, por supuesto, la razón principal por la que a la gente le gusta compartir y colaborar con terceros es que puede ahorrarle muchas horas de tiempo de desarrollo, porque no está reinventando algo que ya existe.

Pero incluso con estos grandes beneficios del sistema de código compartido de terceros, hay muchas razones por las que es posible que desees 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 capacitado generalmente puede hacer un buen trabajo al ocultar la naturaleza maliciosa del código, y solo otro programador altamente capacitado podrá averiguar 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 puede ser un error.

En particular, sería un error si alguna condición del acuerdo de licencia provocara que usted infrinja 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 el código, no tiene control sobre él y es posible que no necesariamente comprenda todo lo que hace o cómo funciona.

Eso significa que si alguien hace algún cambio en el código, usted puede quedarse con ese cambio, especialmente si instala fielmente actualizaciones, parches, mejoras y nuevas versiones tan pronto como se lanzan como estables, o si confía completamente en 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 características adicionales que no necesita y que probablemente nunca usará.

En algunos casos, esas funciones adicionales no se pueden eliminar fácilmente o incluso no se pueden eliminar. Es posible que también tengas que hacer concesiones. La función puede hacer algo muy parecido a lo que usted pretende, pero no exactamente lo que pretende. Estás intercambiando genialidad por tener menos trabajo que hacer, y ese no siempre es un buen intercambio.

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 causar problemas.

Hoy en día, muchos desarrolladores ni siquiera instalan los fragmentos que están utilizando, sino que los extraen en tiempo de ejecución de las redes de entrega de contenido bajo demanda. El peligro de esto quedó ilustrado espectacularmente por el incidente del Left-Pad de 2016.

Cada cadena es tan fuerte como su eslabón más débil. Este encadenamiento de dependencias significa que si algún eslabón en cualquier lugar de la cadena se rompe o se ve comprometido, toda la cadena corre el riesgo de funcionar mal. En algunas situaciones, eso podría resultar bastante costoso.

Nadie habría sospechado el poder contenido en las 11 líneas de código contenidas en esa pequeña y benigna función llamada Left-Pad, pero cuando ese eslabón de cadena en particular falló, detuvo a muchos sitios web importantes.

La mayor parte 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 punto 2, si no lo posee, es posible que no necesariamente lo comprenda.

Left-Pad era una función muy simple que simplemente 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 usaban software que la incluía, incluidos Netflix, Facebook y Reddit. Fue sólo un golpe de buena suerte que en este caso fuera una función muy simple la que rompiera 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.

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.

Comentarios Comentarios 0

Deje un comentario

Su dirección de correo electrónico no será publicada. Las areas obligatorias están marcadas como requeridas *

Clasificación *

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.