Exposées ou non, les vulnérabilités sont dangereuses

Illustration de Lou Reade

Imaginez que vous ayez un étang dans votre jardin, avec un ponton en bois. Un jour, en vous avançant sur le ponton, vous découvrez qu’une planche est fissurée et sur le point de céder. Vous devez décider de la réparer ou de la laisser en l’état en vous disant que vous vous en occuperez plus tard. Si vous êtes la seule personne à vous rendre sur le ponton, ce n’est pas forcément très grave. Vous savez que la planche est abîmée et vous ferez attention (à condition de vous en souvenir). Mais qu’en est-il du reste de votre famille ? Ou de vos amis qui viennent vous rendre visite ? Rien ne garantit que, même si vous les prévenez tous, ils s’en souviendront. Un jour, quelqu’un finira par marcher sur cette planche et prendre un bain qu’il n’avait pas prévu. Il suffit d’une personne, d’un seul pas. Une bibliothèque peut présenter une vulnérabilité connue, mais si le site ou l’application concernés n’utilisent pas un appel de méthode particulier, cette vulnérabilité n’est pas exposée. Dans ce cas, on pourrait vous pardonner de l’ignorer : elle n’a tout simplement aucun impact sur votre système actuel. Mais le mot clé, ici, c’est « actuel ». Les vulnérabilités ont ceci de particulier qu’elles ne sont généralement pas très évidentes. La méthode vulnérable ne s’appelle pas clairement « à ne pas utiliser, dangereux ». Les vulnérabilités sont généralement subtiles. Une modification de vos paramètres, un appel de méthode qui semble anodin : il suffit de cela pour passer d’un système sûr à un système vulnérable. Qu’une vulnérabilité soit exposée ou non aujourd’hui est important, mais moins que certains ne le pensent. Cela peut tout à fait être un critère déterminant pour établir les priorités. Si vous devez traiter deux vulnérabilités, dont l’une est exposée et l’autre non, donnez la priorité à celle qui est exposée. Mais il est également essentiel de corriger rapidement les vulnérabilités non exposées. Tant que ce n’est pas fait, elles constituent une faiblesse dans votre application, une faille dans votre armure. Il suffit d’un développeur et d’une seule modification du code pour les rendre exploitables. La résilience compte, et une vulnérabilité non exposée mais non corrigée fragilise inutilement votre système. La sécurité est souvent réactive : les équipes de défense tentent de suivre les innombrables moyens dont disposent les attaquants pour s’en prendre à leurs systèmes. Les vulnérabilités connues qui ne sont pas encore exposées dans votre application ne doivent pas être ignorées. Elles vous offrent au contraire une occasion rare de garder une longueur d’avance et de sécuriser vos systèmes avant qu’un incident ne survienne. Face à tous les défis que nous devons relever pour protéger nos sites et nos applications, saisissons chaque occasion d’agir de manière proactive afin de garantir la sécurité de ce que nous développons.