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

Les logiciels sont au cœur de toutes les entreprises modernes et jouent un rôle crucial dans tous les aspects des opérations. Presque toutes les entreprises utiliseront des logiciels open source, sciemment ou non, puisque même les logiciels propriétaires dépendent de bibliothèques open source. OpenUK Le rapport « State of Open » de 2022 révèle que 89 % des entreprises s'appuient sur des logiciels open source, mais toutes ne connaissent pas clairement les détails des logiciels sur lesquels elles s'appuient.

Les entreprises exigent de plus en plus d’informations sur leurs logiciels essentiels à leurs opérations. Les entreprises responsables s'intéressent de près à leur chaîne d'approvisionnement en logiciels 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 immédiatement savoir quels logiciels et versions sont utilisés, ainsi que quels systèmes sont affectés. La connaissance, c'est le pouvoir dans ces situations !

Le recours aux bénévoles

Fin 2021, une vulnérabilité de sécurité appelée Log4Shell a été identifié dans un framework de journalisation Java largement utilisé, Log4j. Puisqu’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, le les responsables du projet étaient des bénévoles. Ils avaient un travail quotidien et n'étaient pas disponibles pour des correctifs de sécurité urgents, même si un grand nombre de systèmes étaient affectés. On estime que cette vulnérabilité à elle seule a affecté 93 % des environnements cloud d’entreprise.

À l’époque, la presse était négative à l’égard de l’open source, mais la vérité est que s’il s’agissait d’un composant à code source fermé, la vulnérabilité n’aurait peut-être jamais été rendue publique, laissant les organisations vulnérables aux attaques. La nature open source de la bibliothèque signifiait qu'elle pouvait être inspectée, les problèmes détectés et les conseils offerts par d'autres. Alors oui, les responsables n’étaient pas de garde pour des problèmes de sécurité dans leur projet bénévole. La grande question est donc la suivante : comment en sommes-nous arrivés à une situation où les grandes entreprises dépendaient de logiciels qui relevaient de la responsabilité de quelqu'un qui faisait autre chose pour payer leurs factures ?

Négliger les dépendances logicielles est une activité risquée quelle que soit la licence du logiciel, mais lorsqu’il est open source et très largement utilisé, cela devient particulièrement dangereux. 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é détecté. L’outil qui a été si largement utilisé n’a en fait pas été aussi largement soutenu – et ce qui s'est passé ensuite appartient à l'histoire.

Cette histoire se répète encore et encore, dans de nombreuses entreprises qui ont des dépendances critiques mais ne prennent aucune mesure pour soutenir ni les responsables ni les projets eux-mêmes. Avoir un SBOM pour le logiciel utilisé par une entreprise signifie qu'elle dispose des informations nécessaires. Pour les organisations qui fournissent des logiciels à des tiers, l’attente de fournir le SBOM en même temps que le code est de plus en plus la norme.

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

Apporter la connaissance des 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 ? Être capable de 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 créé elle-même cette bibliothèque, les ingénieurs de l'entreprise devraient corriger eux-mêmes chaque bug.

L'open source s'apparente davantage à un système de propriété partagée. Nous ne sommes pas tous obligés de construire la même chose à plusieurs reprises, mais pouvons plutôt contribuer, ce qui représente à la fois moins d’efforts et conduit ainsi à une meilleure qualité. L'une des choses les plus efficaces que les entreprises puissent faire est d'utiliser un peu de leurs ressources d'ingénierie et contribuer aux corrections de bugs ou aux fonctionnalités des projets qui sont au cœur de 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 lorsqu'une nouvelle version est disponible. Fondamentalement, l'entreprise a un aperçu de la santé et de l'état du projet dépendant et participe à 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, disposent d'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 aux autres collaborateurs de s'engager dans l'open source.

Une autre approche consiste à soutenir les organisations existantes pour soutenir l'open source. Le OpenSSF (Fondation de sécurité Open Source) 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 liés aux logiciels qu'elles utilisent. Une autre organisation similaire est Tidelift, qui s'associe aux responsables pour garantir que certaines exigences de base sont respectées, là encore financé par les organisations. Tidelift propose également des outils et des formations 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écurisés que les alternatives propriétaires.

C’est une décision judicieuse, mais une décision encore plus judicieuse consiste à avoir une connaissance claire de la chaîne d’approvisionnement des logiciels 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 faisait cela, le risque d'événements tels que la vulnérabilité Log4Shell serait réduit.