GESTION DE LA CHAÎNE LOGISTIQUE LOGICIELLE PARTIE 2

L'avènement du développement de logiciels comme composants

L'open source faisait figure d'outsider et a fait l'objet de nombreux débats dans les années 2000, mais sa viabilité et son utilité ont fini par faire leurs preuves. Il définit désormais le secteur dans son ensemble et il ne montre aucun signe de ralentissement.

L'utilisation des composants logiciels s'accroît toujours aussi rapidement, avec plus de 2 200 milliards de téléchargements dans les quatre langages de programmation open source principaux en 2021. Dans Maven Central, 497 milliards de téléchargements ont été enregistrés rien que pour Java.

Un graphique à barres qui représente l'augmentation des téléchargements entre 2012 et 2021 (de 10 milliards à un peu moins de 500 milliards)

Total des téléchargements de composants Java open source par an.

La réalité, c'est que les logiciels ne sont plus simplement écrits, ils sont montés à partir de plusieurs pièces. Même Linux, l'une des créations les plus réussies basées sur la méthodologie open source, a été conçu dès le départ à partir de plusieurs projets de composants logiciels. Le système Linux moderne est à la fois un bénéficiaire de la chaîne logistique logicielle, et un composant dans d'autres projets.

De nos jours, il est rare qu'un logiciel soit créé de zéro. Et pourquoi les développeurs ne s’appuieraient-ils pas sur des logiciels de haute qualité en accès libre pour effectuer leurs tâches de développement ? Votre équipe bénéficie du travail de 1 000 personnes, et non pas des 10 seules personnes qui la composent. Les équipes de développement s'appuient sur des composants tiers et open source pour déployer leur code et innover plus rapidement, sans avoir à réinventer la roue. 

Ces composants sont ce que l'on appelle des « dépendances », et chacune d'entre elles présente un risque potentiel : vulnérabilités de sécurité, problèmes de licences ou problèmes de qualité. Nombre de ces dépendances reposent sur d'autres composants open source, également appelés « dépendances transitives », ce qui complique l'identification des sources de risque initiales.

Pourquoi les développeurs ne s’appuieraient-ils pas sur des logiciels de haute qualité en accès libre pour effectuer leurs tâches de développement ? Votre équipe bénéficie du travail de 1 000 personnes, et non pas des 10 seules personnes qui la composent.

Types de dépendances logicielles

