Catégories
Start-up et applications

Il est essentiel de garder vos composants open source à jour et sécurisés

Le 2020 récemment publié Analyse de la sécurité et des risques Open Source (OSSRA), produit par le Synopsys Cybersecurity Research Center (CyRC), a révélé que sur plus de 1250 bases de code analysées en 2019, non seulement presque 100% avaient des composants open-source, mais aussi qu'une moyenne de 70% des code était open source, près du double des 36% trouvés par le premier rapport OSSRA. Une autre mesure de l'augmentation spectaculaire de l'utilisation de l'open source est que l'OSSRA a trouvé une moyenne de 445 composants open-source par base de code en 2019, en hausse de près de 50% par rapport à 298 un an plus tôt.

Ce que les logiciels open source fournissent aux développeurs est une base qui rend le développement d'applications plus rapide, plus efficace et moins cher. C’est pourquoi la majorité des logiciels actuels sont «assemblés» à partir de composants existants plutôt qu’écrit à partir de zéro.

Si votre organisation crée ou utilise simplement des logiciels, vous pouvez supposer que les logiciels contiendront de l'open source. Si vous êtes membre d’une équipe de sécurité et que vous n’avez pas mis en place de règles pour identifier et corriger les problèmes connus avec les composants open source que votre organisation crée ou utilise, vous ne faites pas votre travail.

L'open source comporte les mêmes risques de sécurité qui affectent tous les logiciels – bogues ou autres défauts qui pourraient être exploités par des pirates. Alors que les grands projets open source ont des communautés qui émettent généralement des correctifs pour les vulnérabilités beaucoup plus rapidement que les fournisseurs commerciaux – grâce à des milliers d '«yeux» sur le code – maintenir l'open source à jour et sécurisé n'est pas aussi simple que les mises à jour automatiques, comme on le fait. pour de nombreux logiciels commerciaux. Contrairement aux fournisseurs commerciaux qui «poussent» automatiquement les correctifs vers les utilisateurs, l'open source fonctionne sur un modèle «pull». Au fur et à mesure que les correctifs sont mis à disposition, les consommateurs du composant open-source doivent d'abord être conscients que le correctif est disponible, puis doivent le «extraire» d'un référentiel pour effectuer la mise à jour nécessaire.

Mais un nombre alarmant d’entreprises qui consomment de l’open source n’appliquent pas de correctifs, s’ouvrant ainsi au risque d’attaque et leurs applications à des exploits potentiels. En fait, de nombreuses organisations sont très en retard dans l'utilisation de la dernière version d'un composant open source donné.

Comme le précise le rapport de l'OSSRA, 82% des composants open source trouvés dans les audits étaient obsolètes et 75% contenaient au moins une vulnérabilité connue. La vulnérabilité à haut risque la plus courante, CVE-2018-16487, une vulnérabilité à la pollution du prototype Lodash à haut risque affectant les versions antérieures à la 4.17.11, est apparue plus de 500 fois dans les scans OSSRA. Une autre vulnérabilité à la pollution du prototype Lodash à haut risque fréquemment trouvée dans les analyses de 2019 (495 instances) était CVE-2019-10744, affectant toutes les versions antérieures à 4.17.12. Les dangers des deux vulnérabilités vont de l'injection de propriété à l'injection de code et au déni de service. Étant donné que Lodash était le quatrième composant open source le plus couramment trouvé – utilisé dans un tiers des plus de 1 250 bases de code analysées pour le rapport OSSRA – ces vulnérabilités devraient être préoccupantes. Dans les deux cas, une mise à niveau vers une version ultérieure de Lodash résout les problèmes de sécurité.

De nombreux composants open source obsolètes sont le résultat d'un état d'esprit «insérer et oublier». Les développeurs n'ajoutent généralement pas d'informations sur la version d'un composant à la feuille de calcul d'inventaire avant de passer à un autre travail. Ensuite, tant que le code continue de fonctionner comme il est censé le faire, il est ignoré et finalement oublié, jusqu'à ce qu'il se casse ou soit exploité.

Sans politiques en place pour faire face aux risques que les versions obsolètes des composants open source peuvent créer, les organisations s'ouvrent à la possibilité de problèmes dans leurs logiciels. Les équipes de sécurité et de développement doivent travailler ensemble pour créer et maintenir un inventaire des logiciels à jour et précis – a.k.a. une nomenclature logicielle ou «nomenclature». Une nomenclature complète comprendra tous les composants open source et tiers, les versions en cours d'utilisation et les emplacements de téléchargement pour chaque projet. La nomenclature doit également inclure toutes les dépendances, ou les bibliothèques auxquelles le code appelle, ainsi que les bibliothèques auxquelles ces dépendances sont liées. Armé de la nomenclature, vous pouvez désormais identifier et gérer les risques de l'open source que vous utilisez, que ces risques impliquent la conformité des licences, des facteurs opérationnels ou des problèmes de sécurité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *