Copy Fail è il tipo di vulnerabilità Linux che attira l’attenzione per una buona ragione: secondo quanto riportato pubblicamente, essa può fornire a un utente locale senza privilegi un percorso pratico per ottenere i privilegi di root su diverse distribuzioni principali, dispone di una prova di concetto pubblica e comporta implicazioni tra container poiché sfrutta il comportamento della cache delle pagine condivisa.
Per i team addetti alla sicurezza e alle operazioni, il problema non è solo il bug del kernel in sé. Si tratta della velocità con cui è possibile identificare i sistemi vulnerabili, stabilire le priorità tra quelli che presentano il rischio maggiore, applicare le patch e verificare che la modifica sia stata effettivamente implementata. Eppure, secondo , il 77% delle organizzazioni impiega più di una settimana per distribuire le patch a livello aziendale.
Che cos’è “Copy Fail”?
"Copy Fail" è una vulnerabilità di escalation dei privilegi locali di tipo " Linux " presente nel sottosistema crittografico del kernel. A livello generale, la vulnerabilità consente a un utente locale senza privilegi di eseguire una piccola operazione di scrittura controllata sui dati di un file supportati dalla cache di pagina. Nelle catene di exploit pubbliche, tale corruzione temporanea può essere indirizzata verso i contenuti memorizzati nella cache di un binario setuid, in modo che un’esecuzione successiva esegua codice controllato dall’autore dell’attacco con privilegi di root.
Diversi fattori rendono questa vulnerabilità particolarmente rilevante:
- Si tratta di un problema di escalation dei privilegi a livello locale con una via di sfruttamento concreta
- È stato descritto come affidabile e compatibile con le principali distribuzioni di Linux
- Non dipende da una condizione di competizione, come invece accadeva in molti vecchi attacchi di escalation dei privilegi di tipo “ Linux ”
- Ciò comporta implicazioni a livello trasversale tra i container, poiché la cache delle pagine è condivisa a livello di host
Il risultato è un rischio evidente: se un malintenzionato riesce a eseguire codice con i privilegi di un utente di basso livello su un sistema vulnerabile Linux , potrebbe essere in grado di ottenere l'accesso amministrativo completo.
Comprendere cosa contraddistingue questa vulnerabilità fornisce un contesto utile, ma la domanda più urgente per la maggior parte dei team è perché essa stia generando un’urgenza operativa proprio in questo momento.
Perché i team di sicurezza stanno prendendo la questione sul serio
Sebbene il numero di CVE relativi al kernel Linux sia aumentato notevolmente nel 2024, gran parte di tale aumento rifletteva i cambiamenti nelle pratiche di assegnazione CVE adottate dopo che il progetto del kernel era diventato un’Autorità di numerazione CVE , piuttosto che un aumento direttamente comparabile, su base annua, del rischio aziendale.
Non tutti i casi di gravità elevata Linux CVE comportano lo stesso livello di urgenza operativa. Copy Fail lo fa, per una serie di motivi.
È facile descriverlo dal punto di vista dell’autore dell’attacco
Le notizie diffuse dai media si sono concentrate su un codice di prova compatto scritto in Python in grado di prendere di mira un binario setuid, come ad esempio /usr/bin/su, e che, su sistemi vulnerabili, potrebbe consentire di elevare i privilegi da un punto di accesso con privilegi limitati a quelli di root. Quando una vulnerabilità è al tempo stesso comprensibile e riproducibile, i responsabili della sicurezza dovrebbero presumere che ne derivi un interesse concreto da parte degli aggressori. Un LPE simile del kernel è stato utilizzato a fini malevoli dagli autori di ransomware nel 2025.
La vulnerabilità interessa gli ambienti aziendali comuni di tipo “ Linux ”
È stato segnalato che la vulnerabilità interessa le distribuzioni di Linux rilasciate a partire dalla versione 2017, comprese piattaforme aziendali ampiamente diffuse quali:
- Amazon Linux
- Red Hat Linux per le aziende
- SUSE
- Ubuntu
- Debian e altri kernel di produttori le cui versioni dei pacchetti forniti includono il percorso di codice vulnerabile e non contengono ancora la correzione del produttore
L'ampiezza delle distribuzioni interessate è uno dei fattori che rendono questa questione una preoccupazione a livello dell'intera flotta, piuttosto che un problema isolato legato a una singola piattaforma.
I contenitori non eliminano il rischio
Questo è uno degli aspetti più importanti per i team che si occupano delle piattaforme, e non solo a causa delle ipotesi relative all’isolamento. L’errore di copia non è “solo” un problema dell’host. Poiché la cache delle pagine è condivisa tra i vari processi di un sistema, una vulnerabilità di questo tipo può mettere in discussione i presupposti relativi all’isolamento negli ambienti con kernel condiviso.
Tuttavia, la realtà operativa più immediata è che l’applicazione delle patch richiede un riavvio, e tale necessità di riavvio si applica all’intero parco macchine Linux . Per la maggior parte delle organizzazioni, ciò comporta interruzioni pianificate su larga scala, non un aggiornamento silenzioso in background.
Tale requisito di riavvio si estende a:
- Nodi di lavoro di Kubernetes
- Runner CI/CD condivisi
- Host di container multi-tenant
- Sandbox per l'esecuzione del codice
- Altri ambienti di elaborazione condivisi di Linux
In sintesi, qualsiasi ambiente in cui più carichi di lavoro vengano eseguiti su un host condiviso dovrebbe essere considerato potenzialmente a rischio qualora utenti privi di privilegi possano eseguire codice arbitrario.
RHEL e le distribuzioni compatibili dispongono di una misura di mitigazione in grado di ridurre l’esposizione senza richiedere un riavvio immediato; tuttavia, nella maggior parte degli ambienti, è inevitabile prevedere un periodo dedicato all’applicazione delle patch.
Una volta definito il profilo di minaccia, è utile comprendere i meccanismi alla base della vulnerabilità prima di procedere alla correzione.
Come funziona Copy Fail a livello generale
Senza addentrarsi nei dettagli del codice di exploit, il problema segnalato deriva da una vulnerabilità nella gestione di algif_aead nel sottosistema crittografico del kernel Linux . Una ricerca pubblica ha descritto un percorso che coinvolge AF_ALG, operazioni AEAD e la funzione splice(), il quale fa sì che i dati supportati dalla cache di pagina finiscano in una posizione in cui il kernel può eseguire una scrittura che non dovrebbe effettuare.
In termini pratici, la sequenza dell’attacco descritta pubblicamente si presenta come segue:
- Aprire un socket: Aprire un socket AF_ALG ed eseguire il binding alla trasformazione AEAD/crittografia autenticata interessata richiesta dall’exploit
- Costruire il payload: Creare l'input necessario per attivare il percorso di codice vulnerabile
- Corroggere il file di destinazione: Innescare un'operazione di scrittura nella copia memorizzata nella cache di un file binario di destinazione, ad esempio /usr/bin/su
- Eseguire il file binario: Eseguire il file binario mentre i suoi contenuti memorizzati nella cache sono danneggiati, in modo che il codice controllato dall'autore dell'attacco venga eseguito con i privilegi elevati del file binario
I dettagli tecnici costituiscono un contesto utile, ma l’aspetto operativo è di maggiore rilevanza: si tratta di una vulnerabilità a livello di kernel con un percorso di escalation locale ben definito.
Comprendere il funzionamento dell’exploit aiuta a chiarire il motivo per cui Copy Fail rientra in una categoria di rischio diversa rispetto a molti bug più datati relativi all’escalation dei privilegi di tipo “ Linux ”.
Cosa distingue Copy Fail dai precedenti bug di escalation dei privilegi di tipo “ Linux ”
I team di sicurezza mettono naturalmente a confronto i nuovi problemi relativi all’escalation dei privilegi in Linux con bug precedenti di grande risonanza. Copy Fail rientra in tale contesto, ma presenta un proprio profilo di rischio.
| Fattore | Errore di copia | Modelli LPE più datati della serie “ Linux ”, caratterizzati da un design fortemente ispirato alle auto da corsa |
|---|---|---|
| Affidabilità degli exploit | Considerato altamente affidabile | Spesso dipende dal momento |
| Necessità degli offset del kernel | Non è un elemento centrale del percorso di exploit segnalato | Spesso richiesto in alcune catene di exploit |
| Portabilità tra diverse distribuzioni | Segnalato nelle principali distribuzioni | Spesso più specifico per una determinata versione |
| Impatto dei container | Rilevante negli ambienti con kernel condiviso | Varia |
| Difficoltà di rilevamento | Difficile | Spesso difficili, ma alcuni percorsi sono più rumorosi |
È proprio questa combinazione di fattori che dovrebbe indurre i responsabili della sicurezza a resistere alla tentazione di considerare questo problema come “solo l’ennesimo bug locale”.
L’escalation dei privilegi locali rimane una delle fasi più importanti nelle moderne catene di attacco, in particolare a seguito del furto di credenziali, di attacchi di phishing, di controlli di accesso iniziali inadeguati o della compromissione di un’applicazione.
Risk definizione delle priorità relative alle forme dei profili. La domanda successiva è: quali sistemi dovrebbero avere la priorità nella lista degli interventi correttivi?
Chi è maggiormente esposto
Ogni vulnerabilità Linux endpoint richiede un intervento, ma alcuni ambienti dovrebbero avere la priorità.
Sistemi a massima priorità
- Sistemi " Linux " collegati a Internet in cui gli aggressori potrebbero già aver acquisito un punto d’appoggio a livello utente
- Nodi Kubernetes condivisi e host dei container
- Infrastruttura CI/CD e di compilazione in cui, durante la compilazione, vengono eseguite dipendenze di terze parti o codice fornito da altri
- Host Bastion e server di salto
- Postazioni di lavoro per sviluppatori con accesso privilegiato agli ambienti di produzione
- Server multiutente Linux in ambienti aziendali
Perché gli ambienti con kernel condiviso meritano un’attenzione particolare
È proprio la prospettiva trasversale tra i vari container a trasformare questa semplice operazione di correzione in una discussione sui rischi legati alla piattaforma.
Se il Suo confine di fiducia è principalmente “il container”, Copy Fail Le ricorda che i presupposti relativi al kernel condiviso rimangono fragili, in particolare in ambienti in cui all’interno dei container viene eseguito codice generato dall’intelligenza artificiale o non attendibile, oppure in cui i sistemi connessi a Internet accettano ed elaborano input esterni provenienti da fonti sconosciute.
Per molte organizzazioni, la vera domanda non è se la vulnerabilità sia grave. La questione è se sappiano esattamente quali carichi di lavoro siano attualmente in esecuzione su kernel vulnerabili.
Versioni interessate e stato della correzione
Le note informative disponibili al pubblico indicano che il problema risale a una modifica del kernel introdotta nella versione 2017. Sono state pubblicate correzioni stabili del kernel e le distribuzioni stanno integrando tali correzioni nei propri canali di aggiornamento.
Un modo sintetico per valutare se i vostri sistemi siano interessati dal problema è il seguente:
| Categoria | Stato |
|---|---|
| Sistemi che utilizzano kernel in cui è presente la logica vulnerabile | Potenzialmente esposti |
| I sistemi sono stati aggiornati con i pacchetti del kernel corretti dal fornitore | Problema risolto (riavvio confermato) |
| Sistemi che si basano esclusivamente sul monitoraggio, senza l’applicazione di patch | La vulnerabilità rimane esposta (il monitoraggio non risolve la vulnerabilità di fondo) |
| Host di container con kernel condiviso privi di correzioni del kernel | Elevato livello di preoccupazione |
Poiché i fornitori di soluzioni di gestione delle vulnerabilità ( Linux ) per le aziende effettuano il backport delle correzioni, l’unico modo giustificabile per verificare l’esposizione consiste nell’utilizzare le linee guida fornite dalla propria distribuzione, unitamente a una visibilità diretta sui pacchetti del kernel distribuiti e sullo stato di riavvio del sistema.
Una volta individuata l’esposizione, il passo successivo consiste nell’elaborare un piano di risposta chiaro e articolato in fasi.
Cosa fare in questo momento
Per la maggior parte delle squadre, il piano di intervento dovrebbe essere semplice e rapido.
1. Individuare i sistemi Linux esposti
Inizi con un inventario accurato di:
- Distribuzione e versione
- Versione del kernel in esecuzione
- Pacchetti del kernel installati
- Stato del riavvio dopo l'aggiornamento del kernel
- Ruolo di sistema, in particolare host di container o runner CI/CD
2. Stabilite le priorità in base al rischio, non limitandovi a un semplice conteggio
Patch tutto è vulnerabile, ma si raccomanda di applicare prima queste patch:
- Infrastruttura condivisa
- Server di fascia alta
- Sistemi con numerosi utenti interattivi
- Sistemi che eseguono regolarmente codice non attendibile o parzialmente attendibile
Un approccio alla gestione delle vulnerabilità basato sul rischio, come quello proposto da , risulta particolarmente utile in questo contesto, poiché il semplice numero di risorse è meno rilevante rispetto alla consapevolezza di quali sistemi Linux comportino i maggiori rischi operativi e di sicurezza.
3. Applicare la patch fornita dal produttore
Questa è l'azione fondamentale. In questo caso, gli aggiornamenti del kernel rappresentano la vera soluzione al problema. I team che devono agire rapidamente su larga scala si affidano generalmente a flussi di lavoro di gestione endpoint per la distribuzione delle patch , anziché considerare la correzione del kernel come un’operazione manuale una tantum.
4. Riavviare se necessario
Per quanto riguarda gli aggiornamenti convenzionali dei pacchetti del kernel, un pacchetto in fase di implementazione che non sia stato attivato tramite il riavvio con il nuovo kernel non costituisce una correzione completa. Se il Suo ambiente utilizza l'applicazione di patch al kernel in tempo reale, verifichi invece lo stato di livepatch.
5. Verifichi che la correzione sia stata implementata
Non si limiti a dire “la patch è stata implementata”. Si prega di verificare quanto segue:
- Il pacchetto aggiornato è stato installato
- L'host è stato riavviato, se necessario
- Il kernel attualmente in esecuzione è quello corretto
È proprio in questo contesto che lo stato attuale di endpoint assume un’importanza fondamentale, poiché il solo inventario dei pacchetti non dimostra che il kernel in esecuzione sia cambiato.
6. Si consideri una misura di mitigazione temporanea solo qualora l'applicazione della patch subisca un ritardo
Qualora fosse necessario rimandare l’applicazione della patch, alcune linee guida pubbliche hanno suggerito di disabilitare il percorso del modulo interessato come misura temporanea. Su RHEL e sulle distribuzioni compatibili, l’applicazione di questa misura correttiva richiede un riavvio, così come la sua rimozione per ripristinare le funzioni crittografiche interessate.
Tale realtà operativa dovrebbe essere presa in considerazione nel processo decisionale relativo al rischio, in particolare laddove le interruzioni non pianificate del servizio comportino conseguenze specifiche. Ciò non sostituisce l'applicazione delle toppe.
Verificare che le patch siano state applicate e che i sistemi siano stati riavviati è importante tanto quanto l'applicazione delle patch stessa. Ciò porta direttamente alle realtà relative al rilevamento e al monitoraggio che i team devono comprendere.
La realtà del rilevamento e del monitoraggio
È proprio qui che i difensori devono essere onesti. Se un malintenzionato riesce a sfruttare questa vulnerabilità, significa che i Suoi controlli di rilevamento e prevenzione hanno già fallito in una fase precedente.
Il rilevamento preventivo delle vulnerabilità è limitato, poiché il comportamento vulnerabile si verifica all’interno dei meccanismi legittimi del kernel. Ciò che il sistema di rilevamento può realisticamente offrire in questo caso è:
- Analisi dei comportamenti successivi allo sfruttamento
- Monitoraggio di modelli sospetti di esecuzione setuid
- Indagine sulle modifiche impreviste dei privilegi
- Monitoraggio delle attività successive dell'autore dell'attacco dopo l'ottenimento dell'accesso come root
È utile, ma non equivale alla prevenzione. Vulnerabilità come “Copy Fail” ci ricordano che il volume e il ritmo delle vulnerabilità CVE relative al kernel non stanno diminuendo e che un modello di applicazione delle patch di tipo reattivo avrà sempre più difficoltà a tenere il passo.
L’approccio più sostenibile consiste nell’applicazione continua delle patch, in cui la riduzione dei tempi di applicazione delle patch viene considerata una priorità operativa costante, piuttosto che una risposta a singole vulnerabilità (CVE).
Tanium'La nostra visione del rischio di "Copy Fail"
Non è una risposta piacevole, ma è quella più realistica: individuare l’attivazione della vulnerabilità a livello di kernel non è fattibile, mentre rilevare le tracce di un attacco in corso — script o file binari sconosciuti che si introducono nel sistema — è possibile grazie a strumenti quali Tanium e soluzioni dedicate EDR . L'applicazione delle patch rimane la risposta principale, ma non è l'unico livello di protezione disponibile. Laddove ciò sia operativamente fattibile, i team possono comunque monitorare o limitare l’interfaccia del kernel interessata e individuare eventuali comportamenti sospetti successivi.
Il modo in cui si inquadra la questione è importante. Copy Fail desta preoccupazione per la sua semplicità e per le sue caratteristiche di escalation dei privilegi locali, ma gli esperti di sicurezza dovrebbero distinguere la realtà operativa dal clamore mediatico.
La filosofia di risposta in questo caso è semplice e articolata in fasi successive:
- Individuare i sistemi Linux vulnerabili
- Dare priorità ai sistemi in cui l’escalation da utente locale a root comporta le conseguenze più gravi
- Patch il kernel
- Verifichi che la patch sia attiva
- Utilizzate la ricerca post-exploit solo come misura di controllo complementare, non come strategia principale
Per i clienti di “ Tanium ”, ciò corrisponde sostanzialmente a ciò che la piattaforma “ Tanium ” già consente ai team di fare nella gestione quotidiana delle vulnerabilità: ottenere una visibilità aggiornata sugli endpoint “ Linux ”, individuare i sistemi esposti e monitorare lo stato di avanzamento delle misure correttive.
Il punto fondamentale non è che Copy Fail introduca un flusso di lavoro completamente nuovo. Ciò conferma quanto siano essenziali una gestione continua delle vulnerabilità ( ) e una verifica rigorosa delle patch.
In sintesi
Il CVE-2026-31431 rappresenta un grave problema di escalation dei privilegi del kernel Linux , ma la risposta adeguata non è complicata. Non si tratta del tipo di questione in cui abbia senso fare promesse eccessive in materia di prevenzione basandosi esclusivamente sull’analisi dei dati. La posizione più giustificabile è quella di applicare la patch il prima possibile. Non è necessario un framework innovativo. Sono necessari visibilità, definizione delle priorità, applicazione delle patch e verifica.
Per i team addetti alla sicurezza e alle operazioni, ciò costituisce un utile promemoria del fatto che la gestione delle vulnerabilità raramente si limita a un semplice esercizio tecnico.
La sfida più ardua consiste nel mantenere il giusto equilibrio tra riservatezza, integrità e disponibilità, applicando al contempo le patch con sufficiente rapidità da ridurre i rischi senza compromettere le operazioni aziendali e le funzioni mission-critical che dipendono da tali sistemi.
Nelle organizzazioni di maggiori dimensioni, le attività di correzione e di ricerca delle minacce sono spesso gestite da team distinti e possono svolgersi contemporaneamente. Entrambi i percorsi possono e devono procedere in parallelo senza attendere l’uno l’altro.
Come si presenta una risposta aziendale efficace
I team che gestiscono efficacemente gli errori di copia solitamente adottano rapidamente quattro misure:
| Fase di risposta | Come si presenta la qualità |
|---|---|
| Valutazione dell'esposizione | Un elenco chiaro dei sistemi Linux vulnerabili nel giro di poche ore, non di giorni |
| Prioritization | In base all’esposizione della Sua organizzazione, alla Sua tolleranza al rischio e ai Suoi vincoli operativi |
| Remediation | Le patch del kernel vengono implementate rapidamente con un controllo operativo |
| Convalida | Stato del kernel in esecuzione confermato, non presunto |
È proprio in questo ambito che molte organizzazioni incontrano difficoltà. Potrebbero sapere che esiste un sito CVE , ma non sono in grado di rispondere immediatamente:
- Quali sistemi sono esposti?
- Quali servizi aziendali sono ospitati su tali sistemi?
- Quali host sono stati aggiornati ma non sono stati riavviati?
- Quali host di container non sono stati aggiornati e rappresentano ancora un rischio per i carichi di lavoro in esecuzione?
Si tratta di questioni operative, non di questioni di ricerca. Ed è proprio da questi elementi che dipende se un “ CVE ” si configura come un incidente.
Errori comuni da evitare
Considerare l’escalation dei privilegi locali come una priorità secondaria
Poiché per sfruttare questa vulnerabilità è necessario disporre già di un accesso locale, la sua risoluzione potrebbe essere considerata meno prioritaria rispetto ad altre esigenze immediate di applicazione delle patch. Si tratta di una decisione legittima in materia di rischio, ma l’impatto aziendale derivante dalla necessità di un percorso affidabile per raggiungere il root richiede comunque una tempistica definita per la risoluzione del problema.
Supponendo che i contenitori garantiscano una separazione sufficiente
Negli ambienti con kernel condiviso, tale presupposto può rivelarsi errato in breve tempo. Le organizzazioni che fanno un uso significativo dei container dovrebbero considerare la visibilità e la protezione a livello di " " per gli ambienti containerizzati , anziché dare per scontato che il solo livello di orchestrazione sia sufficiente a ridurre i rischi a livello di kernel.
Considerare l'implementazione del pacchetto come completamento della correzione
Le patch del kernel richiedono spesso una verifica tramite riavvio. Senza ciò, potreste ottenere solo progressi parziali.
In attesa di una logica di rilevamento perfetta
In caso di “Copy Fail”, attendere l’esito della logica di rilevamento pre-sfruttamento prima di agire rappresenta una strategia perdente. Patch In primo luogo. Qualora si sospetti uno sfruttamento, attribuite priorità ai flussi di lavoro relativi alla risposta post-violazione una volta che le operazioni di contenimento e di riparazione siano già in corso.
Domande frequenti sull’errore di copia
"Copy Fail" solleva questioni pratiche che vanno oltre l’avviso " CVE ". Di seguito sono riportate le domande più frequenti che i team aziendali addetti alla sicurezza e alle operazioni si pongono mentre procedono alla valutazione delle vulnerabilità e alla pianificazione delle misure correttive.
È possibile sfruttare il bug "Copy Fail" da remoto?
No. Si tratta di una vulnerabilità di escalation dei privilegi a livello locale, il che significa che un malintenzionato deve prima disporre di un accesso al sistema. È proprio a causa di tale requisito di accesso che alcune organizzazioni potrebbero non considerarlo una priorità; tuttavia, un percorso affidabile per ottenere i privilegi di root su un sistema a cui si è già avuto accesso comporta comunque conseguenze concrete per l’azienda e deve essere incluso nel Suo programma di correzione.
L’errore “Copy Fail” influisce sui container e su Kubernetes?
È possibile. Poiché i container condividono il kernel dell’host, un host vulnerabile può esporre i carichi di lavoro in container al rischio di LPE a livello del kernel locale. La possibilità di sfruttamento pratico dipende dall'accesso del container all'interfaccia del kernel interessata, dalla politica di sicurezza in fase di esecuzione e dal fatto che le pagine del file di destinazione siano condivise e raggiungibili da quel carico di lavoro.
Qual è la misura di mitigazione più efficace qualora non fosse possibile applicare immediatamente la patch?
Esistono misure di mitigazione temporanee, che sono state documentate sia dai fornitori interessati sia dal team di ricerca che ha individuato la vulnerabilità. Tuttavia, la vera soluzione consiste nell’applicare una patch al kernel. Le misure temporanee dovrebbero essere considerate come una riduzione del rischio di breve durata, non come una soluzione definitiva.
Come posso verificare se la correzione ha funzionato?
Si assicuri che il pacchetto del kernel corretto dal fornitore sia installato, verifichi se è stato necessario un riavvio e controlli che il kernel in esecuzione sia la versione corretta. La convalida dovrebbe concentrarsi sullo stato effettivo del kernel, non solo sullo stato di implementazione.
Perché questa vulnerabilità sta suscitando così tanta attenzione?
Poiché riunisce caratteristiche che i difensori non gradiscono: un’escalation affidabile da utente locale a root, un’ampia rilevanza in termini di “ Linux ”, una discussione pubblica sul proof-of-concept e implicazioni tra container. L’approccio di individuazione potenziato dall’intelligenza artificiale ha inoltre aumentato la visibilità, sebbene la risposta operativa rimanga piacevolmente semplice: applicare una patch.
La soluzione al problema "Copy Fail" è semplice: applicate una patch al kernel. Se il Suo team sta ancora valutando le vulnerabilità, Tanium può aiutarLa a identificare quali sistemi Linux ne necessitano, a stabilire le priorità in base al rischio e a verificare che la patch sia stata applicata in tutto il Suo ambiente.
Prenoti oggi stesso una demo gratuita su.
