Il ritmo delle correzioni di sicurezza nel kernel Linux è cambiato in modo brusco. Per anni le release hanno viaggiato attorno a 500 CVE corrette; oggi ci si avvicina a 2.000, con la possibilità che Linux 7.3 superi quella soglia. La causa indicata non è un crollo improvviso della qualità del codice, ma la diffusione di modelli LLM capaci di analizzare la vasta codebase del kernel e di segnalare un numero crescente di potenziali vulnerabilità.

Questa accelerazione merita di essere letta in modo controintuitivo: un aumento delle CVE non equivale automaticamente a un sistema meno sicuro. Una parte rilevante del fenomeno è prodotta dalla maggiore capacità di osservazione, non da un aumento proporzionale dei difetti reali. Gli LLM abbassano il costo per trovare candidati interessanti, ma non riducono il costo per verificarli, correggerli e distribuire le patch. Il collo di bottiglia si sposta quindi dalla scoperta alla gestione.

Il collo di bottiglia non è più la scoperta

Quando il numero di CVE per release cresce di quattro volte, cambia anche il valore informativo di ogni singola segnalazione. Centinaia di CVE possono essere gestite una a una; migliaia costringono a introdurre priorità automatiche, filtri e triage. Per i maintainer del kernel, questo significa più tempo speso a separare i problemi reali dai falsi positivi e dalle segnalazioni a basso impatto. Per le distribuzioni e per chi fornisce kernel con supporto a lungo termine, il carico si moltiplica: ogni CVE deve essere valutata, eventualmente retroportata e testata su più rami.

Il punto strutturale è che gli LLM riducono il costo marginale della scoperta, ma il costo marginale della correzione resta legato al lavoro umano e ai cicli di integrazione. In un ecosistema come quello del kernel Linux, dove la fiducia si costruisce sulla revisione incrementale, l'asimmetria tra scoperta e correzione può allungare la coda delle vulnerabilità note e non ancora risolte.

Il conto per chi gestisce infrastrutture self-hosted

Chi opera server Linux self-hosted, incluse le macchine usate per l'inference di modelli locali, riceve questa pressione sotto forma di patch di sicurezza più frequenti. La scelta tra applicare subito una correzione e rimandarla per non interrompere un carico di lavoro diventa più frequente. In contesti on-premise, il controllo diretto sulla piattaforma porta con sé anche il costo operativo della gestione delle vulnerabilità: più CVE significano più manutenzione, più test di regressione e più finestre di manutenzione.

Questa dinamica non elimina i vantaggi del self-hosting, ma li rende più espliciti. Per chi valuta deployment on-premise di stack LLM, il carico di patching è uno dei fattori da includere nel calcolo del TCO e della sovranità dei dati. AI-RADAR offre framework analitici su /llm-onpremise per confrontare questi trade-off, senza ridurre la scelta a una semplice preferenza tecnicica.

Il fatto che ci si avvicini a 2.000 CVE per release può sembrare un indicatore di insicurezza. In realtà segnala che la capacità di analisi automatizzata sta superando la capacità di assorbimento del processo di sviluppo. La domanda aperta non è se gli LLM troveranno più bug, ma se l'ecosistema del kernel saprà trasformare questa ondata di segnalazioni in correzioni efficaci senza paralizzare i maintainer.