Best of breed : la souplesse a un prix, la maîtrise des vulnérabilités
Une plateforme Data moderne assemble souvent plusieurs briques open source. Ce choix reste courant, même face au retour des plateformes all-in-one - mais il a un revers : le parc devient vite difficile à cartographier.
Une plateforme Data moderne assemble souvent plusieurs briques open source : un orchestrateur (Kestra, Airflow), une base analytique, dbt, Spark, des images Docker. Ce choix best of breed reste courant, même face au retour des plateformes all-in-one, parce qu'il permet de garder la main sur les bons outils. Je le vois encore très souvent chez mes clients.
Le revers de la médaille
Le parc devient vite difficile à cartographier. Savoir qu'on utilise Airbyte ou dbt ne suffit plus, il faut connaître les versions réellement déployées, leur exposition réseau et les vulnérabilités qui les concernent vraiment. Spoiler : personne n'a cette vue à jour dans un coin de sa tête.
CVE et CVSS, en deux mots
Recevoir une liste de CVE (l'identifiant d'une faille, au format CVE-2024-12345) ne suffit pas non plus. Sa gravité est mesurée par un score CVSS, entre 0 et 10. Sans ce score, la CVE est simplement « à qualifier » : on sait que le problème existe, mais pas encore à quel point il faut s'en inquiéter.
Un scanner né d'un besoin client
Un nouveau besoin client m'a donné l'occasion de construire un scanner qui automatise cette logique :
- inventaire CSV des composants, aujourd'hui déclaratif, avec pour chacun un identifiant standardisé de package (PURL, ex : pkg:pypi/apache-airflow) et/ou de version (CPE), plus la criticité et l'exposition réseau
- croisement automatique avec OSV (base de vulnérabilités open source) et NVD (base officielle du NIST américain), avec déduplication des CVE communes aux deux
- flag des vulnérabilités confirmées exploitées (catalogue CISA KEV)
- priorisation P1 à P4 : le flag KEV prime toujours sur le score, une faille exploitée passe devant une faille juste « critique »
- deux rapports : une vue architecture, qui consolide pour chaque composant sa version, son écart avec la dernière stable et sa pérennité (activité du projet), et une vue opérationnelle centrée sur les alertes à traiter
Au-delà de la sécurité
Pour le client, l'intérêt dépasse largement la sécurité : cette vue par composant sert aussi aux audits, aux montées de version et aux décisions d'architecture, pas seulement à la veille CVE. Et accessoirement, ça évite le fameux « on tourne sur quelle version de Kestra en prod déjà ? »
Ce qui reste à construire
Cette logique est aujourd'hui entièrement déterministe, sans IA : pas besoin d'un LLM pour comparer des scores CVSS. Les prochaines étapes : automatiser la collecte de l'inventaire, aujourd'hui déclaratif, puis ajouter un LLM pour résumer et rédiger les notes de remédiation, sans jamais lui laisser la priorisation.
La vraie question n'est pas « quelles vulnérabilités existent », mais « lesquelles concernent réellement ma plateforme, avec quel risque, et que dois-je traiter en premier ».
Si vous gérez une stack Data best of breed, comment traitez-vous ce sujet aujourd'hui ?
Une stack best of breed à sécuriser ?
Inventaire, priorisation des vulnérabilités, gouvernance des versions - échangeons.