Les dernières heures d’un salon réservent toujours de bonnes sessions. Ce midi, nous avons eu la possibilité de voir une session dont le titre nous intéressait beaucoup “Retour d’expérience Thales DIS : gestion du risque de sécurité open source et des vulnérabilités connues”. Thales DIS est l’émanation issue du rachat de Gémalto par Thales en début d’année. A Thales DIS, 96 % des projets utilisent des codes / projets open source, soit + 250 composants ouverts. Ce n’est pas sans risque. Attention, nous ne sommes pas dans un débat “l’open source c’est mal”. Le risque évoque ici deux éléments importants : les vulnérabilités possibles dans les composants et les problèmes de licences, selon le mode de distribution des projets réalisés par les équipes de Thales DIS. 

Un des critères est l’activité de la communauté, le nombre de commits depuis 12 mois. C’est le risque opérationnel. Le licence pose aussi un risque réel : il faut pouvoir déterminer la licence utilisée pour tel ou tel composant, les obligations liées à ces licences. Enfin, le risque de sécurité se résume, ici, aux vulnérabilités. 

Comme évoqué plus haut, la question n’est pas de savoir si l’OSS est + ou - sécurisé. Car, le code source est disponible et ouvert, donc l’accès est facile, les hackers peuvent eux aussi voir le code et chercher les failles. Et souvent l’exploit est illustré par des vidéos :-)

Un des exemples donnés fut la faille CVE-2017-5638, sur Apache Struts : découverte en mars 2017 et comblée en juillet. Cela montre bien les délais possibles entre la découverte et le patch. Heureusement c’est souvent plus rapide. Quand une faille est découverte, il est nécessaire de savoir si j’utilise le composant et si la version que j’utilise est impactée. 

Un scan des composants open source effectué en 2017, par Thales, a montré que 78 % contenaient des vulnérabilités. Et surtout, elles étaient, en moyenne, vieilles de 6 ans ! Plus de la moitié était de risque élevé. 

Vu le nombre élevé de failles officiellement déclarée, plus de 120 000, il est impossible de traiter cette recherche manuellement. Il est nécessaire de mettre en place des outils dédiés tels que les SCA (Software Composition Analysis). Un SCA va servir à scanner les composants, découvrir les failles, définir et les lister les licences de chaque composant. Attention : un outil comme Black Duck n’analyse pas le code, d’autres outils s’en chargeront. Black Duck repose sur une grosse base de connaissance de +70 000 failles et 2200 licences. 

Dans le cas de Thales DIS, l’outil a été déployé dans la chaine d’intégration continue et tout le long du processus projet. Et il a été intégré au SecPlan (plan de sécurité global à l’entreprise). Une faille détectée dans un composant doit être corrigée d’une manière ou d’une autre : retrait du composant, application du patch, etc. Cependant, il faut prendre en compte le contexte d’usage du composant et évoluer le risque sur le projet (= gestion du risque). 

Mais il ne faut pas non plus faire une confiance aveugle à un outil SCA. A vous de faire le reste. Dans le cas de Thales DIS, le scan est analysé et évalué. Comme vous le comprenez, l’usage d’un tel outil est nécessaire quand vous manipulez beaucoup de composants et vous aide à gérer les vulnérabilités. D’autre part, la question de licences va se poser selon le mode de distributions car certaines licences peuvent “contaminer” tout le code. Le constructeur a mis en place une matrice de décision selon le mode de distribution et la catégorie de licences (de la plus permissive à la plus contraignante). 

Il existe beaucoup d’outils SCA. Vous pouvez regarder la liste proposée par l’OWASP.

François Tonic