open source
Les entreprises informatiques ont été les premières à utiliser l’open source, puis d’autres grandes entreprises ont suivi. Après tout, la possibilité de réutiliser, modifier indépendamment un code et corriger des bugs a encouragé une innovation rapide et une réduction des coûts.
L’open source a tout de même quelques caractéristiques négatives inhérentes, à cause du manque de clarté quant aux responsabilités en termes de création et de maintien du code. Endor Labs, avec l’aide de 20 CISO et CTO de grandes entreprises informatiques, a réalisé une analyse systématique pour élaborer ce top 10 des risques.
Les vulnérabilités connues
Le risque identifié comme étant le plus important est la présence de vulnérabilités dans le projet open source lui-même et dans ses dépendances, c’est-à-dire dans les composants open source externes utilisés pour le projet. Les vulnérabilités des dépendances peuvent provoquer de graves problèmes pour des dizaines de grands ensembles de programmes commerciaux, comme ça a été le cas avec la bibliothèque Log4j d’Apache (CVE-2021-44228).
Précautions : Analysez régulièrement les applications pour rechercher les vulnérabilités connues, qu’elles soient dans les dépendances directes ou indirectes. Installez les corrections disponibles dès que possible. Pour optimiser les ressources de votre entreprise, vous pouvez classer les patchs par ordre de priorité selon la sévérité de la vulnérabilité et la probabilité qu’elle soit exploitée dans le programme que vous utilisez.
Les packages légitimes compromis
Étant donné que près de 80 % du code d’un projet open source provient d’autres projets sous la forme de dépendances, il est toujours possible que certains des composants tiers que votre application utilise aient été infectés par un cheval de Troie. Cela peut arriver lorsque le développeur des composants est piraté, ou lorsque le système de distribution des composants (autrement dit, le gestionnaire de package) contient une vulnérabilité qui permet le spoofing du paquet. Dans ce cas, un code malveillant tiers apparaît soudainement au sein de l’application qui, en pratique, est souvent utilisé pour voler des informations ou pour réaliser diverses activités illicites d’enrichissement (spam, arnaques avec un adware ou encore minage).
Précautions : Il n’existe actuellement aucune méthodologie mâture qui permet de se protéger contre ces menaces. Vous devez utiliser plusieurs mesures à la fois : des systèmes automatiques et manuels qui analysent le code source et surveillent les répertoires, le stockage local des versions fiables des composants, et l’utilisation de la Threat Intelligence pour détecter ces attaques à un stade précoce (avant qu’elles n’aient le temps de nuire aux packages utilisés par les applications open source de votre entreprise).
L’attaque des « homonymes »
Les cybercriminels créent des packages qui ont un nom similaire aux paquets légitimes, ou copient les noms de paquets légitimes écrits dans un autre langage de programmation ou partagés sur d’autres plateformes de distribution. Les développeurs de votre application open source risquent d’intégrer un package malveillant « homonyme » au lieu de l’authentique.
Précautions : Apprenez à vos développeurs à faire attention. Selon la procédure normale, les développeurs doivent vérifier le code source des packages avant de l’utiliser et contrôler qu’il n’y a rien de bizarre, comme des fragments chiffrés dans le code, des fonctions piratées ou autre. Il est également conseillé de vérifier les signatures électroniques des paquets (le cas échéant).
Le code est incompatible
Les développeurs de composants, packages et applications open source peuvent interrompre l’assistance à tout moment et pour toute raison. Cela arrive souvent avec les petits packages développés par 1 ou 2 personnes. Si vous êtes dans cette situation, personne ne peut mettre à jour le paquet pour qu’il soit compatible avec les nouvelles technologies et personne ne peut supprimer les risques de sécurité informatique.
Précautions : Évaluez la maturité du projet et les perspectives de développement et d’assistance avant de l’intégrer dans les processus de votre entreprise et dans votre code. Faites attention au nombre de développeurs qui permettent le maintien du projet et à la fréquence de sortie des mises à jour. Vérifiez les versions de support à long terme et leur sortie. Pourtant, s’il s’agit d’un projet assez stable, il est normal que les mises à jour soient occasionnelles et destinées à corriger des bugs.
Le programme est obsolète
L’utilisation de vieilles versions des composants pour les projets rend l’installation des correctifs plus difficile. Ce problème est particulièrement important lorsque le risque le plus grave se présente : les composants sont vulnérables. De façon générale, le problème des dépendances obsolètes apparaît lorsque la nouvelle version d’un composant diffère sensiblement de celles des itérations précédentes en termes de syntaxe ou de sémantique. Dans ce cas, une version obsolète peut être utilisée pendant des années sans mise à jour de sécurité.
Précautions : Laissez aux développeurs le temps de travailler avec les dépendances, et notamment de retravailler votre code pour installer les dernières versions des composants utilisés.
Les dépendances ne sont pas suivies
Étant donné que presque toutes les applications utilisent des composants tiers qui, à leur tour, utilisent d’autres composants tiers, il arrive que les développeurs de l’application principale ne sachent pas que leur code utilise un composant en particulier. Dans ce cas, ils ne le vérifient pas et tous les risques précédents ne sont pas contrôlés.
Précautions : Établissez une nomenclature logistique des programmes (SBOM) détaillée et utilisez des outils d’analyse capables de détecter les dépendances utilisées sans gestionnaire de package.
Les risques réglementaires et de licence
Même si c’est open source, chaque application et package open source a sa propre licence d’utilisation. Les risques apparaissent lorsque la licence est incompatible avec l’utilisation de l’application aux fins proposées, ou que les licences de certains composants de l’application sont incompatibles. Il se peut aussi qu’un ou plusieurs composants de dépendance enfreignent certaines lois ou exigences réglementaires en vigueur et imposées par l’entreprise.
Précautions : Le BOM mentionné ci-dessus et les outils d’analyse du code doivent être utilisés pour contrôler les licences et les exigences relatives aux licences qui concernent les applications et les composants open source utilisés au sein de l’entreprise. Il convient de travailler avec votre service juridique pour développer une liste des licences standard applicables à l’entreprise et pour détailler leur compatibilité avec le but du programme utilisé. Les programmes sans licence, ou dont la licence est incompatible, doivent être immédiatement supprimés.
Le programme est immature
L’utilisation de composants développés par une équipe qui manque de maturité implique un certain nombre de désagréments et de risques. Voici certains des problèmes associés à l’immaturité d’un programme : documentation insuffisante ou inexacte du code, instabilité, opérations sujettes à erreur et absence d’un ensemble de tests pour les tests de régression. De plus, le code immature est plus susceptible de contenir des vulnérabilités critiques. C’est pour toutes ces raisons que le programme immature n’est pas pratique à utiliser et qu’il augmente les coûts impliqués et les risques d’événements critiques ou de temps d’arrêt.
Précautions : Avant de déployer une application ou un composant, vérifiez que les développeurs utilisent les meilleures pratiques actuelles. Certains indicateurs sont la possession d’une documentation complète et mise à jour, l’existence de pipelines d’intégration et de distribution continues (CI/CD) pour les tests de régression ainsi que la mise à disposition d’informations détaillées sur la couverture des tests et même sur le nombre de packages qui utilisent déjà le composant en question.
Les modifications ne sont pas approuvées
Les composants utilisés par une application peuvent changer sans que les développeurs ne le remarquent. Cette situation peut se produire si les composants sont téléchargés à partir d’un serveur sans contrôle strict de la version et/ou à partir de canaux de communication non chiffrés, et ne sont pas vérifiés à l’aide du hachage ou de la signature électronique. Dans ce cas, l’assemblage de l’application peut théoriquement avoir un résultat différent à chaque fois.
Précautions : Soyez strict lorsqu’il s’agit d’appliquer des pratiques de développement sûres. Lors du développement, utilisez des identifiants de ressources qui indiquent clairement la version du composant. Ensuite, vérifiez les composants téléchargés à l’aide des signatures électroniques. Enfin, utilisez toujours des protocoles de communication sécurisés.
Les dépendances sont trop grandes ou trop petites
De nos jours, les développeurs peuvent intégrer un composant avec seulement trois lignes de code. D’autre part, la situation est tout aussi mauvaise lorsque le composant entier ne contient que quatre lignes de code (ce qui est très petit) ou que vous essayez d’utiliser le code pour une seule fonctionnalité parmi les milliers du composant ; l’application de l’entreprise n’utilise pas les autres. Dans ce cas, les développeurs sont chargés du maintien d’une multitude de dépendances alors qu’il s’agit d’une fonctionnalité très réduite.
Précautions : Évitez les dépendances avec peu de fonctionnalités. Développez la fonctionnalité en question au sein de l’application principale
Conseils