Le segnalazioni di bug generate dall'IA travolgono i manutentori del software DNS

I manutentori del software DNS open source di NLnet Labs affermano che un afflusso di segnalazioni di sicurezza generate dall'IA sta ora consumando quasi tutto il loro tempo di sviluppo, lasciando poco spazio per nuove funzionalità. Gli sviluppatori dietro il resolver DNS ricorsivo Unbound, ampiamente utilizzato, il server dei nomi autoritativo NSD e il validatore RPKI Routinator descrivono un cambiamento iniziato sul serio negli ultimi dodici mesi, quando i Large Language Model (LLM), i sistemi di intelligenza artificiale che alimentano strumenti come Claude, sono diventati ampiamente disponibili. In un resoconto dettagliato di Alex Band, l'organizzazione spiega che il cambiamento tocca due aree contemporaneamente: i contributi di codice della comunità e il volume di segnalazioni di vulnerabilità di sicurezza che arrivano alla loro porta. È una storia sul costo umano dell'automazione della ricerca di difetti del software e su ciò che i manutentori open source devono alla salute a lungo termine di un codice da cui dipende gran parte del nucleo di Internet.

NLnet Labs non è un tipico progetto di comunità open source. Sviluppa software per standard Internet come DNS (il Domain Name System, la rubrica di Internet), BGP (Border Gateway Protocol, il linguaggio di routing tra reti) e RPKI (un framework di sicurezza per il routing Internet). Il codice è scritto in C e Rust e l'organizzazione opera in piccoli team dedicati con una roadmap, una pianificazione dei progetti e rilasci programmati, molto simile a un'azienda commerciale. Tutto è open source e con licenza liberale, ma in 25 anni i progetti hanno ricevuto pochissimi contributi esterni oltre a piccole correzioni di bug e refusi. Occasionalmente arriva una pull request sostanziale, spesso da un'organizzazione che ha personalizzato Unbound per il proprio caso d'uso e vuole unire tali modifiche upstream per non dover più riapplicare le patch a ogni nuova release. In uno scenario ideale questo avvantaggia tutti: il progetto guadagna funzionalità e il contributore guadagna manutenzione a lungo termine. Ma la realtà è più sfumata, perché il team di NLnet Labs esamina meticolosamente architettura, manutenibilità a lungo termine e stile di codifica. Questa rigorosa revisione riga per riga, usata anche internamente, è una delle ragioni per cui Unbound si è evoluto per quasi 20 anni senza una riscrittura completa. Quando un contributo esterno non si adatta, il team principale può riscrivere la funzionalità da zero, come è accaduto con Serve Stale in Unbound, implementato dietro un compenso concordato, oppure il codice può vivere nella cartella '/contrib', al di fuori della distribuzione ufficiale.

Questa dinamica di contribuzione gestita con cura è stata trasformata negli ultimi 12 mesi dal rilascio di diversi modelli di IA all'avanguardia. Una nuova schiera di sviluppatori ora sente di avere superpoteri alimentati dall'IA. Band descrive l'osservazione di un agente IA a cui viene detto: 'Implementa le Catalog Zones definite nella RFC 9432 in Cascade di NLnet Labs. Fermati solo quando tutti i test passano e tutte le specifiche della RFC sono coperte. Il risultato finale deve includere pagine man, test e piena copertura della RFC.' L'agente può restituire 4.000 righe di codice dall'aspetto plausibile che potrebbe persino funzionare in una certa misura. Ma i manutentori sottolineano che questo sorvola su tutte le scelte di progettazione necessarie per specifiche non descritte nello standard. Per un estraneo una pull request può sembrare 'gratis come la birra' e 'libera come la parola', ma per i manutentori è come ricevere un 'cucciolo gratis', ben intenzionato ma con conseguenze per anni a venire. La questione critica è la responsabilità. I manutentori devono poter discutere con un contributore delle scelte di progettazione, perché si assumono la responsabilità di mantenere quel codice a lungo termine. In quasi tutti i casi, la risposta a qualsiasi domanda sul codice è stata del tipo 'Non lo so, è quello che ha prodotto Claude'. Questo semplicemente non funziona.