Lorsqu'on parle de chaîne logistique logicielle, il est important de prendre en compte les composants et les sous-composants. Imaginez le moteur d'une voiture. Il se compose de milliers de pièces, et chacune d'entre elles provient de sa propre chaîne d'approvisionnement.

  • Dépendances directes : les composants open source sont souvent ajoutés directement au code base (ou à l'arborescence des dépendances) par les ingénieurs logiciels. De plus, une dépendance directe est directement référencée par le programme lui-même, il s'agit des « parents ». Ils contrôlent qui sont leurs enfants (dépendances transitives), et s'ils peuvent en avoir ou non.
    relations de dépendance directes
  • Dépendances transitives : elles interviennent lorsqu'une dépendance déclarée nécessite des composants open source supplémentaires pour s'exécuter correctement. Elles sont souvent problématiques, car à ce niveau, les vulnérabilités ou les problèmes de qualité sont rarement déclarés ou explorés.  Et parce qu'elles sont moins accessibles aux développeurs, les problèmes qu'elles représentent sont plus difficiles à résoudre.
    relations de dépendances transitives

En utilisant ces composants tiers dans leurs applications, les entreprises prennent la responsabilité d'un code que leurs équipes n’ont pas écrit. De même, il est essentiel de connaître les dépendances transitives de votre code InnerSource (ou du code que vous empaquetez vous-même en open source). Les risques que représentent l'Open Source Software et l'InnerSource peuvent être gérés et prévenus via l'analyse de la composition logicielle (SCA).

Nous approfondirons ce sujet lorsque nous aborderons la gestion des dépendances et la SCA plus en détail dans la Partie 4 : Gestion de la chaîne logistique logicielle : notions fondamentales.

Gestion des artefacts et repositories

Il faut comprendre que la chaîne logistique logicielle est un processus qui consiste à rassembler, gérer et distribuer des composants logiciels. Allons plus loin dans l'exploration des logiciels basés sur des composants. Un logiciel, c'est plus que du code source, c'est un ensemble d'éléments appelés des artefacts.

Qu'est-ce qu'un artefact ?

Le mot « artefact » vous évoque certainement un objet ancien conservé dans un musée, mais ce terme désigne également plus largement les créations d'une personne ou d'un groupe. Pour les développeurs de logiciels, les artefacts capturent et identifient les différentes parties de la création de logiciels, notamment le code source, les cas d'utilisation, les modèles, les exigences, les documents de conception, etc.

Ils aident les autres développeurs à comprendre le fil du développement d'un logiciel. Ces derniers peuvent alors prendre des décisions plus ciblées et mieux comprendre comment procéder.

— BAELDUNG.COM

Repository Managers

Les Repository Managers sont des serveurs qui permettent de stocker et de récupérer des artefacts. Lorsque vous écrivez un logiciel, vous devez souvent vous appuyer sur des bibliothèques externes. Vous développez un système pour lancer une fusée dans l'espace ? Vous aurez besoin d'un artefact permettant de calculer les effets de la gravité. Vous créez un site web ? Vous allez sûrement utiliser une structure conçue pour présenter du texte et des images aux visiteurs.

Repositories publics (en amont)

Les repositories comme Maven Central et npm servent de bibliothèques globales en amont qui stockent tous les composants open source.  Ces serveurs accessibles publiquement comptent des dizaines de millions d'utilisateurs dans le monde, et ils sont alimentés par des centaines de milliers de projets open source. Nous pourrions les comparer à une « Bibliothèque d'Alexandrie » moderne, où toutes les connaissances seraient centralisées, sous forme de composants open source.  

De tels services réduisent les efforts requis pour distribuer ces artefacts aux millions de développeurs qui les utilisent.

part2-5

Avant l’arrivée des repositories publics, les utilisateurs devaient mettre à jour les dépendances manuellement, et il fallait réussir à faire passer le mot pour que les utilisateurs soient au courant de la publication des projets open source. Aujourd'hui, la publication de nouveaux composants open source ne fait plus autant de bruit.

Gestionnaires de repositories de binaires (service de mise en cache)

Contrairement aux autres Repository Managers, les gestionnaires de repositories de binaires sont mis en œuvre par des groupes d'individus ou des équipes pour une utilisation personnelle.  Ils remplissent quelques fonctions importantes dans le cycle de développement des logiciels modernes.

Conservez des copies

Ces gestionnaires fonctionnent comme des « proxies » ou des sauvegardes pour les repositories comme Maven Central, npm et d’autres Repository Managers. Lorsqu'un nouveau composant est nécessaire, les gestionnaires le récupèrent dans le repository et en mettent une copie en cache localement pour une utilisation ultérieure. Cette étape est essentielle, car même une courte panne de repository peut constituer un véritable casse-tête pour les développeurs. Ces derniers économisent de la bande passante et accélèrent la récupération lorsqu'ils se connectent au stockage de gestion des artefacts. 

En outre, il arrive que des composants disparaissent des repositories hébergés. Cela représente une menace importante pour toutes vos applications, surtout pour les applications existantes qui bénéficient toujours d'un support. Disposer d'une copie locale du repository réduit les risques. Et comme la copie est enregistrée en local, vous pouvez la gérer directement, et la personnaliser en fonction des besoins de votre entreprise. 

Ceci est primordial, particulièrement pour les équipes de développement, souvent nombreuses et largement distribuées. Une infrastructure efficace et des principes communs concernant le développement logiciel peuvent favoriser la collaboration et accélérer les processus.

Les Repository Managers peuvent également héberger des artefacts internes, comme une entrée de base de données personnalisée ou un contrôle de conformité propre à votre entreprise.  Ils fonctionnent comme une source unique de vérité pour tous les binaires utilisés dans vos processus de build. Nexus Repository est un exemple de Repository Manager de Sonatype. 

À l'instar des repositories publics, qui ont facilité la tâche à d'innombrables développeurs logiciels, l'exécution d'un gestionnaire de repositories de binaires permet une collaboration efficace entre les développeurs et les équipes. Si une équipe développe une bibliothèque qui sera utilisée par une autre équipe, elle peut utiliser un Repository Manager interne pour distribuer les versions logicielles en interne pour ses outils InnerSource. Si vos équipes de développement distribuent des applications à un groupe d'opérations pour le déploiement, elles peuvent utiliser un Repository Manager pour partager les produits finaux.

Même pour les petites équipes, les repositories de mise en cache ont leurs avantages : transferts accélérés, économies de bande passante et contrôle des logiciels à exclure du cycle de vie de développement.

Conteneurs

Aujourd'hui, l'open source tiers s'applique à la quasi-totalité des logiciels en développement : outils intégrés, bureau, cloud, machines virtuelles, etc. Toutefois, l'une des conséquences les plus notables de la chaîne logistique logicielle est la conteneurisation. Dans ce contexte, la vitesse de développement et de déploiement, favorisée par la mise en œuvre d'un environnement cohérent, met les logiciels conteneurisés en première ligne.

Les médias utilisent constamment des photos de porte-conteneurs pour accompagner leurs articles sur le sujet, et ce n'est pas un hasard :

« Les technologies de conteneurs tiennent leur nom du secteur du transport de marchandises. Plutôt que d'expédier chaque produit spécifiquement, les marchandises sont placées dans des conteneurs d'expédition en acier, conçus pour être déplacés par la grue sur le quai, et pour être empilés sur un navire construit spécialement pour accueillir des conteneurs de taille standard. En bref, en standardisant le processus et en rassemblant les marchandises, le conteneur peut être déplacé en une fois : une méthode moins coûteuse. (TechRadar) »

Avantages et adoption

Les conteneurs permettent de partager et de déployer facilement les applications, avec les avantages suivants :

  • Environnement et outils cohérents
  • Outils de conception prévisibles
  • Déploiement plus rapide

Les conteneurs peuvent servir de langage commun entre les équipes chargées du développement et des opérations informatiques. Et lorsqu'ils sont configurés correctement, l'équipe chargée des opérations peut utiliser les conteneurs pour assembler des environnements sans compromettre la sécurité de ces derniers.

containers-explained

Image adapted from Docker.

Grâce à ces fonctions, les services de conteneurs destinés au déploiement de logiciels explosent depuis 2013. Comme l'indique notre Rapport sur l'état de la chaîne logistique logicielle en 2020 :

« Les pulls d'images de conteneur ont dépassé les 8 milliards pour le mois de janvier ; le nombre annualisé de pulls d'images depuis le repository devrait donc atteindre les 96 milliards cette année. Afin de suivre le rythme de la demande, les fournisseurs ont importé 2,2 millions de nouvelles images sur DockerHub au cours de l'année dernière, soit une augmentation de 55 % par rapport à notre précédent rapport. » 

Les tendances ne montrent aucun signe de ralentissement. En effet, selon les projections de Gartner, 75 % des entreprises du monde entier exécuteront des applications conteneurisées en 2022, contre 30 % en 2020.

Les conteneurs reposent sur les mêmes dépendances logicielles que celles utilisées par d’autres logiciels, mais avec un délai d’exécution plus rapide, ce qui en fait des cibles d’attaque immédiates. Par conséquent, les attaques sur les conteneurs peuvent être le signe d'une attaque plus étendue sur la chaîne logistique logicielle. Et une sécurité efficace implique la surveillance des vulnérabilités au niveau des composants, ainsi que la recherche des problèmes de conformité et des erreurs de configuration.

Les conteneurs peuvent servir de langage commun entre les équipes chargées du développement et des opérations informatiques. Et lorsqu'ils sont configurés correctement, l'équipe chargée des opérations peut utiliser les conteneurs pour assembler des environnements sans compromettre la sécurité de ces derniers.

La solution à ce problème, et la pierre angulaire de l'intégrité de la sécurité, c'est la possibilité de détecter et de corriger les vulnérabilités tout au long du cycle de développement logiciel. Cela inclut le build, le registre et les environnements de production.

Licence de composants

Pour faire simple, une licence logicielle est un accord contraignant entre l'auteur du logiciel et l'utilisateur qui explique comment le logiciel peut être utilisé. En règle générale, la licence autorise l'utilisateur à consulter, modifier et utiliser le composant tant qu'il suit certaines règles.

Lorsqu'il s'agit d'un logiciel « open source », le code source est mis à la disposition des autres utilisateurs, qui peuvent le consulter et le lire. Une licence open source est simplement une licence qui déclare que le logiciel est un logiciel open source. Mais comme nous l'avons indiqué ci-dessus, cela ne signifie généralement pas qu'il est « libre d'utilisation » dans n'importe quelles conditions. 

Dans les premiers moments des composants logiciels open source, les conditions d'une licence étaient faciles à respecter, car peu nombreuses et généralement restreintes.  Mais avec la multiplication des logiciels basés sur des composants, les licences sont devenues plus problématiques. Rien que dans Maven Central, 95 % des composants sont distribués sous 17 licences différentes, et les 5 % restants sous 307 autres. 

Une chaîne logistique logicielle type en contient des centaines, ce qui complique naturellement les choses.

part2-7

Conformité des licences de composants

L'objectif de la conformité des licences est d'adopter une gestion des politiques qui garantit que les développeurs choisissent des composants atténuant les risques juridiques. Cependant, de nombreux composants open source sont associés à des exigences supplémentaires. Cela peut inclure des obligations légales. Cela peut être aussi simple que de mentionner l’auteur et dans d’autres cas, cela peut impliquer le partage du code source modifié avec la communauté.

Même les obligations les plus courantes peuvent être contraignantes. Les licences « d'attribution », qui vous demandent d'inclure le texte de licence, le texte d'avis, les détenteurs des droits d'auteur, les contributeurs et/ou le code source d'un composant OSS ne sont pas simples quand il existe des centaines de dépendances. En fait, une application type contient plus de 128 dépendances, et la collecte de toutes les données requises peut représenter jusqu'à 58 heures de productivité. (plus)

Encore une fois, l'automatisation est primordiale pour éviter aux développeurs qualifiés de devoir collecter et mettre à jour les licences.

Enveloppe Sonatype

Prêt à essayer les produits Nexus ?