Mises à jour de sécurité d'une pile d'IA développée en interne : ce qu'il faut prévoir

Quelles couches ont besoin de mises à jour de sécurité ?

Couche	Exemples	Points d’attention
Système d’exploitation	distribution Linux	mises à jour de la distribution, planifier les redémarrages
Pilotes des GPU	pilotes et bibliothèques de calcul du fabricant	les versions doivent correspondre au logiciel du modèle
Conteneurs et orchestration	Docker, Kubernetes	avis de sécurité propres, reconstruire les images
Logiciel du modèle	vLLM, Ollama et similaires	versions fréquentes, interface souvent sans connexion propre
Interface	Open WebUI, LibreChat et similaires	versions rapprochées, failles dans le navigateur des personnes
Bases de données et recherche	PostgreSQL, index de recherche	mises à jour avec migration des données, sauvegarder avant
Bibliothèques	paquets Python et leurs dépendances	souvent des centaines, gérables seulement avec des outils
Fichiers de modèles	modèles issus de dépôts publics	vérifier l’origine, préférer les formats sans code exécutable

Les couches dépendent les unes des autres. Une mise à jour du logiciel du modèle peut exiger un pilote plus récent, un nouveau pilote un nouveau système d’exploitation. C’est pourquoi chaque mise à jour s’accompagne d’un test de l’ensemble.

À quelle fréquence les logiciels d’IA présentent-ils des failles critiques ?

Plus souvent qu’on ne l’attendrait de projets jeunes. Trois exemples tirés de sources publiques :

• Ollama : en 2024, Wiz Research a découvert une faille (CVE-2024-37032) permettant à des attaquants d’écraser des fichiers sur le serveur et d’exécuter ainsi du code ; corrigée à partir de la version 0.1.34. Wiz a souligné que l’interface d’Ollama ne prévoit par défaut aucune connexion.
• vLLM : en 2025, plusieurs failles ont été publiées, dont certaines classées critiques dans des fonctions d’exploitation sur plusieurs serveurs (par exemple CVE-2025-32444), et une autre par laquelle du code était chargé depuis un dépôt externe alors que cette option était désactivée (CVE-2025-66448).
• Open WebUI : en 2025, plusieurs failles ont été corrigées, par lesquelles du code injecté pouvait s’exécuter dans le navigateur des personnes.

Cisco Talos a montré en septembre 2025 combien d’installations sont accessibles sans protection : une recherche a trouvé plus de 1 100 serveurs Ollama accessibles depuis Internet sans connexion. Ce n’est pas un argument contre ces projets, qui corrigent en général rapidement leurs failles. Cela montre que l’exploitant doit aussi appliquer les mises à jour.

À quoi ressemble un déroulé pour les mises à jour de sécurité ?

1. Connaître l’inventaire : une liste de tous les composants avec leur version, idéalement sous forme de nomenclature logicielle (SBOM), générée automatiquement.
2. Suivre les avis : s’abonner aux avis de sécurité des projets sur GitHub, de la distribution et du fabricant des cartes graphiques ; des outils comparent l’inventaire aux failles connues (CVE).
3. Évaluer : la fonction concernée est-elle active et accessible chez vous ? Quelle est la gravité de la faille ?
4. Tester : appliquer la mise à jour dans un environnement de test, vérifier la connexion, les réponses et les connexions aux systèmes.
5. Appliquer : dans la fenêtre de maintenance ou, pour les failles critiques, immédiatement, avec une sauvegarde préalable.
6. Pouvoir revenir en arrière : si une mise à jour échoue, l’état précédent doit pouvoir être restauré.
7. Documenter : ce qui a été appliqué et quand, pour la révision et les auditeurs.

Le BSI (Office fédéral allemand de la sécurité de l’information) décrit les exigences relatives à ce déroulé dans le module IT-Grundschutz OPS.1.1.3 Gestion des correctifs et des changements. NIS2 range expressément le traitement des vulnérabilités parmi les obligations des entités concernées (art. 21, par. 2, point e).

Qu’est-ce qui aide en plus des mises à jour ?

• Rien d’exposé sur le réseau : interfaces des modèles accessibles uniquement en interne, accès uniquement via l’interface avec connexion.
• Peu de fonctions : désactiver ce qui n’est pas utile, par exemple l’exploitation sur plusieurs serveurs ou les connexions externes dans l’interface.
• Versions figées : pas de mises à jour automatiques depuis Internet en production, mais des versions vérifiées et fixées.
• Responsabilité avec suppléance : la gestion des correctifs est une tâche permanente. Voir facteur bus.

Comment cela fonctionne-t-il avec basebox ?

Les mises à jour et correctifs de sécurité sont inclus dans la licence. Chaque version passe par des contrôles des dépendances sur les vulnérabilités connues (CVE) et une analyse statique du code ; en cas de vulnérabilité connue, la version échoue. Chaque version est accompagnée d’une nomenclature logicielle (SBOM) et de notes de version, et vous êtes informé par e-mail. Dans le cloud, basebox applique les mises à jour, les mises à jour de sécurité urgentes aussi en dehors de la fenêtre de maintenance. Sur le serveur, rien ne s’installe automatiquement : sans contrat d’exploitation, vous appliquez les mises à jour et examinez sans délai les mises à jour de sécurité urgentes, sans Internet sous forme de paquet hors ligne via votre dépôt interne. Sur demande, nous exploitons votre serveur à distance. Les images ne sont pas encore signées ; la signature est en préparation. D’ici là, les empreintes (digests) des images prouvent qu’elles n’ont pas été modifiées.

Remarque : exemples de failles d’après les sources citées, état au 11 octobre 2026. Vous trouverez les avis actuels sur les pages des projets.