Négliger les développeurs open source met Internet en danger

Le logiciel est au cœur de toutes les entreprises modernes et est crucial dans tous les aspects des opérations. Presque toutes les entreprises utiliseront des logiciels open source, sciemment ou non, car même les logiciels propriétaires dépendent de bibliothèques open source. Le rapport « State of Open » d’OpenUK en 2022 a révélé que 89% des entreprises s’appuyaient sur des logiciels open source, mais toutes ne sont pas claires sur les détails des logiciels sur lesquels elles s’appuient.

Les entreprises demandent de plus en plus d’informations sur leurs logiciels critiques. Les entreprises responsables s’intéressent de près à leur chaîne d’approvisionnement logicielle et créent une nomenclature logicielle (SBOM) pour chaque application. Ce niveau d’information est crucial pour que, lorsque des failles de sécurité sont identifiées dans leurs logiciels, ils puissent être immédiatement certains des logiciels et des versions utilisés, et des systèmes affectés. La connaissance est le pouvoir dans ces situations!

Dépendance aux bénévoles

Fin 2021, une vulnérabilité de sécurité appelée Log4Shell a été identifiée dans un framework de journalisation Java largement utilisé, Log4j. Comme il s’agit d’une bibliothèque open source largement utilisée, la vulnérabilité a été largement médiatisée et des correctifs étaient attendus. Cependant, les mainteneurs du projet étaient des bénévoles. Ils avaient des emplois de jour et n’étaient pas disponibles pour des correctifs de sécurité urgents, même si un grand nombre de systèmes étaient touchés. On estime que cette vulnérabilité à elle seule a affecté 93 % des environnements cloud d’entreprise.

À l’époque, il y avait une presse négative à propos de l’open source, mais la vérité est que s’il s’agissait d’un composant à source fermée, la vulnérabilité n’aurait peut-être jamais été connue publiquement, laissant les organisations ouvertes aux attaques. La nature open source de la bibliothèque signifiait qu’elle pouvait être inspectée, les problèmes trouvés et des conseils offerts par d’autres. Donc, oui, les mainteneurs n’étaient pas de garde pour des problèmes de sécurité dans leur projet de volontariat. La grande question, alors, est la suivante : comment en sommes-nous arrivés à une situation où les grandes entreprises dépendaient de logiciels qui étaient la responsabilité de quelqu’un qui fait autre chose pour payer leurs factures ?

La négligence des dépendances logicielles est une activité risquée quelle que soit la licence du logiciel, mais lorsqu’elle est open source et très largement utilisée, elle devient particulièrement dangereuse. S’en tenir à l’histoire d’une vulnérabilité ; le problème existait dans la base de code depuis des années, mais n’a pas été repéré. L’outil qui était si largement utilisé n’était pas, en fait, si largement soutenu et ce qui s’est passé ensuite appartient à l’histoire.

Cette histoire se répète encore et encore, dans tant d’entreprises qui ont des dépendances critiques mais qui ne prennent aucune mesure pour soutenir les mainteneurs ou les projets eux-mêmes. Avoir un SBOM pour le logiciel utilisé par une entreprise signifie qu’ils ont les informations à portée de main. Pour les organisations qui fournissent des logiciels à d’autres, l’attente de fournir le SBOM avec le code est de plus en plus la norme.

Connaître les dépendances pour évaluer les risques

Connaître les dépendances permet d’évaluer plus facilement le risque associé à chacune. Ces projets open source sont les plus simples à évaluer : les problèmes ont-ils été résolus et y a-t-il eu des versions récemment ? Pouvoir voir les responsables et l’activité du projet pour chaque projet donne un bon aperçu de la santé du projet.

Les entreprises peuvent jouer leur rôle pour réduire les risques en soutenant les projets dont elles dépendent. Certains projets acceptent le parrainage directement via le programme GitHub Sponsors, d’autres pourraient plutôt apprécier des offres d’hébergement ou un audit de sécurité. Chaque projet open source apprécie les contributions. Si votre entreprise avait elle-même créé cette bibliothèque, les ingénieurs de l’entreprise devraient corriger eux-mêmes chaque bogue.

L’open source ressemble plus à un système de propriété partagée. Nous n’avons pas tous besoin de construire la même chose à plusieurs reprises, mais nous pouvons plutôt contribuer, ce qui représente à la fois moins d’efforts et, par conséquent, une meilleure qualité. L’une des choses les plus percutantes que les entreprises peuvent faire est d’utiliser un peu de leurs ressources d’ingénierie et de contribuer aux corrections de bogues ou aux fonctionnalités de projets qui sont si essentiels à l’entreprise.

Garder vos propres ingénieurs impliqués dans un projet présente de nombreux avantages. Ils apprennent à le connaître et peuvent garder un œil sur les nouvelles fonctionnalités ou sur la disponibilité d’une nouvelle version. Fondamentalement, l’entreprise a un aperçu de la santé et de l’état du projet dépendant et fait partie de ce qui le maintient en bonne santé, réduisant ainsi le risque pour l’entreprise d’un problème avec une dépendance. Un certain nombre d’organisations, dont Aiven, ont un OSPO (bureau de programme open source), avec du personnel dédié à contribuer ou même à maintenir les projets utilisés par l’organisation. Ces départements contribuent souvent à la présence générale de l’entreprise dans l’écosystème open source et permettent à d’autres employés de s’engager avec l’open source.

Une autre approche consiste à soutenir les organisations qui existent pour soutenir l’open source. L’OpenSSF (Open Source Security Foundation) travaille à améliorer la sécurité des projets open source et est financé par les organisations qui dépendent de ces projets. Il publie également d’excellentes ressources d’apprentissage afin que les entreprises puissent se renseigner sur les risques des logiciels qu’elles utilisent. Une autre organisation similaire est Tidelift, qui s’associe à des mainteneurs pour s’assurer que certaines exigences de base sont satisfaites, encore une fois financées par les organisations. Tidelift fournit également des outils et une formation pour aider les entreprises à gérer leur chaîne d’approvisionnement en logiciels et à adopter les meilleures pratiques dans ce domaine.

Assurer un avenir logiciel plus sûr

Les entreprises dépendent des logiciels, et cela inclut les logiciels open source, qui sont largement utilisés et généralement plus sûrs que les alternatives propriétaires.

C’est une décision intelligente, mais une décision encore plus intelligente consiste à avoir une connaissance claire de la chaîne d’approvisionnement logicielle et de ses dépendances. Lorsqu’un problème survient, dépendre de projets sains et disposer des détails de votre logiciel aide chaque organisation. Si chaque organisation le faisait, le risque d’avoir des événements tels que la vulnérabilité Log4Shell serait réduit.