La récente découverte d'une porte dérobée dans l'utilitaire de compression de données XZ Utils, présent dans presque toutes les principales distributions Linux, rappelle brutalement que les organisations qui consomment des composants open source sont en fin de compte responsables de la sécurisation des logiciels.

XZ Utils, comme des milliers d'autres projets open source, est géré par des bénévoles et, dans son cas, est géré par un seul responsable. De tels projets disposent souvent de peu ou pas de ressources pour gérer les problèmes de sécurité, ce qui signifie que les organisations utilisent le logiciel à leurs propres risques. Cela signifie que les équipes de sécurité et de développement doivent mettre en œuvre des mesures pour gérer les risques open source de la même manière qu'elles le font avec le code développé en interne, affirment les experts en sécurité.

« Bien qu'il soit peu probable qu'une organisation puisse prévenir efficacement [toute] l'exposition aux risques liés à la chaîne d'approvisionnement, les organisations peuvent tout à fait se concentrer sur une stratégie visant à réduire la probabilité de réussite d'une attaque contre la chaîne d'approvisionnement », déclare Jamie Scott, chef de produit fondateur chez Endor Labs.

L'open source n'est pas la même chose que l'externalisation : « Les mainteneurs de logiciels open source sont des bénévoles. Au niveau industriel, nous devons les traiter comme tels. Nous possédons notre logiciel ; nous sommes responsables des logiciels que nous réutilisons.

Bien intentionné et sous-financé

Préoccupations concernant la sécurité des logiciels open source ne sont en aucun cas nouveaux. Mais il faut souvent des découvertes comme celle Vulnérabilité Log4Shell et par porte dérobée dans XZ Utils pour vraiment faire comprendre à quel point les organisations sont vulnérables aux composants de leur code. Et souvent, le code provient de projets open source bien intentionnés mais désespérément sous-financés et peu entretenus.

XZ Utils, par exemple, est essentiellement un projet mené par une seule personne. Un autre individu a réussi à faufiler la porte dérobée dans l'utilitaire sur une période de près de trois ans, en gagnant progressivement suffisamment de confiance de la part du responsable du projet. Si un développeur Microsoft ne l'avait pas découvert fin mars en enquêtant sur un comportement étrange associé à une installation Debian, la porte dérobée aurait pu se retrouver sur des millions d'appareils dans le monde, y compris ceux appartenant à de grandes entreprises et à des agences gouvernementales. Il s'est avéré que la porte dérobée a eu un impact minime car elle affectait les versions de XZ Utils qui n'étaient présentes que dans les versions instables et bêta de Debian, Fedora, Kali, open SUSE et Arch Linux.

La prochaine compromission du code open source pourrait être bien pire. « Le plus effrayant pour les entreprises est que leurs applications sont construites sur des projets logiciels open source, tout comme XZ Utils », déclare Donald Fischer, co-fondateur et PDG de Tidelift. « XZ Utils est un package parmi des dizaines de milliers qui sont utilisés chaque jour par des entreprises typiques », explique-t-il.

La plupart de ces organisations ne disposent pas d'une visibilité suffisante sur la sécurité et la résilience de cette partie de leur chaîne d'approvisionnement logicielle pour pouvoir évaluer les risques, note-t-il.

Une Harvard Business School L’étude estime que la valeur de la demande de logiciels open source s’élève à la somme étonnante de 8.8 44 milliards de dollars. Les responsables sont au cœur de cet écosystème et nombre d’entre eux volent seuls, explique Fischer. Une enquête menée par Tidelift l'année dernière a révélé que XNUMX % des responsables de projets open source se décrivent comme les seuls responsables de leurs projets. Soixante pour cent se sont identifiés comme des amateurs non rémunérés, et le même pourcentage a déclaré avoir abandonné ou envisagé de quitter son rôle de responsable de projet. De nombreux responsables ont décrit leurs efforts comme un travail stressant, solitaire et financièrement ingrat, explique Fischer.

« Le piratage de XZ utils met en évidence les risques liés au sous-investissement dans la santé et la résilience de la chaîne d'approvisionnement des logiciels open source sur laquelle s'appuient les entreprises », déclare Fischer. « Les entreprises doivent comprendre que la majorité des packages open source les plus fiables sont gérés par des bénévoles qui se décrivent comme des amateurs non rémunérés. Ces responsables ne sont pas des fournisseurs d’entreprise, mais ils sont censés travailler et livrer comme eux.

Danger : dépendances transitives

A étude menée par Endor en 2022, a révélé que 95 % des vulnérabilités open source sont présentes dans des dépendances dites transitives, ou dans des packages ou bibliothèques open source secondaires dont un package open source principal pourrait dépendre. Il s'agit souvent de packages que les développeurs ne sélectionnent pas directement eux-mêmes, mais qui sont automatiquement utilisés par un package open source dans leur projet de développement.

« Par exemple, lorsque vous faites confiance à un package Maven, il y a en moyenne 14 dépendances supplémentaires auxquelles vous faites implicitement confiance », explique Scott. « Ce nombre est encore plus important dans certains écosystèmes logiciels tels que NPM, où vous importez en moyenne 77 autres composants logiciels pour chacun en qui vous avez confiance.

Une façon de commencer à atténuer les risques liés à l’open source est de prêter attention à ces dépendances et d’être sélectif quant aux projets que vous choisissez, dit-il.

Les organisations devraient vérifier les dépendances, en particulier les petits packages ponctuels, gérés par des équipes d'une ou deux personnes, ajoute Dimitri Stiliadis, CTO d'Endor et co-fondateur. Ils doivent déterminer si les dépendances dans leur environnement disposent de contrôles de sécurité appropriés ou si une seule personne valide tout le code ; s'ils ont des fichiers binaires dans leurs référentiels dont personne n'est au courant ; ou même si quelqu'un maintient activement le projet, dit Stiliadis.

« Concentrez vos efforts sur l'amélioration de l'efficacité de votre réponse : les contrôles fondamentaux tels que le maintien d'un inventaire logiciel mature restent l'un des programmes les plus rentables que vous puissiez mettre en place pour identifier, évaluer et répondre rapidement aux risques logiciels une fois qu'ils sont identifiés », Scott conseille.

Les outils d'analyse de la composition logicielle, les scanners de vulnérabilités, les systèmes EDR/XDR et les SBOM peuvent également aider les organisations à identifier rapidement les composants open source vulnérables et compromis.

Reconnaître la menace

"Atténuer l'exposition commence par une compréhension partagée et une reconnaissance au sein de la haute direction et même au niveau du conseil d'administration du fait qu'environ 70 % des ingrédients d'un produit logiciel moyen sont des logiciels open source historiquement créés par des contributeurs pour la plupart non rémunérés", explique Fischer de Tidelift.  

Les nouvelles réglementations et directives du secteur des services financiers, de la FDA et du NIST façonneront la manière dont les logiciels seront développés dans les années à venir et les organisations doivent s'y préparer dès maintenant. « Les gagnants ici s'adapteront rapidement d'une stratégie réactive à une stratégie proactive de gestion des risques liés à l'open source », dit-il.

Fischer recommande aux organisations de demander à leurs équipes de sécurité et d'ingénierie d'identifier comment les nouveaux composants open source arrivent dans leur environnement. Ils doivent également définir des rôles pour surveiller ces composants et supprimer de manière proactive ceux qui ne correspondent pas à l'appétit pour le risque de l'entreprise. « Réagir aux problèmes à un stade avancé est devenu un moyen inefficace de faire face à l'ampleur du risque pour l'entreprise au cours des dernières années, et le Le gouvernement américain signale cette époque touche à sa fin », dit-il.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security