7 conseils pour hiérarchiser les vulnérabilités des conteneurs et des applications web

Comme il est tout simplement impossible de corriger toutes les vulnérabilités des applications web de votre backlog, vous devez établir des priorités. Cette hiérarchisation vous aide à vous concentrer sur les problèmes les plus importants pour votre organisation et à tirer le meilleur parti du temps et des ressources limités dont vous disposez, afin d’obtenir le meilleur impact sur la sécurité.

Par où commencer pour hiérarchiser les vulnérabilités ?

Il existe différentes méthodes de hiérarchisation. Celle que vous choisirez dépendra de l’approche de sécurité que vous avez décidé de mettre en œuvre. Pour vous aider à comprendre les différents éléments de cette démarche, voici une liste des outils les plus utilisés pour hiérarchiser les vulnérabilités des applications web.

1. CWE

Qu’est-ce que CWE ?

CWE signifie Common Weakness Enumeration. Il s’agit d’un glossaire en ligne qui classe les faiblesses des logiciels et du matériel en différents types. Par exemple : CWE-20 (validation des entrées), CWE-125 (lecture hors limites), CWE-79 (XSS) et CWE-200 (fuite/divulgation d’informations).

Géré par MITRE, CWE a pour objectif déclaré de fournir un moyen efficace d’identifier, de détecter et de résoudre les problèmes de sécurité logicielle dès que possible. CWE peut également servir à hiérarchiser les vulnérabilités des applications web de plusieurs façons :

• Si vous manquez de temps et ne pouvez pas examiner en profondeur les vulnérabilités détectées dans votre code, utilisez la liste CWE Top 25 comme point de départ pour prioriser la correction des CWE que la communauté considère comme les plus importantes.

• Servez-vous de CWE pour établir vos priorités en fonction de l’impact : les entrées CWE précisent les conséquences techniques d’une faiblesse. Au lieu d’essayer de tout corriger, concentrez-vous sur les CWE les plus dangereuses pour votre organisation.

• Utilisez CWSS et CWRAF, deux systèmes de notation des CWE qui vous permettent de hiérarchiser les vulnérabilités en fonction de leur pertinence pour votre activité.

2. CVSS/gravité

Le Common Vulnerability Scoring System (CVSS), la méthode de hiérarchisation la plus utilisée, est une norme du secteur qui permet d’évaluer la gravité des vulnérabilités. Selon la facilité avec laquelle une vulnérabilité d’application web peut être exploitée et l’impact d’une exploitation réussie, le CVSS attribue un score de 0 à 10, 10 correspondant au niveau de gravité le plus élevé.

Selon la NVD, un score de base CVSS (v3) de 0,0 à 3,9 correspond à une gravité « faible » ; un score de 4,0 à 6,9 à une gravité « moyenne » ; un score de 7,0 à 8,9 à une gravité « élevée » ; et un score de 9,0 à 10,0 à une gravité « critique ».

Le CVSS constitue un bon point de départ, mais gardez à l’esprit qu’il ne donne pas une vision suffisamment précise du risque posé par une vulnérabilité. Comme l’indique la documentation officielle du CVSS : « Le CVSS est conçu pour mesurer la gravité d’une vulnérabilité et ne doit pas être utilisé seul pour évaluer le risque… Le score de base CVSS doit être complété par une analyse contextuelle de l’environnement et par des attributs susceptibles d’évoluer dans le temps. »

3. Possibilité d’exploitation

Pour déterminer le risque réel qu’une vulnérabilité pose à votre organisation, vous pouvez notamment évaluer la facilité avec laquelle elle peut être exploitée. La disponibilité d’un code d’exploitation est l’un des facteurs qui facilitent considérablement la tâche des pirates. Dès qu’un tel code est publié, on parle d’un « exploit actif ».

Savoir s’il existe des « exploits actifs » pour les problèmes de votre backlog vous aidera à vous concentrer sur les problèmes les plus risqués. Distinguer les différents types d’exploits publiés vous permettra d’affiner encore votre analyse : le risque posé par un exploit abouti, publié et exploitable en pratique n’est pas le même que celui d’un exploit théorique ou universitaire. Pour en savoir plus sur l’importance de la possibilité d’exploitation dans la hiérarchisation, cliquez ici.

