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 .

Au-delà de statistiques convaincantes, cet article avance que les vulnérabilités des logiciels libres se répartissent 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.  

Par exemple, imaginez une application personnalisée qui s’appuie sur un composant open source contenant une fonction vulnérable. Selon la définition de White Source, on pourrait qualifier de « inefficace » la fonction vulnérable si l’application personnalisée ne l’utilise jamais. Les lecteurs avertis comprendront que cette fonction vulnérable pourrait être appelée par une autre fonction d’un composant open source (que ce soit un autre composant ou le même) et devenir ainsi efficace. Quand j’ai interrogé WhiteSource sur ce cas, ils ont précisé que cette éventualité est bien prise en compte dans leur catégorisation. Si le code vulnérable est appelé, directement dans du code personnalisé ou indirectement via un autre composant open source, on le considère comme « efficace ». À l’inverse, s’il n’existe aucun chemin, direct ou indirect, qui invoque cette fonction vulnérable, elle est jugée « inefficace ».  

Les recherches de WhiteSource montrent que, si 96,8 % des développeurs utilisent des composants open source, 7,5 % des projets sont vulnérables. Savoir quelles vulnérabilités prioriser serait donc un véritable atout. WhiteSource révèle aussi que 64 % des produits open source présentent uniquement des vulnérabilités inefficaces, que vous pouvez ignorer sans risque.

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 faut savoir qu'il existe de nombreuses vulnérabilités dans le code, qu'il soit personnalisé ou libre. Vous pouvez hiérarchiser les remédiations selon qu'elles sont « efficaces » ou « inefficaces », conformément aux stratégies de sécurité actuelles qui évaluent le risque en tenant compte de la menace existentielle, en plus d'autres critères. La menace liée à une vulnérabilité inefficace est quasiment nulle. Cela dit, négliger les vulnérabilités inefficaces ne constitue pas la meilleure solution sur le long terme. Elles peuvent devenir efficaces avec le temps. Les évolutions du code personnalisé, lors de l’ajout ou de l’amélioration de fonctionnalités, ainsi que les changements apportés aux composants libres, peuvent ouvrir un chemin qui active une fonction vulnérable. C’est pourquoi nous recommandons d’analyser régulièrement le code source pour ces vulnérabilités, idéalement en continu, ou au minimum lors de la dernière phase de construction.

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.