La majeure partie du travail qui garantit la fiabilité d'un produit de sécurité est invisible. Les utilisateurs voient une analyse terminée, une menace bloquée, une mise à jour appliquée pendant la nuit. Ils ne voient pas la plateforme sous-jacente : environnements d'exécution, bibliothèques gérées, pilotes natifs, etc. Windows Les exigences doivent toutes rester à jour et fonctionner ensemble sur des millions de points de terminaison. Notre migration vers .NET 10 illustre notre démarche pour assurer la continuité de cette plateforme et constitue le sujet principal de cet article.
Il serait facile de qualifier ces mises à niveau de simples tâches de maintenance et de passer à autre chose. Mais ce serait les minimiser. Notre code s'exécute en continu, avec des privilèges élevés, à proximité de certaines des parties les plus sensibles de Windows .
Chaque dépendance de notre pile logicielle, qu'il s'agisse de l'environnement d'exécution, des bibliothèques tierces, des pilotes natifs ou des exigences du système d'exploitation, influe sur l'environnement dans lequel notre logiciel s'exécute. Toute modification apportée à l'une d'entre elles peut nécessiter une modification de l'ensemble des éléments qui en dépendent.
Le problème : les plateformes prennent du retard en restant immobiles.
En matière de sécurité des terminaux, le terrain est en perpétuelle évolution. Windows Les technologies évoluent. Les menaces évoluent. Le matériel évolue, passant des ordinateurs portables ARM64 à des machines dotées de beaucoup plus de mémoire et d'un stockage plus rapide que celles pour lesquelles notre code a été initialement conçu.
Une plateforme qui stagne ne reste pas la même. Elle prend du retard. Chaque mise à jour manquée d'une dépendance ou d'un environnement d'exécution creuse l'écart entre l'écosystème sur lequel nous l'avons bâti et celui qui est stable aujourd'hui.
Un environnement d'exécution moderne, et .NET 10 en particulier, nous offre une sécurité renforcée, des exécutions plus rapides, une empreinte mémoire réduite et des diagnostics plus complets. Il apporte également à nos ingénieurs des améliorations au niveau du langage et des outils, ce qui leur permet de travailler plus efficacement.
Les enjeux sont également particulièrement élevés pour les logiciels de sécurité :
- Une application web peut être restaurée après son déploiement. Ce n'est pas le cas pour un logiciel déjà installé sur le poste client.
- Notre code s'exécute avec des privilèges élevés, aux côtés des pilotes du noyau et des protections anti-falsification.
- Une régression d'exécution n'affecte pas un seul serveur. Elle peut potentiellement affecter des millions de machines.
Nous traitons donc une mise à jour en cours d'exécution avec la même rigueur qu'une fonctionnalité de sécurité.
Le défi : tout bouge ensemble
Malwarebytes pour Windows Il ne s'agit pas d'un programme unique. C'est un système coordonné : une interface utilisateur, plusieurs processus de longue durée Windows services, un programme d'installation, un pipeline de mise à jour automatique, une interface de plugins et des dépendances gérées par des tiers.
Ces éléments se situent au-dessus des pilotes natifs et de notre moteur de détection. La migration vers .NET 10 a couvert les parties managées de Malwarebytes tout en laissant ce noyau natif intact. Mais les différentes couches doivent toujours fonctionner ensemble.
La migration devait satisfaire simultanément plusieurs exigences :
- Le code sensible en matière de sécurité devait se comporter de manière identique avant et après la modification.
- Les pilotes natifs et les couches anti-falsification devaient continuer à fonctionner correctement avec le code géré.
- Le processus d'installation et de mise à jour devait déployer les nouveaux fichiers d'exécution et supprimer les anciens.
- Les plugins et les dépendances tierces devaient rester compatibles.
- Existant Malwarebytes Les installations devaient continuer à fonctionner.
- Notre système de validation automatisée devait être suffisamment complet pour que l'on puisse faire confiance au résultat sans avoir à inspecter chaque chemin manuellement.
La frontière entre code managé et code natif mérite une attention particulière. Le code managé de nos services communique avec les composants natifs via des interfaces telles que P/Invoke et COM. Une modification à l'exécution peut subtilement affecter la manière dont ces différentes parties interagissent. Malwarebytes communiquer et travailler ensemble.
Ces différences pourraient ne jamais apparaître lors d'une démonstration. Elles pourraient n'apparaître que sur une machine sur 10 000. L'important est de les détecter avant les clients.
Les mises à jour ne se ressemblent pas toutes.
Il existe trois raisons principales pour lesquelles nous mettons à jour une dépendance : soit nous le décidons, soit la plateforme sous-jacente nous y oblige, soit une vulnérabilité nous y contraint. Chaque cas a son propre calendrier.
Modernisation optionnelle. Nous pouvons choisir de passer à un nouvel environnement d'exécution, à une nouvelle version majeure d'une bibliothèque ou à une nouvelle fonctionnalité de la plateforme afin de bénéficier de nouvelles fonctionnalités, de correctifs ou d'améliorations de sécurité.
Évolution des exigences de la plateforme. À mesure que ces exigences évoluent, certaines contraintes de compatibilité anciennes peuvent freiner la modernisation. Par exemple, la migration vers .NET 10 nous a permis de mettre à jour l'architecture de base de l'application et d'adopter un environnement d'exécution plus récent et pris en charge. Dans le cadre de cette même évolution, Windows La prise en charge de la version 7 a été abandonnée.
Correctifs imposés. Il arrive qu'une vulnérabilité soit découverte dans une bibliothèque que nous distribuons ou dans un système dont nous dépendons. La modification devient alors obligatoire et nous ne maîtrisons pas le calendrier. En revanche, nous pouvons contrôler notre préparation : les tests, le processus de publication et le déploiement progressif qui nous permettent de réagir rapidement sans créer de nouveaux problèmes.
Des raisons différentes et des échéanciers différents, mais chaque situation exige la même approche rigoureuse.
La migration .NET : pourquoi nous l’avons faite
Passer à .NET 10 offre Malwarebytes une base plus sûre, plus solide et plus performante pour Windows , avec plusieurs avantages cumulatifs :
Sécurité. Un environnement d'exécution moderne bénéficie des efforts continus de Microsoft en matière de sécurité, notamment des paramètres par défaut plus sûrs, un chiffrement renforcé et des correctifs pour les failles de mémoire et d'interopérabilité. Utiliser un environnement d'exécution activement pris en charge par Microsoft nous permet de continuer à appliquer des correctifs dès la découverte de vulnérabilités.
Une base solide et pérenne. Ce n'est peut-être pas la raison la plus glamour, mais .NET 10 nous permet de rester sur une plateforme prise en charge et activement développée, mieux alignée sur les versions plus récentes de Windows Cela facilite l'intégration des correctifs, fonctionnalités et améliorations futurs dans le cadre du travail de routine plutôt que de projets ponctuels.
Diagnostic et observabilité. Les versions modernes de .NET intègrent des fonctionnalités de traçage, de métriques et de diagnostic des incidents plus robustes. Dans un produit de sécurité, il est essentiel de comprendre le comportement du code en production. Un meilleur diagnostic nous aide à identifier et à résoudre les problèmes de fiabilité.
Performances et gestion de la mémoire. Les dernières versions de .NET ont amélioré le compilateur JIT, le ramasse-miettes et les bibliothèques principales. Nos processus s'exécutent en continu en arrière-plan ; leur efficacité et leur gestion de la mémoire sont donc cruciales. Ces améliorations nous offrent davantage de possibilités d'optimisation, même si l'impact variera selon les composants.
La migration .NET : comment nous l’avons réalisée
Le principe directeur est simple : ne jamais aller plus vite que ne le permettent les preuves.
Nous avons commencé par isoler le travail sur une branche dédiée. Nous avons ensuite réorienté la plateforme et mis à jour toutes les dépendances gérées afin que le nouvel environnement d'exécution et le code source s'accordent précisément sur les composants à déployer.
Cela a rapidement mis en évidence certaines des conséquences moins évidentes de la mise à niveau : des bibliothèques renommées ou intégrées à l’environnement d’exécution, des fichiers devenus inutiles et de nouveaux fichiers qui ont dû être fournis à leur place.
Le déploiement est facile à négliger et coûteux à rater. Une migration en cours d'exécution ne concerne pas seulement le code exécuté, mais aussi ce qui est installé sur le disque du client.
Notre service d'installation et de mise à jour a dû s'adapter à la nouvelle structure de fichiers du runtime. Il a fallu supprimer les dépendances désormais fournies par ce dernier, cesser de distribuer des fichiers renommés et assurer un remplacement propre lors des nouvelles installations et des mises à jour existantes.
La réussite du déploiement fait toute la différence entre une mise à jour que les utilisateurs ne remarquent même pas et une mise à jour qui crée un problème de support.
Une fois la compilation fonctionnelle, l'attention s'est portée sur la validation.
La migration impliquait :
- Tests automatisés approfondis sur l'ensemble des services, des chemins d'installation et de mise à jour.
- Validation de la compatibilité par rapport aux configurations réelles et aux installations précédentes.
- Évaluation comparative des performances pour détecter les régressions au démarrage, en matière de mémoire et de comportement d'analyse.
- Déploiement progressif et par étapes, en commençant par de petites populations et en s'étendant seulement lorsque les résultats ont montré que cela ne présentait aucun danger.
- Surveillance continue et détection automatisée des régressions sur le terrain.
- Travail transversal entre les différentes fonctions : plateforme, assurance qualité, installation et mise à jour, et ingénierie des versions.
« Nous n’avons jamais progressé plus vite que ne le permettaient les preuves. Chaque étape devait passer au vert d’elle-même. »
La migration .NET : les compromis
Rien de tout cela n'était gratuit, et les choix impliquaient des compromis délibérés.
Le compromis concernant cette branche était la dérive. Isoler la migration protégeait le code principal, mais plus cette branche existait longtemps, plus elle risquait de diverger du développement actif. Nous avons géré ce risque par des intégrations fréquentes plutôt que de reporter une fusion importante et risquée à la fin.
Le compromis à faire lors du déploiement était la rapidité. Le déploiement progressif impliquait également que les clients reçoivent la mise à jour plus tard qu'avec un déploiement massif. Nous avons accepté ce compromis. Les retours d'expérience provenant de populations plus restreintes nous permettent de détecter les problèmes avant qu'une mise à jour ne soit déployée sur un nombre beaucoup plus important de terminaux.
Le compromis avec la compilation AOT résidait dans la flexibilité. La compilation anticipée peut améliorer les performances au démarrage, mais aussi contraindre le comportement dynamique. Nous l'avons appliquée de manière sélective, composant par composant, plutôt que systématiquement.
Ce que la migration vers .NET 10 signifie pour les clients
Le meilleur résultat des travaux d'infrastructure est que les clients en bénéficient sans avoir à y penser.
Sur .NET 10, ces avantages pour Malwarebytes Parmi nos clients figurent :
- Fiabilité accrue grâce à un environnement d'exécution entièrement pris en charge et activement maintenu.
- Une base plus sûre qui bénéficie des améliorations continues apportées à la sécurité de la plateforme.
- Accès aux nouvelles fonctionnalités et correctifs .NET.
- Meilleure prise en charge des versions plus récentes de Windows .
- Les outils .NET les plus récents peuvent nous aider à développer et à déployer plus rapidement de nouvelles protections.
Des leçons à retenir
Chacune de ces mises à jour — l’environnement d’exécution, les configurations de base, les correctifs de sécurité — renforce certaines convictions au sein de l’équipe.
Les mises à niveau de plateformes constituent des investissements stratégiques pour tout ce qui est construit par-dessus. La modernisation est d'autant plus efficace qu'elle est continue : plus une plateforme prend du retard, plus sa mise à niveau finale risque d'être complexe.
L'automatisation est particulièrement importante pour des changements de cette ampleur. Il en va de même pour les petites décisions, peu attrayantes, prises des années auparavant, comme le maintien de frontières claires entre les composants et la mise en place d'un processus de fabrication qui sait précisément ce qu'il livre.
Ce sont ces fondements qui rendent possibles les changements plus importants.
« La dette technique s'accumule comme la dette financière. La mise à niveau la moins coûteuse est celle que vous n'avez jamais reportée. »
Que se passera-t-il ensuite ?
Aucune mise à jour n'est un aboutissement. Chacune représente une étape d'un processus plus long : moderniser en continu, par étapes réfléchies, afin que la plateforme ne prenne jamais de retard. Les exigences de base évolueront. Des vulnérabilités surgiront sans prévenir. Chaque mise à jour sera soumise à la même rigueur : mêmes tests, même déploiement progressif et mêmes preuves à l'appui avant toute autre action.
C’est cette discipline qui constitue réellement un produit conçu pour fonctionner au quotidien, sur chaque machine, sans la moindre hésitation.
Malwarebytes pour Windows sur .NET 10 a été lancé en version 5.6.0. Il s'agit de la dernière étape d'un engagement de longue date à investir dans la plateforme sous-jacente au produit afin que la protection qu'il offre puisse continuer à s'améliorer.
« L'une des meilleures suites de cybersécurité au monde. »
D'après CNET.Lire leur critique →
