Aller au-delà de l’accessibilité pour mieux hiérarchiser les priorités

La plupart des applications modernes contiennent un grand nombre de packages, de bibliothèques et de frameworks open source. En fait, on estime qu’au moins 80 % du code source des applications modernes est issu de l’open source. En plus de s’appuyer largement sur des composants courants pour créer leurs applications, les équipes de développement déploient souvent ces applications et services à partir d’images de base de conteneurs provenant de la communauté. Elles s’appuient aussi sur des ressources tierces comme les assistants de programmation basés sur l’IA pour générer du code propriétaire, accélérant encore davantage la chaîne d’approvisionnement logicielle.

Cette utilisation toujours croissante des bibliothèques open source, de l’IA générative et des conteneurs soulève de nouvelles questions en matière de licences et de sécurité. Près de 29 000 nouvelles vulnérabilités ont été découvertes rien qu’en 2023 (et déjà plus de 28 000 en 2024). Si l’histoire se répète, plus de la moitié de ces vulnérabilités nouvellement découvertes présenteront une gravité élevée ou critique. Autrement dit, certains des risques les plus importants pour vos applications — et potentiellement pour l’ensemble de votre organisation — proviennent de composants qui échappent à votre contrôle.

Les défis de la sécurité open source aujourd’hui

Trouver, hiérarchiser et corriger toutes les vulnérabilités open source dans vos applications est irréaliste. Même viser uniquement les vulnérabilités de gravité élevée dans vos dépendances tierces peut s’avérer difficile. Après tout, vous devez vous attaquer non seulement aux vulnérabilités récemment découvertes, mais aussi à l’ensemble du stock de vulnérabilités en attente dans votre base de code. Ce stock provient de différentes sources : vous en avez peut-être hérité, ou elles se trouvent peut-être dans un projet mis en œuvre bien avant que vous commenciez à rechercher les vulnérabilités open source.

Même les petits projets peuvent compter des centaines de vulnérabilités dans des dizaines de dépendances directes (c’est-à-dire explicitement déclarées dans les manifestes de dépendances). Ils en comptent probablement encore davantage parmi leurs dépendances indirectes ou « transitives », c’est-à-dire les bibliothèques dont les dépendances directes ont besoin pour fonctionner. Multipliez tout cela par le nombre de projets de votre organisation, et vous obtenez une liste interminable.

Les techniques de hiérarchisation statique ne suffisent pas

De nombreuses entreprises s’appuient sur des facteurs de risque statiques, comme la gravité NVD/CVSS, pour commencer à trier cette longue liste de vulnérabilités et déterminer lesquelles corriger en premier. Cependant, ces instantanés du risque ne tiennent pas compte de nombreux facteurs importants pour une hiérarchisation précise et efficace.

De nouveaux facteurs de risque, comme l’EPSS (système de notation de la prédiction d’exploitation), cherchent à intégrer davantage d’informations sur la vulnérabilité, mais omettent encore des détails essentiels, comme le contexte général de l’application ou de l’entreprise. À l’instar d’autres facteurs de risque statiques, l’EPSS reste centré de façon étroite et cloisonnée sur des problèmes individuels, plutôt que sur vos applications. Chaque problème évalué par l’EPSS est propre à un CVE donné, au lieu de refléter ce qui a le plus d’impact sur l’ensemble de votre organisation.

De nombreuses entreprises se sont tournées vers l’analyse d’accessibilité pour améliorer leurs techniques de hiérarchisation statique et mieux comprendre quelles vulnérabilités corriger en priorité. L’analyse statique de l’accessibilité examine la définition de la vulnérabilité, repère où elle se trouve dans une version donnée d’une bibliothèque, puis cherche à déterminer s’il existe un chemin d’appel entre votre code propriétaire et la fonction où la vulnérabilité se trouve probablement. Les équipes peuvent alors combiner différents signaux statiques, comme les données d’accessibilité et un score CVSS ou EPSS élevé, pour décider quelles corrections traiter en premier.

Si l’analyse statique de l’accessibilité peut contribuer à la hiérarchisation, elle peut aussi laisser des angles morts. Par exemple, elle peut aider à repérer les chemins de code qui appellent des fonctions vulnérables, mais l’inverse n’est pas vrai : elle ne peut pas déterminer avec certitude qu’une fonction n’est pas accessible. De plus, toutes les vulnérabilités ne fournissent pas les informations nécessaires à une analyse statique de l’accessibilité. Il existe toutefois des techniques permettant d’identifier les fonctions vulnérables dans les packages open source. Par exemple, Snyk s’appuie sur une solution basée sur l’IA qui évalue les commits de correction pour les déterminer.

