Aider les développeurs à prioriser le backlog de sécurité

Aujourd’hui, les développeurs prennent de plus en plus les devants pour corriger les vulnérabilités de leurs applications, ce qui est formidable. Mais ils se retrouvent alors face à un long backlog de vulnérabilités. Décider quel problème traiter en premier est difficile et exige du temps et une expertise en sécurité dont ils ne disposent souvent pas. Les bons outils peuvent faire la différence : ils apportent l’expertise nécessaire pour savoir quelles questions de sécurité poser lors de la priorisation, ainsi que la technologie pour y répondre rapidement.

Faire face à la surcharge de vulnérabilités

Le nombre de vulnérabilités dans les composants open source ne cesse d’augmenter, avec des milliers de nouvelles vulnérabilités divulguées chaque année. Pour s’en faire une idée, Snyk Vulnerability Database a enregistré une hausse totale de 394 % au cours des quatre dernières années. Cette croissance continue se reflète dans les retards accumulés par les organisations dans le traitement des vulnérabilités.

Déjà à court de ressources et constamment sous pression pour déployer rapidement et fréquemment du code fonctionnel et sécurisé afin d’aider leur entreprise à rester compétitive, les développeurs ne peuvent venir à bout de ces backlogs qu’en établissant de bonnes priorités. Comme ils ne peuvent pas, en pratique, corriger toutes les vulnérabilités de la liste, les équipes de développement doivent déterminer lesquelles offrent le meilleur retour sur le temps investi.

Ces décisions peuvent avoir un impact considérable sur les efforts d’une organisation pour gérer et réduire les risques. Une mauvaise priorisation peut mobiliser le temps des équipes de développement sur des vulnérabilités qui se révèlent être de faux positifs, créant des frictions et diminuant la confiance des développeurs. Prioriser une vulnérabilité de gravité élevée sans exploit connu plutôt qu’une vulnérabilité de faible gravité exploitée dans la nature pourrait affaiblir la posture de sécurité globale de l’organisation.

Savoir poser les bonnes questions

Une priorisation efficace requiert de l’expertise, notamment en sécurité, pour évaluer avec précision et en profondeur la menace que représente la vulnérabilité pour l’organisation. Les développeurs ne possèdent généralement pas cette expertise, ce qui entrave leur capacité à bien prioriser les risques.

Les outils de sécurité efficaces doivent donc apporter cette expertise manquante et faire émerger les bonnes questions au bon moment. Les spécialistes de la sécurité peuvent adapter ces questions, qui sont ensuite mises en avant dans le produit.

Remettre les priorités dans le bon ordre

La première question à laquelle les développeurs doivent pouvoir répondre semble simple : quel problème du backlog faut-il traiter ensuite ?

Le CVSS a été conçu précisément dans ce but, mais il présente plusieurs difficultés. Calculer un score basé sur le CVSS nécessite des connaissances en sécurité. Même lorsque le score est fourni d’emblée, comprendre comment il a été établi exige des connaissances et parfois des recherches supplémentaires. De plus, la gravité d’une vulnérabilité n’est pas le seul facteur à prendre en compte pour décider quel problème traiter en premier.

Les développeurs ne disposent généralement pas de l’expertise en sécurité nécessaire pour comprendre les nuances du CVSS. Ils ne peuvent pas non plus se permettre de consacrer du temps à rechercher pourquoi une vulnérabilité a reçu un niveau de gravité donné. Pour aider les développeurs à établir leurs priorités, le score doit être explicite et facile à utiliser. Snyk, par exemple, prend en compte la gravité, la disponibilité d’un correctif, la maturité de l’exploit et l’ancienneté de la vulnérabilité pour calculer son score de priorité. Ce score est ensuite présenté de façon à être facile à comprendre et à utiliser pour les développeurs.

La différence entre important et urgent

Une fois les priorités établies, il faut également déterminer quels problèmes sont plus urgents que les autres.

Les vulnérabilités exploitées dans la nature, par exemple, doivent être hautement prioritaires et considérées comme suffisamment urgentes pour nécessiter une intervention immédiate. La célèbre faille d’Equifax provenait d’une vulnérabilité connue, pour laquelle des exploits avaient été publiés dans la nature quelques jours seulement avant l’attaque. 

Savoir si une vulnérabilité est exploitable ne constitue toutefois qu’une partie de la solution. Cela indique la probabilité qu’elle soit exploitée, mais, comme pour les vulnérabilités en général, tous les exploits ne se valent pas. Certains ne sont que théoriques et n’ont jamais été transformés en armes. D’autres sont beaucoup plus matures et leur code d’exploitation a été publié.  Les exploits matures abaissent la barrière d’entrée pour les attaquants, ce qui incite davantage d’entre eux à les essayer. Plus important encore, ils sont rapidement intégrés à des botnets automatisés, qui parcourent constamment le Web à la recherche de failles faciles à exploiter, quelle que soit la victime. Si vous laissez une telle faille ouverte, ces botnets la trouveront probablement rapidement.

Face à un vaste backlog de vulnérabilités, les développeurs doivent pouvoir repérer rapidement celles pour lesquelles il est facile de trouver et de transformer des exploits en armes. Avec ces informations, il devient beaucoup plus facile de décider s’il faut prioriser une vulnérabilité.

Corriger avec le bon contexte

Une vulnérabilité connue peut avoir un exploit, mais cela ne signifie pas qu’elle est exploitable dans votre application. La possibilité de l’exploiter dans votre application dépend des interactions entre votre code, les autres bibliothèques que vous utilisez et le composant vulnérable.

Obtenir ce contexte nécessite non seulement une expertise en sécurité, mais aussi des capacités d’analyse. Les développeurs ont rarement accès à ces deux ressources et n’ont pas non plus le temps de les développer eux-mêmes.  Des outils intégrant ces capacités aident les développeurs à déterminer si une méthode vulnérable est réellement incluse dans le chemin d’exécution d’une application, puis à établir leurs priorités en conséquence.

Snyk, par exemple, analyse au préalable chaque composant de l’environnement de l’utilisateur et peut surveiller l’application en cours d’exécution. L’objectif : indiquer aux développeurs si l’application peut atteindre la vulnérabilité.

Moins de blocages. Plus de garde-fous.

On demande aux développeurs d’assumer toujours plus de responsabilités en matière de sécurité, mais ils ne peuvent le faire que s’ils savent qu’ils consacrent leur temps et leurs ressources aux bonnes vulnérabilités. Une bonne priorisation contribue également à réduire les frictions entre les développeurs et les équipes de sécurité : moins il y a de faux positifs dans la liste des problèmes à corriger immédiatement, plus les développeurs font confiance au processus.

De leur côté, les équipes de sécurité doivent veiller à ce que les développeurs puissent prioriser leurs tâches en toute sécurité. En leur fournissant des garde-fous, elles peuvent s’assurer que les décisions sont prises dans un cadre sûr. Ces garde-fous doivent être définis par les équipes de sécurité à l’aide de politiques suffisamment précises pour assurer une gouvernance à grande échelle. Plus ces politiques sont automatisées, mieux c’est.  

Pour aider les développeurs à poser les bonnes questions et à prioriser efficacement, Snyk leur propose des fonctionnalités de priorisation conçues pour eux, qui suggèrent les questions à poser, trouvent les réponses et simplifient les étapes suivantes de la correction. En savoir plus ou commencez dès maintenant gratuitement.