[Tribune] Cinq étapes pour gérer les vulnérabilités et les licences des logiciels open source

Étape 2 : chercher les OSS

Une fois que vous savez comment vos composants open source sont sélectionnés et utilisés, vous pouvez évaluer ceux dont vous avez besoin, et comment ils sont utilisés ou répartis. On appelle ça dresser une nomenclature (Bill of Materials), ou une liste de divulgation. Cette liste sert à suivre les obligations, à modifier les politiques vis-à-vis des OSS, et à réagir aux vulnérabilités rendues publiques. Souvent, des paquets open source comporteront des termes de licence que votre organisation ne pourra pas respecter, ce qui pose automatiquement un problème de conformité. Dans de tels cas, le composant en question devra être supprimé et la fonctionnalité remplacée, soit par un autre composant OSS, ou en écrivant une fonctionnalité équivalente.

L'examen du code base, la tenue d'entretiens et l'utilisation d'outils d'analyse de code peuvent être utiles dans le cadre de ce processus.

Étape 3 : questionner l'équipe de développement

Les projets devenant sans cesse plus vastes, complexes et distribués, il est de plus en plus difficile de découvrir l'ensemble des éléments utilisés. Il est donc important d'avoir des échanges réguliers avec les développeurs, équipes DevOps, ainsi que l'ensemble du personnel informatique impliqué dans la création, le déploiement et la mise en oeuvre du projet en question. Posez-leur des questions ciblées, comme " Quelle base de données utilisons-nous ? ", ou " Quelle bibliothèque de chiffrement utilisons-nous ? ". Cela peut être utile pour découvrir d'autres modules potentiellement passés inaperçus la première fois.

Demander simplement " Quel code open source utilisons-nous " permet rarement de créer une liste complète pour un certain nombre de raisons, notamment à cause d'oublis ou de l'absence de registres adéquats.

Étape 4 : comprendre comment les OSS entrants sont gérés

La gestion des composants tiers doit faire l'objet d'un processus cohérent et correctement appliqué. Votre organisation pourra ainsi respecter ses obligations des licences open source, mais aussi faire face à de nouvelles vulnérabilités. Il est fréquent de voir ce processus atteindre différentes étapes et niveaux de conformité. Certaines organisations se contentent encore de suivre les composants " sollicités " par les développeurs. Celles-ci n'ont souvent connaissance que des éléments les plus importants, ou découvrent que certains développeurs sont plus assidus que d'autres dans le cadre du respect du processus.

D'autres entreprises utilisent des outils d'analyse pour découvrir et suivre leurs OSS. Leurs résultats varieront en fonction des solutions utilisées ou du niveau d'analyse. Certains outils ne découvrent que les textes de licence, pas les composants open source. D'autres ne peuvent retrouver que les composants gérés par des gestionnaires de paquets. Il est donc important de savoir quel niveau d'analyse est adopté et ce que l'on peut espérer repérer...

Étape 5 : cherchez des preuves de conformité des OSS

Une fois toutes ces étapes franchies, il est important de confirmer la visibilité de cette conformité. Les déclarations et autres avis légaux (droits d'auteurs) nécessaires sont-ils présents dans les produits ou leur documentation ? Les textes des licences sont-ils visibles comme il se doit ? Existe-t-il une offre écrite relative au code source ou ses distributions, et ciblant du contenu rendu libre que vous utilisez ? Tous ces éléments seront les témoins visibles de l'efficacité de votre processus de gestion des composants open source.

En suivant ces cinq étapes, en sensibilisant votre personnel à l'utilisation adaptée des OSS, et en encourageant les membres de votre écosystème à en faire de même, vous pourrez créer des applications modernes et puissantes, tout en respectant les licences open source.

En outre, plus vous en savez sur les ingrédients, les éléments tiers et les vulnérabilités de votre produit, mieux ce dernier pourra être sécurisé et pris en charge !