En définitive, combiner l’analyse statique de l’accessibilité avec CVSS/EPSS améliore les méthodes de hiérarchisation, mais il est possible de les améliorer encore en intégrant un élément de contexte essentiel : l’importance d’un artefact pour l’activité de l’entreprise. Les équipes doivent donc tenir compte de facteurs contextuels en plus de l’analyse statique de l’accessibilité afin de hiérarchiser précisément les vulnérabilités selon le risque réel pour l’entreprise.

Les organisations ont besoin d’une approche globale de la hiérarchisation des risques

N’oubliez pas qu’une gravité élevée et l’accessibilité d’une vulnérabilité ne signifient pas qu’elle est exploitable.

Examinons cette idée : imaginons deux vulnérabilités. La première, de gravité critique et « accessible », s’exécute dans un environnement de test interne pour les développeurs. La seconde, de gravité moyenne et sans données d’accessibilité, s’exécute en production. Laquelle faut-il corriger en premier ? Et si la vulnérabilité de gravité moyenne en production est associée à un exploit facile et bien connu, et se trouve dans un conteneur exposé à Internet en périphérie du réseau ? La vulnérabilité de gravité moyenne peut sembler être le choix évident, mais les seuls signaux statiques pourraient en réalité faire passer la vulnérabilité de l’environnement de test en priorité !

Cet exemple montre que l’analyse statique de l’accessibilité ne donne souvent qu’une partie de la situation. Si elle fournit des indications pour hiérarchiser les vulnérabilités, elle ne permet pas aux équipes de gérer les risques dans leur ensemble. Corriger un grand nombre de vulnérabilités critiques peut sembler positif sur le papier, mais le véritable impact vient de la correction des vulnérabilités qui présentent le plus grand risque pour votre entreprise et ses résultats financiers.

Voici quelques autres signaux qui peuvent combler les lacunes de l’analyse statique de l’accessibilité :

• La vulnérabilité concerne-t-elle le système d’exploitation sur lequel le service s’exécute ?

• L’application est-elle essentielle à l’activité de l’entreprise ? Quel rôle précis joue-t-elle et comment contribue-t-elle aux fonctions clés de l’entreprise ?

• L’application est-elle déployée ? Si oui, où l’est-elle ? Est-elle accessible au public ou exposée à Internet, et les packages sont-ils chargés ?

• Le service concerné par la vulnérabilité a-t-il accès à des données sensibles ?

Hiérarchisation contextuelle des risques avec Snyk

Comme les entreprises ne peuvent pas corriger toutes les vulnérabilités open source — ni même toutes celles de gravité élevée ou critique —, il est essentiel de hiérarchiser correctement les problèmes de sécurité. Chez Snyk, nous aidons les organisations non seulement à détecter et corriger les vulnérabilités logicielles, mais aussi à hiérarchiser les mesures correctives selon les risques réels pour l’entreprise. Nos solutions renforcent les processus de sécurité des applications des organisations grâce aux fonctionnalités suivantes :

• La hiérarchisation fondée sur les risques permet aux organisations de comprendre clairement la probabilité d’une exploitation et les conséquences qu’elle pourrait entraîner.

• L’analyse de l’accessibilité du code au cloud, qui comprend l’analyse statique de l’accessibilité, portant sur le code et les fonctions vulnérables, ainsi que l’analyse dynamique de l’accessibilité, qui examine l’environnement de l’application déployée et en cours d’exécution. Notre solution s’appuie sur l’IA et est validée par des experts en sécurité, ce qui renforce sa précision et sa couverture.

• Le contexte de l’application, provenant des outils de gestion du code source (SCM), des portails pour les développeurs, des CMDB et d’autres sources. Ce contexte détaillé permet aux entreprises de mieux cibler les vulnérabilités à traiter en fonction de la propriété du code, de l’actualité des dépôts et d’autres facteurs.

• La souplesse pour les entreprises, grâce à la possibilité d’intégrer directement des consignes propriétaires de sécurité et de conformité à la solution Snyk.

• Un score de risque global, facile à exploiter dans vos activités de sécurité des applications. Ces scores permettent aux utilisateurs de hiérarchiser les problèmes SCA dans tout leur environnement ou d’approfondir l’analyse pour comprendre l’impact de facteurs de risque spécifiques, notamment l’accessibilité statique.

Découvrez le fonctionnement de Snyk AppRisk en regardant notre démonstration à la demande.