Nel frattempo, il lato della ricerca sulla sicurezza è diventato una valanga. Meno di un anno fa, i manutentori si lamentavano di 'AI-slop', segnalazioni di bug senza senso che interrompevano la loro giornata qualche volta al mese. Non potevano essere ignorate perché ognuna di esse poteva essere una vera vulnerabilità con conseguenze catastrofiche. Oggi il problema si è capovolto. Le segnalazioni di bug sono estremamente accurate, piene di passaggi per riprodurre il problema e potenziali correzioni, ma arrivano letteralmente a centinaia alla volta. Il triage richiede molto tempo; i team possono passare un'intera giornata solo per capire quale sia effettivamente il problema segnalato. Le descrizioni restano piuttosto vaghe. Recenti segnalazioni di bug LLM su Routinator includono titoli come 'Round-trip infidelity', 'K-file storm pins validation' e 'Linear-scan burn via block sort position'. Il risultato è che quasi tutti i team di NLnet Labs sono ora al limite nel rilasciare correzioni di bug, in alcuni casi coordinando strettamente con altri fornitori di software. Non ci sono state nuove funzionalità importanti nel loro software dall'inizio dell'anno, e il flusso di segnalazioni tende a esaurirsi solo fino al rilascio di un nuovo modello di IA, quando il ciclo ricomincia. Un grafico nel post mostra il conteggio dei CVE per Unbound negli ultimi anni, dove CVE sta per Common Vulnerabilities and Exposures, gli identificatori univoci assegnati a vulnerabilità di sicurezza divulgate pubblicamente.

Per le persone che svolgono il lavoro, questo è un dilemma frustrante. Band, un manager di NLnet Labs, osserva che gli sviluppatori di software sono motivati a risolvere problemi complicati con soluzioni belle ed eleganti. Per mesi interi, la maggior parte dei team ha solo fatto triage di bug e coordinato rilasci, il che ha tolto il divertimento dal lavoro e reso difficile prevedere la strada da percorrere. NLnet Labs ha quindici dipendenti, dodici dei quali sono sviluppatori di software, e la fondazione non ha i mezzi finanziari per aggiungere personale. Affidarsi agli LLM per il triage delle segnalazioni costerebbe una fortuna, e se quella fosse la soluzione, significherebbe che segnalazioni di bug generate da LLM vengono sottoposte a triage, corrette, unite e rilasciate da LLM, qualcosa che va contro la convinzione dell'organizzazione che gli esseri umani debbano fare la differenza. Il team resta orgoglioso del proprio portafoglio di prodotti, che include resolver DNS e validatori RPKI che supportano una parte enorme del nucleo di Internet, ed è entusiasta delle prospettive del suo nuovo firmatario DNSSEC Cascade. DNSSEC, ovvero Domain Name System Security Extensions, aggiunge firme crittografiche ai record DNS in modo che i resolver possano verificare che le risposte ricevute siano autentiche.

La risposta immediata è una nuova politica sugli LLM: tutti i contributi di codice e documentazione ai progetti NLnet Labs devono essere scritti da un essere umano. Le segnalazioni di vulnerabilità trovate con l'aiuto degli LLM sono ancora accettate. Alcuni potrebbero pensare che questo sia irragionevole, perché uno sviluppatore esperto di C o Rust, ben versato in DNS o BGP, potrebbe usare l'assistenza dell'IA e assumersi comunque la piena responsabilità del proprio codice. Ma questa non è l'esperienza che i manutentori hanno avuto, e la decisione si basa anche su considerazioni etiche e di proprietà intellettuale. La strada da percorrere è incerta. L'organizzazione prevede che le persone che sostengono che sia irresponsabile usare linguaggi di programmazione che non garantiscono la sicurezza della memoria presto affermeranno che è irresponsabile rilasciare software non testato dagli LLM durante lo sviluppo. NLnet Labs afferma che terrà sotto stretta osservazione gli strumenti CI/CD che facilitano i test LLM per il software libero e open source, rimanendo fedele ai propri valori e prendendosi cura della sostenibilità della fondazione. Per gli utenti quotidiani e i proprietari di siti web, questo episodio è un promemoria a mantenere aggiornato il software DNS, mentre l'uso di un resolver DNS crittografato attento alla privacy come AEU DNS può ridurre il tracciamento e le manomissioni a livello DNS lungo il percorso verso un sito web.