4. Atteignabilité

Les développeurs intègrent souvent des composants open source entiers à leur base de code, mais n’en utilisent qu’une petite partie dans la logique de l’application. Certaines vulnérabilités ne sont donc jamais sollicitées dans le chemin d’exécution de l’application. Elles présentent alors moins de risques et peuvent être moins prioritaires.

Si votre outil AppSec fournit cette information, utilisez-la pour vous concentrer sur les problèmes les plus urgents. Plutôt que de prioriser une vulnérabilité grave dans une fonction que votre application n’appelle pas, il est bien plus efficace de traiter en priorité une vulnérabilité de gravité moyenne qui se trouve dans le chemin d’exécution et présente davantage de risques.

Vous pouvez établir vos priorités en appliquant l’une ou les deux approches complémentaires suivantes :

• Déterminer l’atteignabilité par l’analyse statique de votre code source

• Déterminer si les vulnérabilités sont réellement sollicitées à l’exécution

Gardez à l’esprit que cela ne signifie pas que les vulnérabilités qui ne sont pas atteintes sont sans importance et peuvent être ignorées. Elles doivent également être évaluées et corrigées, en particulier celles dont la gravité est élevée. L’atteignabilité vous aide toutefois à mieux distinguer ce qui est important de ce qui est urgent.

5. Ancienneté

Tenez compte de l’ancienneté des vulnérabilités lorsque vous définissez vos priorités. Plus une vulnérabilité est récente, par exemple, moins il est probable qu’un correctif soit disponible. Les pirates sont aussi généralement attirés par les vulnérabilités nouvelles et médiatisées, ce qui les rend encore plus risquées. Les algorithmes qui alimentent le Priority Score de Snyk, par exemple, intègrent l’ancienneté au score final selon cette même logique.

6. Facilité de correction

Une approche de sécurité consiste à corriger autant de problèmes que possible dans un délai donné. Si la rapidité est essentielle, envisagez de prioriser les problèmes les plus faciles, les plus rapides et les moins coûteux à corriger.

Pour cela, essayez de répondre aux questions suivantes :

• Une mise à niveau mineure permet-elle de corriger la vulnérabilité ?

• Un correctif est-il disponible pour cette vulnérabilité ?

• Le composant vulnérable peut-il être facilement remplacé ?

7. Automatisation

Pour hiérarchiser et déprioriser des centaines, voire des milliers de problèmes dans les différents projets de votre organisation, l’automatisation est indispensable. Si vos outils de sécurité offrent cette possibilité, utilisez des stratégies pour définir automatiquement les paramètres qui guideront vos décisions de hiérarchisation lors des corrections.

Vous pourriez, par exemple, augmenter la gravité de toutes les vulnérabilités associées à un CWE particulier. Ou réduire automatiquement la gravité des problèmes pour lesquels aucun exploit connu n’existe.

Ces décisions dépendent de l’activité et varient d’une organisation à l’autre, et d’une équipe à l’autre. Toutefois, l’automatisation et le contrôle précis qu’offrent les stratégies sont indispensables à toute stratégie de hiérarchisation.

Les avantages d’une hiérarchisation efficace des vulnérabilités des applications web

Une hiérarchisation efficace vous aide à vous concentrer sur les vulnérabilités qui présentent le plus grand risque pour votre organisation et à tirer le meilleur parti du temps et des efforts que vous y consacrez, renforçant ainsi votre posture de sécurité globale.

Comme nous l’avons vu, le CVSS seul ne suffit pas pour bien hiérarchiser les vulnérabilités. Les organisations ont besoin de solutions qui fournissent un contexte plus riche et plus approfondi. Plus ces outils sont faciles à utiliser et adaptés aux développeurs, plus ceux-ci sont susceptibles de les adopter, un facteur essentiel à la réussite de vos efforts de hiérarchisation et de correction. C’est précisément ce que propose Snyk.