Politique de veille et de gestion des vulnérabilités
Cette politique décrit comment France Nuage surveille les vulnérabilités qui touchent sa plateforme et comment elle y répond. Elle décline, sur ce volet, les principes de notre politique de sécurité de l'information et couvre les contrôles A.5.7, A.8.7, A.8.8, A.8.19 et A.8.23 de la déclaration d'applicabilité.
Nos contrôles sont auto-évalués, alignés sur ISO/IEC 27001, non certifiés par un tiers à ce jour. Le statut de chaque mesure ci-dessous reflète cette auto-évaluation.
Objet et périmètre
La politique s'applique à l'ensemble de la pile que nous exploitons : composants open source auto-hébergés, dépendances applicatives, images de conteneurs, systèmes d'exploitation des nœuds et services managés que nous opérons pour nos clients. Elle couvre la veille, la qualification, la correction et la vérification des vulnérabilités.
Principes
- Nos composants critiques sont open source. Nous pouvons lire le code, suivre les avis amont et corriger sans attendre le calendrier d'un éditeur.
- Corriger plutôt que contourner. La mise à jour du composant est la réponse par défaut ; le filtrage en frontal réduit l'exposition en attendant, il ne remplace pas le correctif.
- Réduire la surface avant de la surveiller. Registre interne, images à surface réduite, admission durcie et refus réseau par défaut limitent ce qui peut être atteint.
- Une faille signalée est une contribution. Les chercheurs qui nous signalent une vulnérabilité bénéficient d'un cadre publié et de notre protection juridique.
- Un correctif se vérifie. Une vulnérabilité n'est close qu'une fois la version corrigée déployée et l'exposition constatée disparue.
Mesures
| Domaine | Mesure |
|---|---|
| Veille | Veille CVE et avis de sécurité sur l'ensemble de la pile, appuyée par un agent de veille ; pas encore de source automatique pour le catalogue des vulnérabilités activement exploitées (KEV) (A.5.7). |
| Correctifs | Mises à jour de dépendances automatisées, intégrées seulement si l'ensemble des conditions de recette de la chaîne d'intégration continue est satisfait (A.8.8). |
| Analyse en CI | Analyse de secrets bloquante en intégration continue ; détection CVE automatisée (analyse de dépendances) à câbler dans la CI (A.8.8, partiel). |
| Logiciels malveillants | Réduction de la surface : registre interne, images à tag épinglé, admission durcie. Analyse antimalware dédiée des images à ajouter à la chaîne CI (A.8.7, partiel). |
| Provenance des logiciels | Provenance maîtrisée par le registre interne, les tags épinglés et l'admission de sécurité ; épinglage par empreinte (digest) et admission bloquante à renforcer (A.8.19, partiel). |
| Filtrage en frontal | CrowdSec bloque devant l'edge public les adresses IP qui sondent des vulnérabilités connues, ce qui freine l'exploitation de masse. Son module AppSec y ajoute des correctifs virtuels (virtual patching) qui bloquent l'exploitation de CVE connues, sans remplacer un correctif ; couverture à généraliser aux autres points d'entrée (A.8.23, partiel). |
| Signalement externe | Canal public de signalement, accusé de réception sous 48 heures et règles du jeu publiées dans notre politique de divulgation responsable (A.6.8). |
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette politique, de la qualification des vulnérabilités et de l'arbitrage des correctifs urgents.
- L'astreinte SRE traite les vulnérabilités exploitées ou activement exploitables comme un incident, selon la procédure de gestion des incidents.
- Toute personne de l'équipe qui repère une vulnérabilité, dans notre code ou dans un composant amont, la signale à security@france-nuage.fr.
- Les signalements externes arrivent sur le même canal et suivent le même traitement.
Statut et trajectoire
La veille sur les menaces est partielle (A.5.7). Elle couvre l'ensemble de la pile et alimente nos décisions de mise à jour, mais ne dispose pas encore d'une source automatique pour les vulnérabilités activement exploitées. Le délai cible de traitement est fixé par notre charte de gestion des correctifs, sans indicateur qui en mesure encore le respect. Les quatre autres contrôles de cette politique sont aussi partiels, et nous préférons le dire :
- A.8.8, vulnérabilités techniques : mises à jour de dépendances automatisées et analyse de secrets opérationnelles ; détection CVE automatisée à câbler dans la CI.
- A.8.7, logiciels malveillants : surface réduite par construction ; analyse antimalware des images à ajouter à la chaîne CI.
- A.8.19, installation de logiciels : provenance maîtrisée ; épinglage par empreinte et admission bloquante à renforcer.
- A.8.23, filtrage web : blocage des IP hostiles et pare-feu applicatif à signatures (CrowdSec) en place sur l'edge public ; couverture à généraliser aux autres points d'entrée.
Au-delà de ces quatre chantiers, la revue indépendante de la sécurité reste planifiée (A.5.35). Un test d'intrusion externe est prévu lors du passage de la certification ISO 27001, notre revue interne reposant aujourd'hui sur la veille CVE et la revue obligatoire des demandes de fusion.
Revue
Cette politique est revue au moins une fois par an et à chaque évolution significative de notre pile technique ou de nos moyens de détection.
Dernière revue : 31 août 2026.
Voir aussi
- Déclaration d'applicabilité (le statut des contrôles A.5.7, A.8.7, A.8.8, A.8.19 et A.8.23)
- Politique de divulgation responsable (comment nous signaler une vulnérabilité et ce que nous garantissons en retour)
- Politique de développement sécurisé (la chaîne d'intégration continue dans laquelle ces analyses s'exécutent)
- Politique de gestion des changements (le circuit par lequel un correctif atteint la production)
- Charte de gestion des correctifs (les voies, le délai cible et les garde-fous d'application d'un correctif)
- Modèle de sécurité (la chaîne d'approvisionnement logicielle et les couches de défense associées)