Améliorer la sécurité en ignorant les vulnérabilités
D’une manière générale, l’affirmation « ignorer les vulnérabilités » n’est pas quelque chose que vous vous attendez à entendre de la part d’une entreprise de sécurité. Après tout, les vulnérabilités sont responsables de violations d’une telle ampleur qu’elles remplissent nos flux pendant des mois de commentaires post-mortem, d’analyses et de recommandations.
Et vous ne voyez certainement pas « ignorer les vulnérabilités » associé à la notion d’« amélioration de la sécurité ».
Vous l'avez maintenant - même si, comme pour la plupart des conseils, ceux-ci comportent des réserves et des réserves.
Vous ne devriez certainement pas ignorer toutes les vulnérabilités, mais il s'avère qu'il existe une classe de vulnérabilités que vous pouvez ignorer en toute sécurité dès maintenant - ou au moins déprioriser pour un jour de pluie. Je suis tombé sur ce concept en lisant l' état de la gestion des vulnérabilités Open Source 2018 de WhiteSource Software .
En plus de quelques statistiques très intéressantes, l’article avance l’idée que les vulnérabilités open source peuvent être regroupées en deux catégories : inefficaces et efficaces.
Le principe de catégorisation de WhiteSource est que certaines vulnérabilités sont inefficaces, c'est-à-dire qu'elles ne sont pas exploitables car elles ne sont pas invoquées par un code personnalisé. Être capable d'analyser et de différencier, comme le dit l'histoire, signifie que la sécurité et les développeurs peuvent se concentrer sur les vulnérabilités jugées efficaces et ainsi réduire le temps et les efforts tout en améliorant la sécurité globale de l'application.
Prenons par exemple une application personnalisée qui s’appuie sur un composant open source contenant une fonction vulnérable. Selon la définition de White Source, la fonction vulnérable dans cet exemple pourrait être déclarée « inefficace » car elle n’est jamais invoquée par l’application personnalisée. Les lecteurs astucieux noteront que la fonction vulnérable pourrait être invoquée par une fonction d'un composant open source (soit un autre composant, soit le même) et ainsi la rendre efficace. Lorsque j'ai interrogé WhiteSource sur cette possibilité, ils ont développé leur catégorisation en notant que cette possibilité était prise en considération. Si le code vulnérable est invoqué soit à partir d'un code personnalisé, soit indirectement via un autre composant open source, il est qualifié d'« efficace ». À l’inverse, s’il n’existe aucun chemin – direct ou indirect – qui invoque la fonction vulnérable, celle-ci est qualifiée d’« inefficace ».
Étant donné que les recherches de WhiteSource ont déterminé non seulement que 96,8 % des développeurs s'appuient sur des composants open source, mais que 7,5 % de tous les projets sont vulnérables, pouvoir hiérarchiser les vulnérabilités sur lesquelles se concentrer serait certainement une aubaine. WhiteSource a également déterminé que 64 % des produits open source contenaient uniquement des vulnérabilités inefficaces , qui, selon eux, peuvent être ignorées en toute sécurité.
Bien que je ne sois pas convaincu que nous devrions simplement ignorer les vulnérabilités dans un code parce qu'elles ne sont pas invoquées activement, je vois un intérêt à utiliser une telle distinction pour prioriser la gestion des vulnérabilités. En se concentrant sur le code vulnérable qui est activement invoqué, les développeurs et les professionnels de la sécurité peuvent immédiatement améliorer la sécurité globale d'une application. Cela permet une meilleure utilisation des développeurs seniors, qui, selon le rapport de White Source, passent en moyenne plus de temps à traiter les vulnérabilités que les développeurs juniors.
Une sorte de méthode de priorisation doit être mise en place. WhiteSource a déclaré qu'il y avait près de 3 500 vulnérabilités signalées en 2017, soit une augmentation de 60 % par rapport à 2016. Ces 3 500 vulnérabilités signalées ne concernent pas toutes les applications ou organisations, mais nous devons garder à l’esprit que ces chiffres sont positifs. Autrement dit, les 3 500 sont de nouvelles vulnérabilités qui s’ajoutent à un total cumulé.
Il va sans dire qu’il existe de nombreuses vulnérabilités dans le code, qu’il soit personnalisé ou open source. Être capable de prioriser les mesures correctives en fonction de leur « efficacité » ou de leur « inefficacité » est conforme aux stratégies de sécurité émergentes qui évaluent les risques en fonction de la menace existentielle en plus d’autres facteurs. La menace existentielle d’une vulnérabilité inefficace est presque inexistante. Cela dit, ignorer les vulnérabilités inefficaces n’est peut-être pas la meilleure approche à long terme. Il est possible qu’un jour de telles vulnérabilités deviennent efficaces. Les modifications apportées au code personnalisé à mesure que des fonctionnalités sont ajoutées et/ou améliorées, ainsi que les modifications apportées au fil du temps aux composants open source, peuvent conduire à une ouverture de chemin qui invoque une fonction vulnérable. C'est l'une des raisons pour lesquelles l'analyse du code source spécifiquement pour les vulnérabilités doit avoir lieu en continu au mieux, et au pire pendant la construction finale.
Mais dans l'intérêt du respect des délais et d'une utilisation efficace du temps des développeurs, repousser les vulnérabilités « inefficaces » à l'arrière de la file d'attente afin que les vulnérabilités « efficaces » puissent être corrigées immédiatement pourrait bien être l'un des meilleurs moyens pour les développeurs d'améliorer la sécurité dès maintenant.