Vous savez que vos applications ne vivent pas dans une bulle. Elles sont composées de paquets open source, de conteneurs, de ressources gérées dans le cloud, de machines virtuelles (VM), d'API, et bien plus encore. Chaque partie a sa propre surface d'attaque et son propre scanner : les outils d'analyse statique du code (SAST) recherchent les vulnérabilités dans le code source, les outils d'analyse de la composition logicielle (SCA) scannent les dépendances, les outils de sécurité cloud surveillent les configurations, et les scanners de conteneurs recherchent les exploits connus dans les images.
Alors, une fois que tous ces scanners sont en place… vous êtes en sécurité, n'est-ce pas ?
En quelque sorte. Vous scannez certainement chaque couche.
Mais à quel prix ?
Pourquoi les scanners de sécurité vous submergent de faux positifs
Un scanner pourrait vous alerter sur une fonction vulnérable dans votre code, sans savoir qu'elle est protégée par une API en amont. Ou il pourrait détecter un danger concernant une CVE dans une couche de base de conteneur, ignorant que votre application réelle n'atteint jamais ce chemin de code. De même, un scanner cloud pourrait signaler un rôle IAM qui dépasse ses permissions, sans se rendre compte qu'il est uniquement lié à une charge de travail de staging qui ne peut pas accéder aux données de production.
Le résultat ? Vos équipes sont inondées d'une multitude de découvertes isolées. Oui, elles sont toutes techniquement exactes, mais elles sont accompagnées de peu de contexte pour déterminer si le problème est réellement dangereux.
Ou comme l'a récemment dit un ingénieur en sécurité d'une grande entreprise : « Pouvez-vous me dire si une vulnérabilité affecte mes joyaux de la couronne ou le menu virtuel du déjeuner ? »
Bien que les faux positifs et les faux négatifs isolés soient un risque, le risque majeur est de passer à côté des chaînes de dépendances qui déterminent si des problèmes apparemment inoffensifs se combinent pour former de véritables chemins d'exploitation — ou si de nombreux problèmes apparemment nuisibles n'en sont pas du tout.
Et nous l'entendons constamment de la part des équipes :
« Nous ne maîtrisons pas nos dépendances. »
La raison ? Il est trop difficile de gérer la chaîne d'approvisionnement ; les paquets open source apportent avec eux des dépendances indirectes. Même avec l'analyse de conteneurs ou les outils cloud-native, la plupart des organisations ne peuvent pas déterminer avec certitude ce qui est important. En conséquence, elles finissent par courir après les vulnérabilités de manière réactive.
Pourquoi le Contexte des Vulnérabilités est Important en Sécurité des Applications et Sécurité du cloud
Les outils SAST ou SCA typiques adoptent une approche très simpliste et littérale.
Par exemple, lorsqu'il détecte qu'un paquet est listé dans une CVE, il le signalera comme critique.
Cela semble être une bonne pratique sur le papier ; il vaut mieux être averse au risque après tout, penserait-on. Mais en réalité, cela ne fait que déclencher de fausses alertes car :
- Souvent, votre application n'appelle même pas la fonction vulnérable
- La fonction pourrait être enfouie dans une dépendance transitive que vous n'avez jamais directement touchée
- Ou elle se trouve derrière une importation destinée uniquement aux développeurs, qui n'est jamais déployée en production
Les équipes reçoivent donc une liste trop exhaustive de problèmes « critiques » et doivent passer des heures à les traquer, pour finalement se rendre compte qu'ils ne sont même pas critiques.
Parallèlement, les chemins réels qui pourraient être exploités peuvent passer inaperçus.
Construire un Graphe de Dépendances Complet à Travers le Code, les Conteneurs et le cloud
La raison pour laquelle de nombreux scanners fournissent des résultats bruyants ou incomplets est qu'ils ne disposent pas du contexte supplémentaire nécessaire pour apporter de la clarté. Les outils traditionnels traitent chaque couche — code source, packages open source, conteneurs, ressources cloud — comme des problèmes distincts, souvent gérés par des produits séparés.
Cela signifie qu'ils manquent d'un graphe de dépendances unique qui les unit tous. Il n'y a pas de visibilité inter-dépendances, ce qui signifie que vous serez informé de problèmes non critiques et risquez de passer à côté des problèmes qui comptent réellement.
Mais la visibilité ne concerne pas seulement le contexte ; elle concerne aussi la cohérence. Les gestionnaires de packages gèrent tous les vulnérabilités transitives différemment.
Par exemple :
- npm/yarn en JavaScript offrent des arbres de dépendances et permettent de surcharger/épingler les paquets imbriqués.
- Maven en Java peut importer des versions de bibliothèques inattendues, nécessitant des configurations supplémentaires pour exclure les packages transitifs risqués.
Sans un graphe unifié, les équipes finissent par ajouter des outils supplémentaires juste pour maîtriser ce qu'elles ont déployé.
Certains ingénieurs pensent : « si nous ne l'avons pas installé directement, cela ne peut pas nous nuire » ; ce qui aggrave le problème. Les vulnérabilités résident à plusieurs niveaux de profondeur.
Alors, que devraient faire les équipes ?
Utiliser l'analyse d’accessibilité pour Éliminer les Fausses Alertes dans les Dépendances
Une véritable analyse d’accessibilité devrait signifier que, plutôt que de simplement signaler « vous avez un paquet vulnérable dans le graphe », votre plateforme peut déterminer si votre code est :
- Réellement en train d'appeler la fonction vulnérable, ou
- Impliqué dans une faille exposée à l'entrée utilisateur, ou
- Exécuté dans un conteneur accessible depuis internet
Si la réponse à toutes ces questions est non, alors il l'ignore. Si oui, il remonte l'information.
Il est également crucial de filtrer les vulnérabilités transitives liées aux dépendances de développement ou aux packages de test qui ne sont jamais déployés en production. Cela permet de réduire considérablement le bruit, ce qui signifie moins de faux positifs et plus de temps pour les développeurs afin de se concentrer sur la création de logiciels.
La plupart des scanners peuvent vérifier si un package est répertorié dans un CVE. Mais très peu peuvent tracer si votre code réel appelle la fonction vulnérable, s'il est intégré dans un conteneur exposé à internet, et s'il s'exécute sur une ressource cloud avec un IAM risqué — le tout dans une seule vue.
Corrélation des vulnérabilités à travers le code, les conteneurs et les configurations cloud
C'est un point crucial. Comprendre ce qui se passe partout est essentiel pour faire gagner un temps considérable à votre équipe et réduire les risques d'être pris au dépourvu.
Cela signifie étendre ce graphe de dépendances au-delà du niveau des packages, vers les conteneurs, l'infrastructure as code, les configurations cloud — et superposer l'analyse d'accessibilité sur l'ensemble de ces éléments.
Par exemple, il pourrait demander :
- Cette vulnérabilité affecte-t-elle vos dépendances ? Oui
- Est-elle réellement appelée par votre application ? Non
- Est-elle intégrée dans un conteneur déployé avec un accès public ? Non
→ Ignorer - Cette vulnérabilité nécessite-t-elle l'ouverture d'un port spécifique ? Oui
- La vulnérabilité est-elle présente dans une machine virtuelle cloud ? Oui
- Le port requis est-il ouvert sur la VM ? Non
→ Ignorer
Remédiation automatique : Corriger les vulnérabilités réelles plus rapidement
Une fois confirmée comme une vulnérabilité réelle et accessible, le scénario idéal est de déterminer la mise à niveau minimale sûre et de la corriger automatiquement.
Certains outils peuvent :
- Déterminer automatiquement la mise à niveau minimale sûre
- Vérifier qu'elle ne rompra pas vos contraintes semver
- La corriger automatiquement sans introduire de régressions
Cela signifie plus de recherche manuelle de dépendances, et beaucoup moins de nuits blanches.
Gérer les dépendances dans le cadre d'une stratégie de sécurité unifiée
En liant votre code, vos conteneurs et vos configurations cloud dans un seul graphe, vous réduisez le bruit et voyez ce qui est réellement exposé. Plus de fausses alertes à gérer.
Et lorsqu'il y a un problème réel, il n'est pas seulement signalé — il est corrigé. Ainsi, votre équipe passe moins de temps à fouiller des alertes inutiles et plus de temps à livrer.
Découvrez comment Aikido scanne les dépendances de développement pour les CVE dans notre documentation. Découvrez notre solution de gestion des vulnérabilités tout-en-un, ici.
Sécurisez votre logiciel dès maintenant.
