Les estimations actuelles disent que 70 à 90 % de software utilise l'open source. Mais à quel point l'open source est-il sécurisé ? Les packages open source sont partagés par les développeurs dans le monde entier. Par conséquent, l'utilisation de l'open source dans vos propres applications signifie l'introduction de code tiers dans vos projets. Cela peut introduire des risques de sécurité, et plus un package open source est largement utilisé, plus l'impact qu'une vulnérabilité de sécurité à l'intérieur peut avoir est important.
A nouveau projet de recherche de Snyk et de la fondation Linux axé sur la façon dont les organisations sécurisent leurs packages open source. Le projet a examiné comment les développeurs détectent et gèrent les risques. Une analyse approfondie des données collectées a révélé certains faux pas majeurs que les organisations prennent en matière de sécurité open source. Voici trois étapes que les organisations peuvent prendre pour corriger ces faux pas et s'engager sur la voie de pratiques de sécurité plus solides autour de l'open source.
1. Comprendre que les dépendances apportent de la complexité
Le projet moyen a 49 vulnérabilités couvrant 79 dépendances directes.
Sécurité open source devient un plus grand défi à mesure que software la chaîne d'approvisionnement devient plus complexe. Presque toutes les applications modernes sont construites avec des composants qui dépendent d'autres composants, créant une chaîne d'approvisionnement qui implique des centaines de composants et des dépendances à plusieurs niveaux.
La software La chaîne d'approvisionnement est un point d'entrée attrayant pour les acteurs malveillants, car ils peuvent tirer parti des vulnérabilités des petites bibliothèques largement utilisées. Vous vous souvenez de Log4Shell ? Cela rendait toutes les données entrantes enregistrées vulnérables aux attaques RCE (exécution de code à distance). C'était une faiblesse critique à l'intérieur d'un framework de journalisation open source populaire - une vulnérabilité à l'intérieur d'une dépendance.
Seulement 24 % des organisations sont confiantes dans la sécurité de leurs dépendances directes. Et tandis que 37 % des organisations déclarent que les dépendances sont faciles à suivre, ces dépendances ne sont pas nécessairement dans un état sécurisé.
2. Jetez les bases avec des politiques de sécurité
Seulement 49 % des organisations ont une politique de sécurité qui traite explicitement du développement et de l'utilisation de packages open source.
Cela est compréhensible dans les petites organisations, où les ressources sont limitées. Les recherches ont également montré que 27 % des moyennes et grandes entreprises n'ont pas mis en place de politique de sécurité établie. Lorsque vous considérez la quantité de données que chacune de ces entreprises pourrait traiter, 27 % est une statistique alarmante.
Chaque organisation a besoin d'un RSSI (chef de la sécurité de l'information) ou d'une personne ou team chargé des principales responsabilités en matière de sécurité. Lorsque les fonctionnalités clés du CISO sont présentes et disponibles, une politique de sécurité open source suivra. Des politiques exploitables doivent être mises en place et socialisées à travers teams — en commençant par les RSSI et les développeurs, et en se déplaçant dans toute l'organisation.
3. Utilisez les bons outils
73 % des organisations recherchent les meilleures pratiques pour améliorer leur software sécurité.
Les organisations doivent investir dans un ensemble diversifié d'outils pour les aider à créer des applications plus sécurisées. Dans de nombreux cas, SCA (software analyse de la composition) outils peuvent fournir un avantage considérable en permettant teams pour trouver les vulnérabilités dans les packages open source et apprendre à les corriger. Certaines organisations utilisent d'autres outils en fonction de leurs préférences en matière de tests de sécurité.
Les outils SAST (tests de sécurité des applications statiques), utilisés dans 35 % des organisations, analysent le code source, le bytecode et le code binaire afin d'identifier les schémas de codage problématiques. Certaines organisations utilisent un modèle IaC (infrastructure en tant que code) pour aider les développeurs à écrire des configurations sécurisées HashiCorp Terraform, AWS CloudFormation, Kubernetes et Azure Resource Manager (ARM) avant d'entrer en production. Les configurations IaC intègrent les meilleures pratiques de sécurité directement dans les workflows de développement.
Chacune de ces options d'outillage peut aider les organisations à faire un grand pas en avant vers la priorisation de la sécurité open source.
Le pouvoir combiné de l'éducation, des politiques et des outils
L'utilisation de packages open source en toute sécurité nécessite une nouvelle façon de penser à la sécurité des développeurs que de nombreuses organisations n'ont pas encore adoptée. Savoir quels risques existent dans les packages open source et comprendre comment créer une protection contre ces risques peut permettre à votre organisation d'utiliser la technologie open source de manière efficace et sûre. Trouver les outils et les politiques les plus efficaces pour la sécurité open source est un excellent point de départ.