La maggior parte del lavoro che mantiene un prodotto di sicurezza affidabile è invisibile. Gli utenti vedono una scansione completata, una minaccia bloccata, un aggiornamento applicato durante la notte. Non vedono la piattaforma sottostante. Runtime, librerie gestite, driver nativi e Windows Tutti i requisiti devono rimanere aggiornati e funzionare in modo integrato su milioni di endpoint. La nostra migrazione a .NET 10 è un esempio di come manteniamo la piattaforma in continua evoluzione, ed è proprio questo l'argomento principale di questo articolo.
Sarebbe facile definire questi aggiornamenti attività di manutenzione e passare oltre. Ma questo significa sottovalutarli. Il nostro codice viene eseguito continuamente, con privilegi elevati, accanto ad alcune delle parti più sensibili di Windows .
Ogni dipendenza nel nostro stack, dal runtime alle librerie di terze parti, dai driver nativi ai requisiti del sistema operativo, influisce sull'ambiente in cui il nostro software viene eseguito. Quando una di queste dipendenze cambia, anche tutto ciò che ne dipende potrebbe dover cambiare.
Il problema: le piattaforme restano indietro rimanendo ferme
Nel campo della sicurezza degli endpoint, il terreno è in continuo movimento. Windows Si evolve. Le minacce si evolvono. L'hardware si evolve, dai laptop ARM64 alle macchine con molta più memoria e archiviazione più veloce rispetto a quelle per cui il nostro codice è stato inizialmente scritto.
Una piattaforma che rimane immobile non resta tale. Rimane indietro. Ogni rilascio saltato di una dipendenza o di un runtime allarga il divario tra l'ecosistema su cui abbiamo costruito la piattaforma e quello stabile di oggi.
Un runtime moderno, e in particolare .Net 10, può offrirci maggiore sicurezza, percorsi di esecuzione del codice più veloci, un minore consumo di memoria e strumenti di diagnostica più completi. Inoltre, fornisce ai nostri ingegneri miglioramenti al linguaggio e agli strumenti che consentono loro di lavorare in modo più efficiente.
La posta in gioco è particolarmente alta anche per i software di sicurezza:
- Un'applicazione web può essere ripristinata tramite un'implementazione. Il software già installato sul dispositivo di un cliente non può essere ripristinato.
- Il nostro codice viene eseguito con privilegi elevati, insieme ai driver del kernel e alle protezioni anti-manomissione.
- Una regressione in fase di esecuzione non riguarda un singolo server, ma può potenzialmente interessare milioni di macchine.
Pertanto, trattiamo un aggiornamento in fase di esecuzione con lo stesso rigore riservato a una funzionalità di sicurezza.
La sfida: tutto si muove insieme
Malwarebytes per Windows Non è un singolo programma. È un sistema coordinato: un'interfaccia rivolta all'utente, diversi processi a lunga esecuzione Windows servizi, un programma di installazione, una pipeline di autoaggiornamento, un'interfaccia per i plugin e dipendenze gestite da terze parti.
Questi si trovano al di sopra dei driver nativi e del nostro motore di rilevamento. La migrazione a .NET 10 ha riguardato le parti gestite di Malwarebytes lasciando intatto il nucleo nativo. Ma i diversi strati devono comunque lavorare insieme.
La migrazione doveva soddisfare contemporaneamente diversi requisiti:
- Il codice sensibile alla sicurezza doveva comportarsi in modo identico prima e dopo la modifica.
- I driver nativi e i livelli anti-manomissione dovevano continuare a funzionare correttamente con il codice gestito.
- Il processo di installazione e aggiornamento doveva distribuire i nuovi file di runtime e rimuovere quelli vecchi.
- I plugin e le dipendenze di terze parti dovevano rimanere compatibili.
- Esistente Malwarebytes Gli impianti dovevano continuare a funzionare.
- La nostra validazione automatizzata doveva essere sufficientemente estesa da poter considerare affidabile il risultato senza dover ispezionare manualmente ogni percorso.
Il confine tra codice gestito e codice nativo merita particolare attenzione. Il codice gestito nei nostri servizi comunica con i componenti nativi tramite interfacce come P/Invoke e COM. Una modifica in fase di esecuzione può influenzare in modo sottile il modo in cui queste diverse parti di Malwarebytes comunicare e lavorare insieme.
Queste differenze potrebbero non emergere mai durante una dimostrazione. Potrebbero manifestarsi solo su una macchina su 10.000. Individuarle prima che lo facciano i clienti è fondamentale.
Non tutti gli aggiornamenti sono uguali
Ci sono tre motivi principali per cui aggiorniamo una dipendenza: lo scegliamo noi, la piattaforma sottostante ce lo impone oppure una vulnerabilità ce lo rende necessario. Ognuno di questi motivi comporta una tempistica diversa.
Modernizzazione facoltativa. Possiamo scegliere di passare a un nuovo runtime, a una nuova versione principale di una libreria o a una nuova funzionalità della piattaforma per sfruttare nuove caratteristiche, correzioni o miglioramenti della sicurezza.
Modifiche alla baseline. Con l'evoluzione dei requisiti della piattaforma, alcuni vincoli di compatibilità precedenti possono ostacolare la modernizzazione. Ad esempio, il passaggio a .NET 10 ci ha permesso di aggiornare la baseline dell'applicazione e di adottare un runtime più recente e supportato. Come parte dello stesso cambiamento, Windows Il supporto 7 è stato deprecato.
Patch forzate. A volte viene scoperta una vulnerabilità in una libreria che distribuiamo o in un sistema da cui dipendiamo. La modifica non è più facoltativa e la tempistica non dipende da noi. Ciò che possiamo controllare è la nostra preparazione: i test, il processo di rilascio e l'implementazione graduale che ci consentono di rispondere rapidamente senza introdurre nuovi problemi.
Motivi e tempistiche diverse, ma ognuno richiede lo stesso approccio scrupoloso.
La migrazione a .NET: perché l'abbiamo fatta
Il passaggio a .NET 10 offre Malwarebytes una base più sicura, supportata e capace per Windows , con numerosi benefici cumulativi:
Sicurezza. Un runtime moderno beneficia del continuo lavoro di Microsoft in materia di sicurezza, che include impostazioni predefinite più sicure, una crittografia più robusta e soluzioni per i bug di memoria e di interoperabilità. Rimanere su un runtime supportato attivamente da Microsoft significa poter continuare ad applicare correzioni non appena vengono scoperte vulnerabilità.
Una base supportata. Potrebbe non essere un motivo affascinante, ma .NET 10 ci mantiene su una piattaforma supportata e attivamente sviluppata che è meglio allineata con le versioni più recenti di Windows In questo modo è più facile integrare correzioni, funzionalità e miglioramenti futuri nel lavoro di routine anziché considerarli progetti una tantum.
Diagnostica e osservabilità. Le moderne versioni di .NET offrono funzionalità integrate più avanzate di tracciamento, metriche e diagnostica degli arresti anomali. In un prodotto di sicurezza, è fondamentale comprendere il comportamento del codice sul campo. Una diagnostica più efficace ci aiuta a identificare e risolvere i problemi di affidabilità.
Prestazioni ed efficienza della memoria. Le recenti versioni di .NET hanno migliorato il compilatore just-in-time, il garbage collector e le librerie principali. I nostri processi vengono eseguiti in background tutto il giorno, quindi la loro efficienza e la gestione della memoria sono fondamentali. Queste funzionalità ci offrono maggiori opportunità di migliorare l'efficienza, sebbene l'impatto vari a seconda dei componenti.
La migrazione a .NET: come l'abbiamo realizzata
Il principio guida è semplice: non procedere mai più velocemente di quanto le prove consentano.
Abbiamo iniziato isolando il lavoro su un ramo dedicato. Abbiamo riadattato la piattaforma e aggiornato tutte le dipendenze gestite in modo che il nuovo runtime e il codice sorgente concordassero esattamente su quali componenti includere.
Ciò ha fatto emergere fin da subito alcune delle conseguenze meno ovvie dell'aggiornamento: librerie che erano state rinominate o integrate nel runtime, file che non erano più necessari e nuovi file che dovevano essere distribuiti al loro posto.
La fase di implementazione può essere facilmente trascurata, ma un errore può costare caro. Una migrazione in fase di esecuzione non riguarda solo il codice in esecuzione, ma anche ciò che finisce sul disco del cliente.
Il nostro servizio di installazione e aggiornamento ha dovuto apprendere la nuova struttura dei file del runtime. Ha dovuto rimuovere le dipendenze fornite dal runtime attuale, smettere di distribuire file rinominati e fornire le sostituzioni in modo pulito sia durante le nuove installazioni che durante gli aggiornamenti sul posto.
Eseguire correttamente l'implementazione fa la differenza tra un aggiornamento che gli utenti non notano nemmeno e uno che crea un problema di supporto.
Una volta verificato il corretto funzionamento del processo di compilazione, l'attenzione si è spostata sulla validazione.
La migrazione ha comportato:
- Test automatizzati approfonditi su tutti i servizi, i percorsi di installazione e di aggiornamento.
- Validazione della compatibilità rispetto a configurazioni reali e installazioni precedenti.
- Esecuzione di benchmark delle prestazioni per individuare regressioni nell'avvio, nella gestione della memoria e nel comportamento di scansione.
- Metodo canarino e implementazione graduale, iniziando con piccole popolazioni ed espandendosi solo quando i risultati hanno dimostrato che era sicuro farlo.
- Monitoraggio continuo e rilevamento automatico delle regressioni sul campo.
- Lavoro interfunzionale che coinvolge i team di sviluppo della piattaforma, controllo qualità, installazione e aggiornamento, e ingegneria del rilascio.
“Non siamo mai andati oltre i limiti consentiti dalle prove. Ogni passaggio doveva diventare verde da solo.”
La migrazione a .NET: i compromessi
Niente di tutto ciò era gratuito e le scelte implicavano compromessi consapevoli.
Il compromesso sul ramo era la deriva. Isolare la migrazione proteggeva il codice sorgente principale, ma più a lungo quel ramo esisteva, più poteva divergere dallo sviluppo attivo. Abbiamo gestito questo rischio attraverso integrazioni frequenti anziché rimandare un'unica grande e rischiosa fusione alla fine.
Il compromesso nella distribuzione è stato la velocità. La distribuzione graduale ha anche significato che i clienti hanno ricevuto l'aggiornamento più tardi rispetto a un rilascio unico e immediato. Abbiamo accettato questo compromesso. I dati provenienti da popolazioni più piccole ci offrono l'opportunità di individuare i problemi prima che un aggiornamento raggiunga un numero molto maggiore di dispositivi.
Il compromesso nell'implementazione dell'AOT (Ahead-of-Time) era la flessibilità. La compilazione anticipata può migliorare le prestazioni all'avvio, ma può anche limitare il comportamento dinamico. L'abbiamo applicata in modo selettivo, componente per componente, anziché ovunque per impostazione predefinita.
Cosa significa la migrazione a .NET 10 per i clienti
Il risultato migliore di un intervento infrastrutturale è che i clienti ne beneficiano senza doverci pensare.
Su .NET 10, questi vantaggi per Malwarebytes Tra i clienti figurano:
- Affidabilità migliorata su un ambiente di runtime completamente supportato e attivamente manutenuto.
- Una base più sicura che beneficia dei continui miglioramenti in termini di sicurezza della piattaforma.
- Accesso alle nuove funzionalità e correzioni di .NET.
- Supporto migliore per le versioni più recenti di Windows .
- I nuovi strumenti .NET possono aiutarci a sviluppare e fornire nuove soluzioni di protezione più rapidamente.
Lezioni da conservare
Ciascuno di questi aggiornamenti – relativi al runtime, alle baseline, alle patch di sicurezza – rafforza ulteriormente le convinzioni del team.
Gli aggiornamenti delle piattaforme rappresentano investimenti strategici in tutto ciò che viene costruito su di esse. La modernizzazione, inoltre, funziona al meglio quando è continua: più a lungo una piattaforma rimane obsoleta, più difficile diventerà l'eventuale aggiornamento.
L'automazione è particolarmente importante per cambiamenti di questa portata. Lo sono altrettanto le piccole decisioni, spesso poco appariscenti, prese anni prima, come mantenere confini netti tra i componenti e disporre di un processo di compilazione che sappia con precisione cosa spedire.
Sono queste fondamenta a rendere possibili cambiamenti più ampi.
"Il debito tecnico si accumula come il debito finanziario. L'aggiornamento più economico è quello che non hai mai rimandato."
Cosa succederà dopo?
Nessun aggiornamento rappresenta un traguardo finale. Ognuno di essi è un passo in un percorso più lungo: modernizzare continuamente, con passi ponderati, in modo che la piattaforma non rimanga mai indietro. Le linee di base cambieranno di nuovo. Le vulnerabilità emergeranno senza preavviso. Ognuna di esse dovrà seguire la stessa disciplina: gli stessi test, la stessa implementazione graduale e le stesse prove prima di procedere.
È proprio questa disciplina a rendere possibile un prodotto affidabile, progettato per funzionare quotidianamente su qualsiasi dispositivo, senza pensarci due volte.
Malwarebytes per Windows su .NET 10 è stato rilasciato nella versione 5.6.0. Si tratta dell'ultimo passo di un impegno di lunga data volto a investire nella piattaforma su cui si basa il prodotto, in modo che la protezione offerta possa continuare a migliorare.
“Una delle migliori suite di sicurezza informatica al mondo.”
Secondo CNET.Leggi la loro recensione →
