Sécurité de l’open source avec Guy Podjarny, auteur chez O’Reilly

La semaine dernière, Guy Podjarny, cofondateur de Snyk, a participé à une discussion en direct au sujet de son livre O’Reilly Securing Open Source Libraries. Cet article résume quelques-uns des points intéressants abordés lors du webinaire. Vous pouvez également visionner l’enregistrement ici si vous n’avez pas encore eu l’occasion de l’écouter. Snyk se réjouit également de vous offrir un exemplaire du livre gratuitement.

Pourquoi la sécurité de l’open source ?

La discussion a commencé par une question essentielle : pourquoi s’intéresser à la sécurité de l’open source ? Guy explique qu’à son avis, le marché sous-estime aujourd’hui les risques liés aux bibliothèques open source. La grande majorité du code déployé par une équipe de développement n’est pas du code qu’elle a écrit, mais plutôt des bibliothèques open source. C’est une excellente nouvelle, car les équipes n’ont pas à réinventer la roue. En revanche, elles héritent des risques présents dans les composants open source.

Ce risque tient en partie au volume de bibliothèques open source par rapport au code original de votre application. Il s’explique aussi par le fait que les composants open source constituent des cibles particulièrement intéressantes pour les attaques. Les attaquants s’en prennent souvent d’abord aux cibles les plus faciles, et l’open source offre un fort retour sur investissement : une seule vulnérabilité peut être exploitée contre de nombreuses victimes.

Comment le secteur aborde-t-il actuellement ce problème ?

Une partie du secteur ne s’attaque pas encore à ce problème. Certaines personnes apprennent l’existence d’un exploit particulièrement malveillant et y remédient au cas par cas. Mais elles ne disposent pas d’une nomenclature des composants open source. Elles ne suivent pas les composants utilisés ni leur emplacement. Et elles ne surveillent pas vraiment ces composants dans la base de données des vulnérabilités.

D’autres prennent la sécurité en compte lorsqu’ils choisissent les bibliothèques open source à utiliser. Cela se produit souvent avant l’ajout d’une bibliothèque, mais celle-ci n’est pas nécessairement surveillée au fil du temps. De nouvelles vulnérabilités peuvent être découvertes, ou une version mise à niveau peut en introduire de nouvelles, sans qu’aucun processus ne soit en place pour suivre l’évolution de ces risques.

Enfin, certaines entreprises investissent dans la détection et la correction continues des vulnérabilités de sécurité de l’open source. Le livre explique en grande partie comment mettre cela en pratique au mieux. Commençons donc par examiner ce qui se passe lorsqu’une nouvelle vulnérabilité est divulguée dans une bibliothèque open source.

Une course contre la montre

Lorsqu’on examine un projet, il faut partir du principe qu’il comporte des bugs. Nous n’écrivons pas de code parfait, et nous n’écrivons ni n’utilisons du code dans des conditions optimales. C’est également vrai pour les bugs de sécurité. Il est donc sain de supposer que tout projet open source que vous intégrez comporte une vulnérabilité de sécurité. La communauté ne l’a peut-être simplement pas encore découverte.

Lorsqu’une vulnérabilité est découverte et divulguée, une course s’engage. La communauté s’empresse de publier un correctif et d’inciter les utilisateurs à l’appliquer. Les acteurs malveillants, eux, s’empressent d’exploiter la vulnérabilité partout où ils le peuvent. Puisque la vulnérabilité est connue, ils n’ont même pas besoin de la découvrir : il leur suffit de passer à l’action. Dès sa divulgation, le risque de sécurité associé augmente considérablement. Les attaquants comptent sur le manque d’hygiène en matière de sécurité. Les équipes veulent réduire au minimum le délai entre la divulgation d’une vulnérabilité et sa correction. Vous ne pourrez jamais éliminer complètement ce délai, mais une heure, un jour, une semaine, un mois ou un an, ce n’est pas la même chose.

Comment les équipes peuvent-elles réduire ce délai ? Et quel est le rôle de chacun ?

Le DevSecOps en pratique

DevSecOps est un terme ambitieux que l’on entend souvent dans le secteur. Il s’agit avant tout de travailler ensemble, au-delà des disciplines, vers un objectif commun : un produit fonctionnel et sécurisé. Les actions menées par les contributeurs individuels pour atteindre cet objectif varient selon qu’ils travaillent dans la sécurité ou le développement.

Le rôle des équipes de sécurité est de protéger leur organisation en gérant les risques potentiels de façon délibérée et réfléchie. Elles doivent donc comprendre leur niveau de risque actuel et pouvoir déterminer quels risques traiter en priorité. Toutefois, si l’on attend d’un professionnel de la sécurité qu’il se charge directement des corrections, cette approche ne pourra pas passer à l’échelle et risque de créer des problèmes : cette personne connaît le code beaucoup moins bien que l’équipe de développement.

