Kate Stewart est directrice principale des programmes stratégiques, responsable du programme Open Compliance à la Linux Foundation englobant les projets liés à SPDX, OpenChain et Automating Compliance Tooling. Dans cette interview, nous parlons de la dernière version et du rôle qu’elle joue dans la chaîne d’approvisionnement des logiciels open source.

Voici une transcription de notre entretien.

Swapnil Bhartiya: Bonjour, c’est Swapnil Bhartiya, et aujourd’hui, nous accueillons à nouveau Kate Stewart, directrice principale des programmes stratégiques à la Linux Foundation. Commençons donc par SPDX. Dites-nous, qu’y a-t-il de nouveau dans cette spécification?

Kate Stewart: Eh bien, la spécification SPDX a publié il y a à peine un mois l’auto 2.2 et ce que nous avons fait avec cela, c’est d’ajouter beaucoup plus de fonctionnalités que les gens voulaient pour leurs cas d’utilisation, plus de relations, et puis nous avons été travailler avec les constructeurs automobiles japonais qui souhaitaient une version allégée. Il y a donc beaucoup de technologies vraiment nouvelles dans la spécification SPDX 2.2. Et je pense que nous sommes actuellement à un stade où il est assez bon qu’il y ait suffisamment de gens qui l’utilisent, nous voulons probablement le transmettre à l’ISO. Nous avons donc reformaté le document et nous allons commencer à le soumettre en ISO pour qu’il devienne une spécification internationale. Et cela arrive.

Swapnil Bhartiya: Pouvez-vous nous dire si quelque chose de plus a été ajouté à la spécification 2.2. Aussi, je voudrais parler de certains des cas d’utilisation depuis que vous avez mentionné le constructeur automobile. Mais avant cela, je veux juste parler de tout ce qui est nouveau dans la spécification elle-même.

Kate Stewart: Donc, dans les spécifications 2.2, nous avons beaucoup plus de relations. Les gens voulaient être en mesure de gérer certains des cas d’utilisation qui proviennent des conteneurs maintenant. Et ils voulaient donc pouvoir commencer à être en mesure d’exprimer cela et de le préciser. Nous travaillons également avec la NTIA. Fondamentalement, ils ont une nomenclature logicielle ou des groupes de travail SBoM, et SPDX est l’un des formats qui a été adopté. Et leur groupe de cadrage a voulu voir certaines fonctionnalités afin que nous puissions spécifier des inconnues connues. Cela a donc également été ajouté à la spécification.

Et puis il y a comment vous pouvez réellement capturer des avis puisque c’est quelque chose que les gens veulent utiliser. La licence l’a réclamé et nous n’avions pas de moyen propre de le faire, c’est pourquoi certains de nos fournisseurs d’outils l’ont fondamentalement demandé. Pas les vendeurs, je suppose qu’il y a des partenaires, il y a des projets open source qui voulaient pouvoir capturer ce truc. Et nous devions donc leur donner un moyen de les aider.

Nous nous efforçons actuellement de nous assurer que SPDX peut être utile dans les outils et que nous pouvons faire en sorte que l’automatisation se produise dans tout l’écosystème. Vous savez, que ce soit lorsque vous construisez un binaire à envoyer à quelqu’un ou à tester, vous voulez avoir votre SBoM. Lorsque vous avez téléchargé quelque chose sur Internet, vous voulez avoir votre SBoM. Lorsque vous l’expédiez à votre client, vous voulez être en mesure d’être très explicite et clair sur ce qu’il y a, car vous devez disposer de ce niveau de détail pour pouvoir suivre les vulnérabilités.

Parce qu’en ce moment environ, je suppose, 19… Je pense qu’il y avait une statistique du début de l’année tirée de l’un des sondages. Et je peux le trouver pour vous si vous le souhaitez, mais je pense que 99% de tout le code qui a été scanné par Synopsys l’année dernière contenait de l’open source. Et dont 70% de l’ensemble des matériaux de construction étaient open source. L’open source est partout. Et ce que nous devons faire, c’est pouvoir travailler avec et être en mesure d’adhérer aux licences, et la transparence sur les licences est importante, tout comme être en mesure de savoir ce que vous avez, afin que vous puissiez corriger toutes les vulnérabilités.

Swapnil Bhartiya: Vous avez mentionné deux ou trois choses ici. L’un était, vous avez mentionné l’outillage. Je suis donc un peu curieux de savoir quel type d’outillage existe déjà? Que ce soit open source ou open source, qu’il s’agisse essentiellement de la commercialisation qui a fonctionné avec les documents SPDX.

