Les dangers de la dépendance au code de tiers

Il y a quelques très bonnes choses sur la façon dont les logiciels fonctionnent sur Internet. Tout d’abord, il existe un vaste réseau non officiel de millions de personnes qui contribuent à un vaste référentiel de fragments de code qui permet d’alimenter de nombreux autres millions d’applications.

Chaque fois que vous voyez un petit lien au bas d'une page Web indiquant «Propulsé par untel», vous êtes témoin de cet effet collaboratif en action.

Et bien sûr, la principale raison pour laquelle les gens aiment le partage et la collaboration avec des tiers est que cela peut vous faire gagner de nombreuses heures en développement, car vous ne réinventez pas quelque chose qui existe déjà. Mais même avec ces avantages considérables du système de partage de code tiers, il existe de nombreuses raisons pour lesquelles vous voudrez peut-être éviter d'utiliser ces fragments de code, comme nous allons le voir…

1.Les risques de sécurité potentiels

Étant donné que presque tout le code qui régit tout ce qui est sur le Web est open source, il est fort à parier que s'il existe des données malveillantes dans une application donnée, elles seront rapidement détectées par la communauté des développeurs et corrigées rapidement.

Mais beaucoup de ces fragments de code sont téléchargés des centaines, voire des milliers de fois par jour, et toutes les équipes administratives ne parviennent pas à maintenir un système de partage de code sécurisé.

Plus une application est grande et complexe, plus il est facile de l'infecter en ajoutant quelques lignes de code dans un endroit obscur. Presque personne ne prend le temps d'analyser chaque ligne de code d'une application, car ils supposent généralement que le code est fiable.

Un programmeur hautement qualifié peut généralement faire de son mieux pour masquer la nature malveillante du code, et seul un autre programmeur hautement qualifié déterminera son rôle… si le fragment de code malveillant est détecté.

2. Vous ne le possédez pas

C'est en fait une combinaison de problèmes. La première est que vous pouvez être soumis à diverses conditions de licence. Lorsque vous utilisez plusieurs fragments de code dans une même page Web ou application, vous pouvez être soumis à plusieurs termes et conditions de licence différents, et certains d'entre eux peuvent même être en conflit.

Bien sûr, presque personne ne se soucie de lire ces listes de termes et conditions fastidieuses, mais cela peut potentiellement être une erreur. En particulier, ce serait une erreur si une condition du contrat de licence vous faisait violer une loi de votre pays d'origine ou du pays où votre serveur est situé.

L'autre problème est que si vous ne possédez pas de code, vous n'avez aucun contrôle sur celui-ci et vous ne comprenez pas nécessairement tout ce qu'il fait ou comment il fonctionne. Cela signifie que si quelqu'un apporte des modifications au code, vous risquez d'être bloqué par cette modification, en particulier si vous installez fidèlement les mises à jour, les correctifs, les mises à niveau et les nouvelles versions dès leur parution stable, ou si vous vous fiez entièrement à la livraison de contenu. réseaux pour vos solutions tierces.

3. Vous obtenez souvent beaucoup plus que ce dont vous avez besoin

Le code tiers permet généralement de faire le travail que vous voulez, mais il contient parfois toutes sortes de fonctionnalités supplémentaires dont vous n’avez pas besoin et que vous n’utiliserez probablement jamais. Dans certains cas, vous ne pouvez pas supprimer ces fonctionnalités supplémentaires facilement, ni même du tout. Vous devrez peut-être aussi faire des compromis. La fonctionnalité peut faire quelque chose de très proche de ce que vous souhaitez, mais pas exactement de ce que vous souhaitez. Vous échangez de la génialité pour avoir moins de travail à faire, et ce n'est pas toujours un bon métier.

4. Plusieurs niveaux de dépendance vis-à-vis de tiers peuvent entraîner de réels problèmes

De nombreux projets open source utilisent les mêmes fragments de code tiers de différentes manières pour produire leurs logiciels. La plupart du temps, ce n'est pas une mauvaise chose, mais cela peut entraîner des problèmes. De nos jours, de nombreux développeurs n’installent même pas les fragments qu’ils utilisent, mais les extraient, au moment de l’exécution, des réseaux de diffusion de contenu à la demande. Le danger de ceci a été illustré de manière spectaculaire par l’incident de 2016 sur la gauche.

Chaque chaîne est aussi forte que son maillon le plus faible. Cet enchaînement de dépendances signifie que si un lien quelconque au long de la chaîne est brisé ou compromis, toute la chaîne risque de mal fonctionner. Dans certaines situations, cela pourrait être assez coûteux. Personne n'aurait soupçonné le pouvoir contenu dans les lignes de code 11 contenues dans cette petite fonction bénigne appelée Left-Pad, mais lorsque ce lien de chaîne en particulier a échoué, de nombreux grands sites Web ont été interrompus. La majeure partie de cela était que la plupart des gens qui utilisaient Left-Pad ne savaient pas qu'ils l'utilisaient, ce qu'ils utilisaient ou comment résoudre le problème. Comme indiqué à l'article 2, si vous ne le possédez pas, vous ne pouvez pas nécessairement le comprendre.

Left-Pad est une fonction très simple qui ajoute juste quelques espaces sur le côté gauche d'une ligne pour s'assurer que la longueur de la ligne est correcte. Maintenant, le problème est que tout programmeur compétent pourrait facilement reproduire cette fonctionnalité. Aucune application ne dépend absolument de cette fonction tierce. Pourtant, des milliers de sites Web utilisaient un logiciel qui l'incluait, notamment Netflix, Facebook et Reddit. Heureusement, dans ce cas, il s’agissait d’une fonction très simple qui rompait la chaîne, et non d’une fonction très compliquée dotée de sa propre chaîne de dépendances.

En bout de ligne, si vous pouvez le construire vous-même, vous devriez probablement!

En fin de compte, la décision d'utiliser ou non des blocs de code tiers dans votre projet se résume à une série de décisions complexes qui ne doivent jamais être prises à la légère. Les facteurs à prendre en compte sont la sécurité, la légalité, les coûts, les délais et la stabilité.

Pour simplifier le processus de décision, les conditions de test suivantes seront probablement utiles.

SI l'un de ces facteurs est vrai:

  • la fonction que vous voulez est simple
  • vous (ou votre équipe) avez la possibilité de créer la fonction
  • il y a beaucoup de temps pour créer la fonction
  • votre application a besoin d'une bonne sécurité
  • vous êtes préoccupé par les problèmes juridiques potentiels liés aux licences tierces
  • il est important que votre application ne échoue jamais

ALORS vous devriez le construire vous-même,

SINON, il peut être plus efficace d’utiliser les fonctions tierces, à condition que vous soyez au courant des problèmes potentiels et que vous ayez une stratégie en place pour ce que vous ferez si de tels problèmes se posent.

image d'en-tête avec la permission de Stéphanie Tucker

Bogdan Rancea

Bogdan est un membre fondateur d’Inspired Mag, ayant accumulé près de 14 années d’expérience 6 au cours de cette période. Dans ses temps libres, il aime étudier la musique classique et explorer les arts visuels. Il est également obsédé par les fixies. Il possède déjà 5.