Dans le DevSecOps, les professionnels de la sécurité jouent un rôle comparable à celui des ingénieurs en fiabilité des systèmes (SRE) dans le DevOps. Ils ont une vision globale de l’état du système et définissent les règles. En plus de leurs responsabilités de gouvernance, les membres de l’équipe de sécurité forment les développeurs avec lesquels ils travaillent et leur donnent les moyens de prendre en charge leurs tâches quotidiennes. Leur travail, qu’il s’agisse de gouvernance ou d’automatisation, permet aux développeurs de prendre les bonnes décisions en matière de sécurité et d’agir en conséquence.

Si le flux de travail est bien conçu, l’essentiel de ce travail peut se faire sans intervention de l’équipe de sécurité. Si un professionnel de la sécurité a défini de bonnes règles et fourni aux développeurs des outils et une formation adaptés, les tâches quotidiennes peuvent se poursuivre avec peu ou pas d’intervention de l’équipe de sécurité.

L’objectif : corriger

Quel est l’objectif d’une équipe DevSecOps ? Corriger les vulnérabilités.

Savoir que vous avez des vulnérabilités et où elles se trouvent est utile, mais nous voulons rendre les systèmes plus robustes dans leur ensemble, et cela passe par la correction des problèmes. Si les développeurs ne disposent pas des outils nécessaires ni du soutien adéquat des équipes de sécurité ou de la direction, il arrive que l’on s’arrête à la découverte de la vulnérabilité au lieu de la corriger.

Comment garder le rythme et non seulement détecter un problème, mais aussi le corriger ? Dans de nombreuses organisations, les corrections n’interviennent qu’après le triage, qui lui-même a lieu avant que l’équipe de développement soit mobilisée. Le triage consiste à évaluer la gravité et le risque de la vulnérabilité, mais pas nécessairement la facilité avec laquelle elle peut être corrigée. Une fois le triage terminé, l’équipe de développement constate que certains problèmes se règlent très facilement, tandis que d’autres sont systémiques et difficiles à corriger.

Pour un certain nombre de vulnérabilités, la correction sera plus simple que le triage. Le triage est nécessaire lorsque la correction n’est pas évidente, mais si elle est facile, autant aller droit au but et corriger. Si vous avez investi pour faciliter la correction, vous pourrez résoudre bon nombre de ces vulnérabilités sans même les trier.

L’ampleur du problème constitue un autre obstacle à la correction des vulnérabilités. Les équipes utilisent généralement de nombreux composants, dont beaucoup sont vulnérables, ce qui complique la gestion des vulnérabilités à grande échelle. Un bon plan de gouvernance peut aider : il permet de déterminer facilement quand l’équipe doit tout interrompre pour traiter un nouveau problème et quand la correction des vulnérabilités peut s’intégrer à son calendrier habituel.

Guy résume l’objectif ainsi : il faut détecter et corriger les problèmes déjà présents dans votre projet, puis prévenir les problèmes à venir et y répondre. Détecter. Corriger. Prévenir. Répondre. En définitive, il s’agit de quatre actions à mener à grande échelle.

Stopper l’hémorragie

Alors, par où commencer ? Que faut-il traiter en premier ?

Le terme « triage » est souvent associé à la médecine d’urgence. Imaginez un patient pris en charge après un grave accident de voiture. Il peut souffrir de plusieurs problèmes : un rhume depuis une semaine, des allergies saisonnières, voire une maladie chronique plus grave. Tous ces maux méritent d’être examinés par un médecin, mais aucun n’est prioritaire dans les premiers instants après l’arrivée du patient, victime d’un accident. L’essentiel est de stopper l’hémorragie. Les médecins font tout leur possible pour éviter que son état ne s’aggrave et, une fois le patient stabilisé, ils peuvent traiter les autres problèmes.

Lorsqu’une équipe commence à s’attaquer à la sécurité de l’open source, la tâche peut sembler écrasante. Votre projet présente peut-être déjà de nombreux problèmes. Dans ce cas, rappelez-vous qu’il faut d’abord stopper l’hémorragie. Vous pourrez vous occuper des problèmes existants une fois que vous aurez empêché la situation de s’aggraver. Concentrez-vous sur les changements. Si vous savez que votre projet comporte sept vulnérabilités, que vous ouvrez une PR pour de nouveaux changements et qu’elle en révèle huit, il vous suffit de corriger ou de prévenir cette vulnérabilité supplémentaire pour stabiliser votre projet. Corrigez les problèmes de sécurité apparus dans les changements entre l’ancien et le nouveau code. Une fois ce flux de travail en place, vous pourrez vous attaquer aux problèmes de sécurité hérités.

Stoppez l’hémorragie, mais ne vous arrêtez pas là. Prévenez les problèmes et réagissez-y. Détectez et corrigez. Gérez les risques persistants liés à la sécurité de l’open source et empêchez l’apparition de nouveaux problèmes. Utilisez l’open source en toute confiance, de manière responsable et sécurisée.

Regardez l’entretien en entier ici.

Recevez gratuitement votre exemplaire de Securing Open Source Libraries