Language
Country/Area
No result found
Les dangers cachés des logiciels open source : votre code est-il déjà en danger ?
Dans l’environnement actuel de développement de logiciels, les logiciels open source (OSS) sont devenus le premier choix pour de nombreuses entreprises et développeurs. Cependant, saviez-vous que l’utilisation de logiciels open source comporte également des risques potentiels ? L'analyse de la composition logicielle (SCA) est une méthode qui aide les développeurs à examiner les composants open source intégrés à leur code pour vérifier s'ils sont à jour, s'ils présentent des vulnérabilités de sécurité ou s'ils sont conformes aux exigences de licence.
Les logiciels open source sont largement favorisés en raison de leur flexibilité et de leurs coûts de développement réduits, mais les risques qui les sous-tendent sont souvent négligés.
Contexte du risque
Cette approche de développement de logiciels à partir de différents composants est devenue de plus en plus courante depuis la fin des années 1990, avec l’essor des logiciels open source. Cette approche divise la complexité d’une grande base de code en parties plus petites pour augmenter la flexibilité et accélérer le processus de développement. Cependant, les risques posés par les logiciels open source augmentent clairement à mesure que davantage de composants sont utilisés, et ces risques peuvent être classés en cinq catégories principales :
- Contrôle des versions : risques des nouvelles versions
- Sécurité : risques de vulnérabilité dans les composants - Vulnérabilités et expositions courantes (CVE)
- Licences : risques liés aux exigences légales en matière de propriété intellectuelle
- Développement : risques de compatibilité entre la base de code existante et les logiciels open source
- Support : risque de documentation incomplète et de composants obsolètes
L’analyse automatisée et la gestion des risques deviennent une nécessité pour les organisations qui utilisent largement des composants open source.
Comment fonctionne SCA
Les produits SCA fonctionnent généralement comme ceci : tout d’abord, le moteur d’analyse examine le code source du logiciel et les artefacts associés utilisés pour le compiler, en identifiant les composants open source utilisés et leurs versions. Ces informations sont ensuite stockées dans une base de données, formant un catalogue des composants open source utilisés. Ce catalogue est ensuite comparé à une base de données de vulnérabilités de sécurité connues, d’exigences de licence et de versions historiques.
Par exemple, lors de la détection des vulnérabilités de sécurité, cette comparaison est souvent effectuée par rapport aux vulnérabilités de sécurité connues suivies dans la base de données nationale sur les vulnérabilités (NVD). Certains produits peuvent utiliser des bases de données de vulnérabilité propriétaires supplémentaires pour leurs vérifications. Pour la propriété intellectuelle et la conformité légale, les produits SCA extraient et évaluent les types de licences utilisées par les composants open source. Ces résultats sont généralement fournis aux utilisateurs dans différents formats numériques et comprendront des évaluations des risques et des recommandations sur les exigences légales en fonction des besoins de différents produits, en particulier les exigences en matière de licences de partage fortes ou faibles.
Les résultats peuvent également inclure un manifeste de composant de service (SBOM), qui détaille les composants open source utilisés dans l'application logicielle et leurs propriétés.
Utilisation de SCA
Étant donné que SCA a un impact sur différentes fonctions organisationnelles, différentes équipes exploitent ces données, souvent en fonction de la taille et de la structure de l'organisation. Les services informatiques utilisent SCA pour mettre en œuvre et exploiter la technologie, et les principales parties prenantes incluent le directeur de l'information (CIO), le directeur de la technologie (CTO) et l'architecte en chef de l'entreprise (EA). Les données de sécurité et d'autorisation sont souvent utilisées par le responsable de la sécurité des systèmes d'information (CISO) pour gérer les risques de sécurité, tandis que le responsable de la propriété intellectuelle/de la conformité se concentre sur les risques de propriété intellectuelle. Selon les capacités du produit SCA, ces outils peuvent être utilisés directement dans l'environnement de développement intégré (IDE) du développeur ou peuvent être utilisés comme étape nécessaire dans le processus de contrôle de la qualité du logiciel.
Avantages et inconvénients de l'ACSDans certains pays, comme les États-Unis, la nécessité de générer des SBOM est rendue obligatoire pour garantir la sécurité des logiciels fournis par les fournisseurs aux agences gouvernementales.
L'automatisation est le principal avantage des produits SCA. Lorsque les développeurs utilisent et intègrent des composants open source, il n’est pas nécessaire d’effectuer de travail manuel supplémentaire. Cela inclut également la gestion automatisée des références indirectes à d’autres composants open source. Cependant, les produits SCA actuels présentent également quelques faiblesses majeures, telles que : le processus de déploiement est complexe et prend du temps, ce qui peut prendre des mois pour être pleinement opérationnel ; chaque produit utilise sa propre bibliothèque de composants OSS propriétaire, la taille et la couverture de ces bibliothèques sont limités ; les taux peuvent varier considérablement ; et les données sur la vulnérabilité se limitent souvent à signaler uniquement les vulnérabilités qui ont été officiellement signalées dans le NVD.
En outre, les produits SCA manquent souvent de conseils automatisés, de recommandations inadéquates sur les actions à entreprendre sur les données dans les rapports et de peu de conseils sur les exigences légales pour les licences OSS détectées.
Dans ce contexte, réfléchissez-vous également à la manière de gérer plus efficacement les risques potentiels des logiciels open source et de protéger votre code contre les menaces ?
