Réutilisation du code Open Source : quelles implications ?

Une étude de Sonatype a récemment souligné à quel point les logiciels modernes utilisent du code open source recyclé, contenant souvent des failles de sécurité connues. Comment identifier le code concerné et le remplacer ? Des services tiers peuvent-ils s’en charger ?

L’utilisation de composants tiers et de code vulnérables au sein de nouvelles applications est devenue un problème de sécurité majeur souligné dans le Top 10 des vulnérabilités applicatives de l’Open Web Application Security Project (OWASP). Dans ses précédentes versions, la catégorie Utilisation de composants aux vulnérabilités connues était intégrée à une autre, plus générique, Défaut de configuration. Mais le problème est devenu si répandu qu’il mérite désormais une catégorie propre.

Les résultats de l’étude annuelle de Sonatype sur le développement Open Source apporte un regard intéressant sur les raisons pour lesquelles l’utilisation de code recyclé génère autant d’applications vulnérables. Dans ce rapport, la vaste majorité des 3 500 développeurs, managers et architectes sondés ont indiqué que leurs applications contenaient au moins 80 % de code Open Source, contre 20 % de code personnalisé. Plus loin, 76 % des grandes organisations n’ont pas de contrôle sur les composants utilisés dans leurs projets de développement logiciel, et que 65 % ne maintiennent pas d’inventaire des composants utilisés dans leurs applications en production. Pire, plus de la moitié des grandes organisations ont admis que leurs développeurs ne se concentrent pas sur la sécurité. Combinez tous ces aspects et les raisons qui ont poussé l’Owasp à pointer la réutilisation du code comme une vulnérabilité majeure du processus de développement applicatif deviennent évidentes.

Pour améliorer la gestion du développement de code Open Source et tiers, les équipes doivent créer et tenir à jour une liste de tout le code utilisé, en intégrant les dépendances et les sources. En outre, chaque source devrait disposer d’un point de contact désigné pour suivre les mailing-lists et les mises à jour. Ces tâches peuvent être plus aisément gérées avec un outil de gestion de dépôt - un point central de stockage des composants logiciels et de leurs dépendances utilisés pour le développement, le déploiement et le provisioning. Un gestionnaire de dépôt peut également aider à faire appliquer les règles relatives à la réutilisation de code.

Seuls les composants qui ont été examinés et qui répondent aux exigences internes devraient figurer dans le dépôt, et les développeurs devraient ne pouvoir utiliser que ces composants dans le cadre de leurs projets. Les produits de gestion de dépôt, tels que Nexus de Sonatype, ou Stash d’Atlassian, aident à intégrer la gestion du cycle de vie des composants à celle du cycle de vie des applications. Ils offrent également un inventaire des composants présents dans les dépôts internes et les applications en production, et alertent par avance les managers de vulnérabilités nouvellement découvertes, simplifiant la surveillance continue des applications en production.

Bien que disposer d’un gestionnaire de dépôt simplifie la gestion du code et des composants, les projets doivent toujours être menés avec une politique de régulation de la réutilisation du code et de prévention de toute confusion quant à qui est responsable de la gouvernance des composants Open Source. Un plan de réaction d’urgence est également vital pour réagir rapidement à la diffusion de tout correctif critique concernant un composant en cours d’utilisation. Les vulnérabilités découvertes dans les composants Open Source, les frameworks ou les librairies sont rapidement exploitées par les pirates. De fait, ils peuvent automatiser leurs attaques, sachant que les applications construites à partir du code défaillant seront vulnérables tant qu’un correctif ne sera pas diffusé et installé.

Les bénéfices liés à l’utilisation de code Open Source seront toujours supérieurs aux coûts associés au développement de ressources similaires. Mais cela requiert un processus visant à garantir que tout le code tiers est maitrisé et bien à jour. Il n’est désormais plus sûr de  laisser simplement les DevOps choisir les composants qu’ils souhaitent utiliser pour un projet.  

Par Michael Cobb, spécialiste de la sécurité applicative.
Adapté de l’anglais par la rédaction.

Pour approfondir sur Outils de développement

Close