Kate Stewart: En fait, j’ai un document qui répertorie essentiellement tous ces outils que nous avons pu trouver et d’autres apparaissent au fil de la journée. Nous avons des outils communs. Comme, certains des projets de la Linux Foundation travaillent certainement avec. Comme FOSSology, par exemple, est capable à la fois de consommer et de générer du SPDX. Donc, si vous avez un document SPDX et que vous voulez le récupérer et le vérifier par rapport à vos sources pour vous assurer qu’il correspond et que personne ne l’a falsifié, l’outil FOSSology peut vous permettre de le faire assez facilement et de coder là-bas que peut générer des FOSSology.

Free Software Foundation Europe a un outil Lindt dans son projet REUSE qui générera essentiellement un document SPDX si vous utilisez les ID. Je suppose qu’il y en a en fait beaucoup plus. Donc, comme je l’ai dit, j’ai un document avec une liste d’environ 30 à 40, et évidemment les outils SPDX sont là. Nous avons un validateur en ligne gratuit. Donc, si quelqu’un vous donne un document SPDX, vous pouvez le coller dans ce validateur, et il vous dira s’il s’agit d’un document SPDX valide ou non. Et nous y attendons.

Je trouve également des outils qui émergent, dont le décodage, que nous intégrerons bientôt dans le parapluie Act, qui envisage de transformer les balises SPDX et SWID, un autre format couramment utilisé. Nous avons donc des outils qui émergent et nous nous assurons que ce que nous avons avec SPDX est utilisable pour les développeurs d’outils et que nous avons des bibliothèques pour SPDX pour les aider en Java, Python et Go. J’espère donc que nous verrons plus d’outils arriver et qu’ils généreront des documents SPDX et que les gens pourront partager ces informations et les rendre automatiques, ce dont nous avons besoin.

Un autre bon outil, je ne peux pas oublier celui-ci, est Tern. Et en fait, Tern, et donc ce que fait Tern, c’est un autre outil qui restera fondamentalement là et qui décomposera un conteneur et vous permettra de connaître la nomenclature à l’intérieur de ce conteneur. Vous pouvez donc y arriver. Et un autre qui émerge et que nous espérons voir plus bientôt est quelque chose appelé OSS Review Toolkit qui entre dans votre flux de factures. Et ainsi de suite lorsque vous travaillez avec cela dans votre système. Et alors que vous faites des factures, vous générez vos SBoM et vous avez des informations précises enregistrées au fur et à mesure.

Comme je l’ai dit, tout ce genre de choses devrait être en arrière-plan, cela ne devrait pas être un effort manuel qui prend beaucoup de temps. Lorsque nous avons lancé ce projet il y a 10 ans, il l’était, et nous voulions qu’il soit automatisé. Et je pense que nous arrivons enfin au stade où cela va être… Il y a suffisamment d’outillage là-bas et il y a suffisamment de construction d’un écosystème pour que cette automatisation se produise.

C’est pourquoi le faire parvenir à l’ISO et obtenir la spécification à l’ISO signifie qu’il sera plus facile pour les responsables de l’approvisionnement de spécifier qu’ils souhaitent voir l’entrée comme un document SPDX pour compléter le produit qui leur est donné afin qu’ils peut l’ingérer, le gérer et ainsi de suite. Mais en étant capable de dire que c’est une norme ISO, cela facilite beaucoup les choses dans les services d’approvisionnement.

OpenChain a reconnu que nous devions le faire et ils ont donc réussi et… OpenChain est en fait la première spécification que nous soumettons à l’ISO. Mais pour SPDX, nous le prenons également en compte, car une fois qu’ils disent que vous devez suivre le processus, vous en avez également besoin pour un format. Il est donc très logique de permettre aux gens de travailler facilement avec ces informations.

Swapnil Bhartiya: Et comme vous avez travaillé avec différents acteurs, différents de l’écosystème, quels sont certains des besoins urgents? Comme l’amélioration de l’automatisation en fait partie. Sur quels autres besoins urgents pensez-vous que la communauté doit travailler?

Kate Stewart: Donc, parmi les autres besoins urgents sur lesquels nous devons travailler, il y a plus de manuels, plus d’instructions, montrant aux gens comment faire les choses. Vous savez, nous l’avons compris, d’accord, voici comment nous pouvons le modéliser, voici comment vous pouvez représenter tous ces cas. Tout cela est connu dans la tête de certaines personnes, mais nous n’avons pas fait un bon travail pour exprimer aux gens afin que ce soit accessible pour eux et qu’ils puissent le faire.

