SecFlowX Story n° 1 — Des paquets vulnérables sans CVE

Au cours des dernières années, les bibliothèques et composants open source sont devenus une part indispensable de notre manière de développer des logiciels. Grâce à la puissance de la communauté, nous avons accès à des composants éprouvés qui résolvent des problèmes allant du plus trivial au plus complexe — du code revu par de nombreuses personnes et durci à la mesure de son utilisation.

C'est le côté du verre à moitié plein. Du côté vide se trouvent les acteurs malveillants. Les bibliothèques connues pour être utilisées par des milliers — voire des millions — de personnes constituent une cible attrayante pour atteindre un large public d'un seul coup, ou pour s'infiltrer dans leurs systèmes. C'est pourquoi les attaquants ciblent aujourd'hui les projets hébergés sur des registres de paquets tels que NPM, PyPI et GitHub.

Si un attaquant parvient à compromettre un paquet ou une application, il obtient un accès simultané à chaque système qui en dépend — c'est l'essence même d'une attaque de la chaîne d'approvisionnement logicielle.

CVE → NVD → SCA

Le parcours d'une vulnérabilité, depuis sa découverte dans une bibliothèque jusqu'à son enregistrement dans la NVD (National Vulnerability Database), puis à son exploitation par les outils d'analyse, nous permet d'utiliser des outils SCA (Software Composition Analysis) pour déterminer si une vulnérabilité signalée par un chercheur est présente dans les projets de notre organisation.

La place de SecFlowX

SecFlowX offre une vue détaillée à la fois au niveau du projet et de l'organisation. Les dépendances des applications et leur statut de vulnérabilité peuvent être obtenus soit via une intégration CI/CD, soit via des analyses déclenchées directement depuis SecFlowX.

Des vulnérabilités sans CVE

Mais qu'en est-il d'un paquet ou d'une application malveillante dépourvue d'identifiant CVE ? L'un des problèmes les plus préoccupants pour les organisations à l'heure actuelle, ce sont les paquets malveillants sans CVE. Le code malveillant injecté dans LiteLLM en est l'un des exemples les plus clairs — aucun CVE n'avait été attribué à l'époque.

Une analyse grype exécutée sur un projet type épinglant litellm==1.82.8 ne renvoie aucune détection du paquet vulnérable. Ce n'est pas la faute de grype ni d'aucun outil SCA — la base de données ne contient tout simplement aucun enregistrement de ce type.

Alors, comment résoudre ce problème ? La réponse est claire : par le suivi de l'inventaire des paquets. Si nous connaissons toutes les dépendances et les informations de version des projets de notre organisation, nous pouvons vérifier si un composant affecté est présent. L'analyse de ce même projet via SecFlowX confirme que la bibliothèque litellm==1.82.8, connue comme vulnérable, est présente dans notre inventaire — et ce sans avoir eu besoin du moindre identifiant CVE.

Synthèse

Les attaques de la chaîne d'approvisionnement logicielle et les défenses qui s'y opposent deviennent chaque jour plus critiques. Savoir quels composants existent dans l'inventaire d'une organisation n'est plus optionnel — c'est une exigence absolue. SecFlowX contribue à rendre vos processus de sécurité applicative existants plus sûrs et plus durables.