Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Une grande partie des logiciels qui font fonctionner le monde est maintenue pendant le temps libre de certaines personnes. Une bibliothèque qui se retrouve intégrée à des milliers de systèmes de production peut n’avoir derrière elle qu’un ou deux responsables de maintenance, souvent bénévoles, qui concilient ce travail avec leur emploi principal. Ce modèle a permis à l’open source de parcourir un long chemin, mais il atteint ses limites précisément au moment où la sécurité en dépend le plus : lorsqu’une vulnérabilité doit être signalée, se voir attribuer un identifiant CVE, faire l’objet d’une coordination et être divulguée dans des délais stricts.
La gestion d’un processus coordonné de divulgation et d’attribution de numéros CVE représente un véritable travail. Cela implique de trier les rapports, de réserver un identifiant, de rédiger un compte-rendu justifiable, de coordonner un embargo et de publier dans les délais. Pour un responsable de maintenance déjà débordé, ce processus peut prendre du retard, et pour les logiciels ayant atteint leur fin de vie, il se peut qu’il n’y ait tout simplement aucun processus actif. Il en résulte une lacune dont toute la communauté en aval fait les frais : une vulnérabilité existe, mais la référence commune sur laquelle tout le monde s'appuie pour la suivre et la hiérarchiser apparaît tardivement, voire jamais. Ce n’est pas un échec des responsables de maintenance. Il s’agit d’un décalage structurel entre l’ampleur de l’utilisation de l’open source et le manque de ressources dont souffre une grande partie de ce secteur.
TuxCare est désormais en mesure de prendre en charge une partie de cette charge.
L'annonce
Le programme CVE a agréé TuxCare en tant qu’autorité de numérotation CVE (CNA). Cela signifie que TuxCare peut attribuer des identifiants CVE et publier des fiches CVE pour les vulnérabilités présentes dans les produits qu’elle gère et distribue, notamment Endless Lifecycle Support (ELS) et SecureChain for OSS. Vous trouverez tous les détails dans notre communiqué de presse.
En quoi consiste réellement le métier d'aide-soignant ?
Une « autorité de numérotation CVE » est une organisation à laquelle le programme CVE confère le pouvoir d'attribuer des identifiants CVE et de publier les fiches associées dans un périmètre défini. La liste CVE alimentée par ces fiches constitue une infrastructure partagée : les scanners, les systèmes SIEM, les flux de renseignements sur les menaces et les avis des éditeurs utilisent tous les identifiants CVE comme référence commune pour désigner une même vulnérabilité.
Une fiche CVE ne constitue pas un aperçu exhaustif d'une vulnérabilité. Elle sert de point de coordination. La CNA peut attribuer un score de gravité et une classification de la faille directement dans l’enregistrement lui-même – c’est ce que fera TuxCare –, tandis que les systèmes en aval, tels que la National Vulnerability Database, y ajoutent des informations complémentaires, l’état d’exploitation et les détails de la correction, le tout référencé par cet identifiant CVE. Le moment où l’identifiant est attribué et publié est donc crucial, car c’est à ce moment-là que tous les systèmes en aval peuvent commencer à suivre le problème de manière coordonnée.
Lorsqu’aucun CNA ne couvre un logiciel donné, un rapporteur doit se rabattre sur le CNA de dernier recours (CNA-LR) du programme CVE. Cette solution fonctionne, mais elle ajoute une étape intermédiaire entre les personnes chargées de corriger la vulnérabilité et celles chargées de publier sa fiche ; or, ces étapes supplémentaires entraînent un temps d’attente supplémentaire. Pour les logiciels dont dépendent de nombreuses personnes, ce décalage constitue un problème.
Quels changements pour les utilisateurs de ce logiciel ?
Pour les vulnérabilités présentes dans les produits relevant du champ d’application du CNA de TuxCare, l’attribution, la documentation et la correction s’inscrivent désormais dans un processus unique et coordonné, TuxCare faisant office de source officielle de référence. Une vulnérabilité confirmée relevant de ce champ d’application se voit attribuer un identifiant CVE dans les 24 heures après son triage, une fiche publiée et un correctif correspondant – sans passer par la file d’attente d’un tiers.
Les logiciels en fin de vie méritent une mention particulière. Lorsqu’un projet arrive en fin de vie, le processus de divulgation du responsable de la maintenance s’essouffle généralement, alors que le logiciel continue de fonctionner en production pendant des années. Les CNA peuvent inclure les versions en fin de vie dans leur périmètre et leur attribuer des CVE plutôt que de les laisser suivre la voie de secours – et c’est exactement ce que fait TuxCare via son programme ELS. Pour les organisations qui utilisent encore ces logiciels, cela fait toute la différence entre une vulnérabilité suivie, documentée et corrigible, et une vulnérabilité laissée sans surveillance.
En quoi cela s'inscrit-il dans les activités actuelles de TuxCare ?
TuxCare propose déjà des correctifs pour ces logiciels. SecureChain recompile et corrige les paquets open source activement maintenus dans les registres publics ; Endless Lifecycle Support prend en charge les systèmes d'exploitation, les bibliothèques et les environnements d'exécution de langages arrivés en fin de vie. Ces deux solutions reposent sur le même principe : les logiciels open source dont dépendent les utilisateurs doivent rester sécurisés, que leurs mainteneurs continuent à les mettre à jour ou qu'ils aient cessé de s'en occuper.
Le rôle de la CNA s'inscrit directement dans cette logique. TuxCare fournit déjà le correctif ; désormais, elle peut également gérer la fiche relative à la vulnérabilité à laquelle ce correctif remédie. L'attribution et la correction ne sont plus deux étapes distinctes gérées par deux entités différentes selon des calendriers différents. Elles deviennent un processus unique, coordonné par la même organisation qui est déjà responsable du correctif.
Et maintenant ?
Le principe général est simple. L’open source est le moteur du secteur, et une grande partie de ce logiciel est maintenue par des personnes qui n’ont jamais eu pour vocation de gérer une opération de divulgation des failles de sécurité. Les décharger d’une partie de cette charge de coordination pour les logiciels pris en charge par TuxCare constitue une petite solution structurelle à un problème structurel. C’est le genre de contribution qui correspond à une organisation dont le travail a toujours commencé là où la maintenance open source atteint ses limites.