L’une des choses qui sont passionnantes en ce moment est que la NTIA a ce groupe de travail sur la nomenclature des logiciels. Cela vient du côté de la sécurité, mais il y a plusieurs preuves de concepts qui vont avec. L’une d’elles est une preuve de concept de soins de santé. Et donc, il y a un groupe d’environ cinq à six fabricants de dispositifs, des fabricants de dispositifs médicaux qui génèrent des SBoM dans SPDX, puis les remettent aux hôpitaux pour qu’ils soient en mesure de s’assurer qu’ils peuvent les ingérer.

Et ce niveau d’amener les gens à ce niveau où ils sentent qu’ils peuvent faire ces choses, ça m’a vraiment ouvert les yeux. Vous savez, à quel point nous devons améliorer notre prise en main et améliorer l’infrastructure pour la rendre accessible. Et cela motive évidemment plus de gens à s’impliquer. Du côté des fournisseurs et du côté commercial, ainsi que de l’open source, mais cela ne serait pas arrivé, je pense, dans une large mesure pour SPDX sans cet open source et sans les projets qui l’ont déjà adopté.

Swapnil Bhartiya: Maintenant, juste du point de vue de la sensibilisation éducative, comme s’il y a un projet open source, comment peuvent-ils facilement créer des documents SBoM qui utilisent la spécification SPDX avec leurs versions et les maintenir synchronisés?

Kate Stewart: C’est exactement ce que nous aimerions voir. Nous aimerions voir les projets en amont générer essentiellement des documents SPDX au fur et à mesure de leur progression. La première étape consiste donc à utiliser les identifiants de licence SPDX pour vous assurer que vous comprenez ce que la licence doit contenir dans chaque fichier, et idéalement, vous pouvez documenter avec des eTags. Mais ensuite, il existe trois ou quatre outils qui les analysent et qui génèrent un document SPDX pour vous.

Si vous travaillez en ligne de commande, l’outil REUSE Lindt que j’ai mentionné de Free Software Foundation Europe fonctionnera très rapidement et rapidement avec ce que vous avez. Et cela vous aidera également à vous assurer que tous vos fichiers sont correctement balisés.

Si vous n’avez pas fait tous les exercices de marquage et que vous vous demandez [inaudible 00:09:40] ce que vous avez, un code d’analyse fonctionne sur la ligne de commande, et il vous donnera également ces informations. Et puis si vous voulez commencer à travailler dans un système plus grand et que vous voulez stocker les résultats et regarder les choses au fil du temps, et avoir un état derrière tout cela, comme s’il y avait différentes versions des choses au fil du temps, FOSSology se souviendra d’une version à l’autre. un autre et vous aidera à créer ces [inaudible 00:10:01] hors des factures.

Swapnil Bhartiya: Pouvez-vous parler de certains des nouveaux cas d’utilisation que vous voyez actuellement, auxquels vous ne vous attendiez peut-être pas plus tôt et qui montrent également comment l’ensemble de la communauté se développe réellement?

Kate Stewart: Oh ouais. Eh bien, lorsque nous avons lancé le projet il y a 10 ans, nous ne comprenions pas les conteneurs. Ils n’étaient même pas dans l’état d’esprit brut des gens. Et il y a beaucoup d’informations dans des conteneurs. Nous avons eu de très bonnes discussions ces dernières années qui illustrent les problèmes. Il y avait un rapport qui a été publié par la Fondation Linux par Armijn Hemel, qui va dans les détails de ce qui se passe dans les conteneurs et de certaines des préoccupations.

Donc, être capable de maîtriser l’automatisation, ce qui se passe avec inquiétude à l’intérieur d’un conteneur et ce que vous expédiez et sachant que vous n’en expédiez pas plus que nécessaire, déterminer comment nous pouvons améliorer ce genre de choses est certainement un domaine auquel on n’a pas pensé au départ.

Nous avons également constaté un immense intérêt pour ce qui se passe dans l’espace IOT. Et pour que vous ayez besoin de vraiment comprendre ce qui se passe dans vos appareils lorsqu’ils sont déployés sur le terrain et de savoir si oui ou non, la vulnérabilité va le briser, ou pouvez-vous récupérer? Des choses comme ça. Au cours des 10 dernières années, nous avons vu un éventail impressionnant de choses que nous n’avions tout simplement pas prévues. Et ce qui est bien avec SPDX, c’est que vous avez un cas d’utilisation que nous ne pouvons pas représenter. Si nous ne pouvons pas vous dire comment faire, ouvrez simplement un problème, et nous commencerons à essayer de le résoudre et à déterminer si nous devons ajouter des champs pour vous ou des choses comme ça.

Swapnil Bhartiya: Kate, merci beaucoup d’avoir pris votre temps et de m’avoir parlé aujourd’hui de ce projet.