Les data scientists rappellent l'utilisation du code open source en raison de problèmes de sécurité PlatoBlockchain Data Intelligence. Recherche verticale. Aï.

Les scientifiques des données rappellent l'utilisation du code open source en raison de problèmes de sécurité

Les vulnérabilités des composants open source, telles que les failles généralisées révélées il y a 10 mois dans Log4j 2.0, ont obligé les data scientists à réévaluer le code open source fréquemment utilisé dans l'analyse et la création de modèles d'apprentissage automatique.

Selon un rapport d'Anaconda, une société de plateforme de science des données, au cours de l'année écoulée, 40 % des data scientists, analystes commerciaux et étudiants interrogés ont réduit leur utilisation des composants open source, tandis qu'un tiers est resté stable, et seulement 7 % ont incorporé davantage de code open source dans leurs projets. La majorité des personnes interrogées ne relèvent pas du département informatique (18 %), mais travaillent au sein de leur propre groupe de science des données ou de recherche et développement (47 %), selon Anaconda «État de la science des données 2022 » rapport, publié la semaine dernière.

Alors que les développeurs de logiciels et les services informatiques ont déjà commencé à examiner le code sécurisé, les préoccupations concernant la sécurité des logiciels open source constituent une tendance relativement nouvelle dans le monde de la science des données, explique Peter Wang, co-fondateur et PDG d'Anaconda.

« Nous voyons un nombre considérable de personnes travailler dans des organisations où l'informatique a créé une posture très stricte autour de l'open source et de Python », dit-il. « Ce ne sont pas des développeurs experts. … Ce sont des data scientists et des spécialistes de l'apprentissage automatique qui ne sont peut-être pas du tout des développeurs très expérimentés, utilisant tout ce qu'ils pouvaient télécharger pour effectuer leur analyse, puis ils ont transmis cela au service informatique.

La sécurité des composants open source – et de la chaîne d’approvisionnement logicielle en général – est devenue une préoccupation majeure parmi les développeurs de logiciels, les entreprises et les gouvernements nationaux au cours des deux dernières années. En mai, par exemple, le National Institute of Standards and Technology (NIST) des États-Unis publié des directives pour gérer les risques liés à la chaîne d'approvisionnement en logiciels. De plus, un nombre croissant d'éditeurs de logiciels se sont joints à l'Open Software Security Foundation (OpenSSF) de la Linux Foundation.

Alors que de nombreuses équipes de science des données analysent les composants open source à la recherche de vulnérabilités, nombreuses sont celles qui créent leur propre logiciel à la place. Source : rapport « 2022 State of Data Science » d'Anaconda.

Dans l’ensemble, la maturité des efforts de sécurité des organisations s’est améliorée. Environ la moitié des entreprises ont mis en place une politique de sécurité open source, ce qui conduit à de meilleures performances en matière de mesures de préparation à la sécurité, selon l'enquête de juin. En outre, les efforts visant à contrôler les risques liés à l'open source ont bondi de 51 % au cours des 12 derniers mois. une étude sur la maturité de la sécurité a déclaré le Sept. 21.

«[G]avec l'attention portée aux chaînes d'approvisionnement logicielles, la plupart des entreprises adoptent une approche de la sécurité des applications basée sur les risques», a déclaré Jason Schmitt, directeur général du Synopsys Software Integrity Group, dans un communiqué annonçant l'étude. « Une telle approche reconnaît que la sécurité ne se limite pas à la base de code ; cela inclut le processus de développement de logiciels dans lequel les examens et les tests de sécurité « se déplacent partout » pour améliorer continuellement les résultats en matière de sécurité.

Les développeurs étendent l'utilisation de l'Open Source 

Les éditeurs de logiciels ne constatent aucune diminution de l’utilisation de l’open source, selon d’autres données. Au lieu de cela, les organisations de développement se concentrent sur l’amélioration de la sécurité des logiciels open source et utilisent la sécurité comme guide principal dans la sélection des composants.

Dans le "État 2021 de la chaîne d’approvisionnement logicielle » rapport, par exemple, Sonatype a constaté que les quatre principaux écosystèmes open source – le référentiel central Maven (Java), Node.js (JavaScript), le Python Package Index (Python) et la galerie NuGet (.NET) – abritaient 37 millions de personnes. projets et composants open source, soit une augmentation de 20 % d'une année sur l'autre. La demande pour ces composants augmente également : plus de 2.2 73 milliards de composants ont été téléchargés, soit une augmentation annuelle de XNUMX %.

Selon Tracy Miranda, responsable de l'open source chez Chainguard, l'abandon autodéclaré des packages open source par la communauté de la science des données est probablement le signe d'une plus grande sensibilisation aux problèmes de sécurité et d'une moindre prise en compte de l'abandon des composants open source en cours de développement.

Même si les équipes de science des données et les équipes de développement ont pu réagir différemment aux problèmes de sécurité majeurs, comme Log4j 2.0 — Les entreprises n'ont guère de recours lorsqu'elles abandonnent un package open source que d'adopter un package différent dont les responsables ont mis davantage l'accent sur la sécurité, dit-elle.

« Les entreprises exploitent l’open source comme moyen d’augmenter leur vélocité. Par conséquent, si elles réduisent leurs effectifs, vers quoi réduiront-elles leurs activités ? Écrire du code en interne ? Utiliser des versions tierces emballées ? » Miranda dit, ajoutant qu'à la place, "je pense que nous pouvons nous attendre à voir les entreprises faire preuve de plus de discernement quant à la qualité de l'open source qu'elles utilisent, notamment en ce qui concerne les fonctionnalités de sécurité."

Les data scientists rattrapent leur retard

Le fossé entre les deux côtés est probablement dû aux différents publics visés par les différentes enquêtes. L'enquête d'Anaconda s'est concentrée sur les professionnels de la science des données, comme le montre le choix de langages de programmation des personnes interrogées : 58 % ont utilisé Python et 42 % ont utilisé SQL, tandis que seulement 26 % ont utilisé JavaScript. 

Une meilleure mesure des sentiments des développeurs de logiciels est « » de StackOverflow.Sondage des développeurs 2022», qui a révélé que si 58 % des « personnes apprenant à coder » utilisent Python, seuls 44 % des développeurs professionnels codent dans ce langage. D'un autre côté, 68 % des développeurs professionnels utilisent JavaScript, selon l'enquête de StackOverflow.

En outre, alors que les professionnels de la science des données travaillent dans des entreprises qui autorisent majoritairement (87 %) les logiciels open source, environ un quart (26 %) ont une surveillance minimale de la part du service informatique sur leurs choix open source, indique le rapport Anaconda. Dans 18 % des entreprises, le service informatique ne spécifie qu'environ la moitié des composants open source disponibles.

Les responsables des projets les plus critiques – il y en a des centaines, voire des milliers – doivent utiliser des dépendances sécurisées, tester leur propre code et valider la fiabilité des contributeurs. Les responsables devraient également publier une carte de score de sécurité – une initiative créée par Google désormais gérée par l'Open Source Security Foundation (OpenSSF), qui attribue une note de sécurité à un projet selon près de 20 critères différents.

Bien que la prise de conscience augmente probablement, il n’existe pas de solution rapide, dit Miranda.

« La réalité est que les options les plus sûres n’existaient pas auparavant », dit-elle. « Réduire les dépendances inutiles pour réduire la surface d'attaque est judicieux, mais c'est difficile à faire une fois que l'arborescence des dépendances est devenue grande. »

Horodatage:

Plus de Lecture sombre