TechTarget
Conseil

Comment établir les bases d’une politique de sécurité open source

L’utilisation de logiciels open source soulève des questions en matière de sécurité et de propriété intellectuelle. Voici comment prendre des décisions judicieuses et éviter des situations potentiellement regrettables.

George Lawton
par
Publié le: 09 janv. 2024

Si les bibliothèques de logiciels libres aident les équipes de développement à lancer rapidement de nouvelles applications, vous devez être conscient des risques qu’elles peuvent présenter. Élaborez la bonne politique pour réduire les efforts nécessaires à la correction des vulnérabilités et pour atténuer les problèmes liés à la perte de données.

« L’usage de l’open source signifie fondamentalement que vous incorporez le code de quelqu’un d’autre dans votre propre produit ou service », insiste Tim Mackey, responsable de la stratégie de risque de la chaîne d’approvisionnement en logiciels chez Synopsys Software Integrity Group.

Ce code est assorti de droits et d’obligations sous la forme de licences plus ou moins permissives, mais il existe également des risques liés à la manière dont le logiciel a été créé, testé et géré. Sans une politique clairement définie, l’utilisation d’un composant open source pose des problèmes de propriété intellectuelle et de cybersécurité.

Une politique en matière d’open source doit clarifier les usages, les flux de travail et les rôles afin de rationaliser les processus de développement de logiciels sécurisés.

« Une telle politique guide les développeurs dans la sélection, la consommation, la surveillance, la mise à jour et l’élimination des composants libres tout au long du cycle de vie du développement logiciel », résume Henrik Plate, chercheur en sécurité chez Endor Labs, l’éditeur d’une plateforme de sécurisation des librairies open source et de la chaîne d’approvisionnement logicielle.

Elle représente une approche structurée et systématique de l’exploitation de composants open source au sein d’une organisation, contrairement à la consommation ad hoc et non coordonnée de logiciels libres par des individus au sein d’une entreprise. La politique doit décrire les exigences, les règles et les conditions relatives à ces usages afin de garantir la réalisation de divers objectifs de haut niveau.

En outre, une telle politique de sécurité open source fournit un ensemble de principes directeurs qui aident les organisations à atteindre leurs objectifs préalablement définis. « Elle permet à une entreprise d’aligner tout le monde sur ces principes directeurs et sur les pratiques qui permettent de les mettre en œuvre », commente Henrik Plate.

Que faut-il inclure dans une politique de sécurité open source ?

Une politique de sécurité relative aux logiciels libres et open source établit un cadre qui aide les consommateurs à prendre des décisions tout au long du cycle de vie d’un composant. Henrik Plate recommande que cette stratégie couvre trois phases du cycle de vie d’un logiciel : sa sélection, son utilisation et sa suppression.

La phase de sélection doit prendre en compte les différents types de librairies disponibles. Les considérations relatives à l’utilisation doivent porter sur le coût total de possession d’un produit logiciel, notamment en évaluant la nécessité d’une maintenance interne lorsqu’une bibliothèque ne dispose pas d’un support actif de la communauté qui pourrait autrement supporter ces coûts. Les entreprises peuvent aussi vouloir s’assurer que le logiciel est fréquemment mis à jour et que sa gestion dépend d’un calendrier d’actualisation clairement défini. Il est non moins important de stipuler quand un composant open source doit être retiré. Il se peut que la communauté ne traite pas les vulnérabilités connues en matière de sécurité.

Par ailleurs, une bonne politique de sécurité open source doit prendre en compte les évolutions de l’usage des librairies en entreprise. Prashant Deo, responsable du centre d’excellence des outils et de l’ingénierie de sécurité au sein du bureau de la pratique de cybersécurité de Tata Consultancy Services, explique qu’il observe régulièrement des situations dans lesquelles un logiciel était prévu pour un usage interne, mais est pour finir intégré dans un produit commercial. Cela peut entraîner des conséquences sur la propriété intellectuelle et la sécurité, d’où l’importance d’une approche qui réglemente l’utilisation, la modification et la distribution des logiciels open source.

C’est pourquoi Prashant Deo recommande aux entreprises de prendre en compte les éléments suivants :

  • Une définition claire des rôles et responsabilités des parties prenantes, y compris des membres des services informatiques, de la sécurité du développement des applications, des équipes de risque et de la conformité.
  • La mise en place de processus de surveillance continue des vulnérabilités pour tous les composants open source et leurs mises à jour.
  • La maintenance d’un référentiel de code source sécurisé, le check-in et le check-out sécurisés, la gestion des changements et la gestion des versions.
  • L’instauration de mécanisme de suivi du bien tout au long de son cycle de vie : acquisition, utilisation, distribution, stockage, mises à jour et retrait, ainsi qu’une nomenclature actualisée des logiciels (SBOM).
  • Le déploiement de processus de test de sécurité pour les composants open source, dont l’analyse de la composition des logiciels, pour une meilleure visibilité des problèmes de sécurité potentiels dans l’ensemble des composants.

Donner la priorité à la sécurité et à la conformité

Qui plus est, il s’avère essentiel d’incorporer des contrôles, différenciés ou non, s’appliquant à chaque composant open source. Ilkka Turunen, directeur technique de Sonatype, recommande aux équipes de générer un SBOM afin de répertorier les composants présents. Ce SBOM peut ensuite être analysé en fonction des exigences d’une stratégie de sécurité open source. Il s’agit d’identifier les cas d’usage potentiellement sensibles et d’autres risques pour l’entreprise, ses collaborateurs et ses clients.

Selon M. Turunen, le principal avantage d’une politique de sécurité open source est qu’elle donne aux entreprises une visibilité et, par conséquent, la possibilité de mieux choisir leurs briques logicielles. Elle améliore également la qualité de l’application, par exemple en réduisant la dette technique liée à des dépendances auparavant sans contrôle.

Les équipes doivent toutefois procéder avec prudence. Il convient de ne pas introduire de nouveaux problèmes pour les développeurs ou des frictions dans le processus de développement. « Comme pour tout changement culturel, l’instauration d’une politique de sécurité open source peut entraîner une transition douloureuse », constate Ilkka Turunen. Par exemple, les développeurs n’ont pas besoin d’un nouveau processus pour générer d’innombrables alertes de sécurité lorsqu’ils activent pour la première fois un outil d’application des politiques. Il est essentiel de démarrer le projet avec les bonnes intentions et des attentes transparentes.

En fin de compte, la création d’une politique de sécurité open source consiste à formaliser les décisions que les individus et l’organisation doivent prendre lorsqu’ils adoptent des composants dépendants de licences libres ou ouvertes. Il paraît essentiel de rechercher des possibilités d’automatiser le processus afin que les équipes puissent se concentrer sur la création de valeur plutôt que sur la résolution de nouveaux problèmes.

« Les organisations qui réussissent cette transition ne passent pas des heures par jour sur ce sujet, mais l’intègrent plutôt dans leur processus d’ingénierie quotidien. L’important n’est pas la présence de failles de sécurité [dans le code source], mais la rapidité avec laquelle on y réagit. La plupart des failles exploitées sont vieilles de plusieurs années », souligne le CTO de Sonatype.

Pour approfondir sur DevSecOps

Close