Buongiorno, On 2026-05-14, Giacomo Tesio via nexa wrote:
[...] > # Bottom Lines > > Understanding the true risk of AI in cybersecurity means separating the > sci-fi hype from the reality of how these models actually work. The [...] > Continua con una breve ma interessante analisi storica del codice di > FreeBSD qui: > https://rival.security/posts/mythos-discovered-a-cve-already-in-its-training-data---and-thats-still-worrying siccome sono cose molto tecniche e sconosciute ai più, faccio sommessamente notare alcune questioni facili facili da non ignorare: 1. fuori di dubbio che l'analisi svolta attraverso quel LLM abbia scovato un pezzo di codice che provoca il duecentomiliardesimo buffer overflow della storia del software scritto in C 2. fuori di dubbio che di tecniche per scovare automaticamente potenziali buffer overflow [1] o "addirittura" per evitare _alla radice_ i buffer overflow [2] ne esistano e siano conosciute ai bravi programmatori da decenni 3. fuori di dubbio - e questo è il punto fondamentale - che questa analisi, sia che sia svolta con LLM che da _esseri umani_ con altri strumenti, richiede: 3.1 che siano dedicate adeguate risorse al compito _e_ che tra le risorse dedicate vi siano persone competenti in materia, anche se usano LLM (se non altro per non sparare "prompt" a caso) 3.2 che il software sia: 3.2.a disponibile in formato sorgente 3.2.b disponibile con una licenza che NON impedisca di pubblicare i risultati ottenuti Fatelo con MS Windows o MAC OSX, se ne avete le risorse. In ogni caso: ci stanno forse suggerendo che le aziende che producono software dovrebbero usare "a tappeto" strumenti come quel LLM per aumetare i loro profitti risparmiando sui bravi _analisti_ programmatori in grado di scrivere codice "safe by design" o di farne analisi per il debugging? Auguroni!!! ...e poi, volete _davvero_ fare a gara a chi c'è l'ha più lunga, la lista dei CVS?!? :-D [...] Saluti, 380° [1] https://en.wikipedia.org/wiki/Static_program_analysis https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis [2] l'argomento è "ostico", solo per segnalare un esempio: https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-buffer-overflow-vulnerabilities ma la discussione tecnica NON deve diventare una guerra "Rust contro C" anche perché ci sono _per forza_ alcune operazioni che devono essere svolte in modalità "memory unsafe", anche in linguaggi "memory safe" come Rust. Certo è che per moltissime applicazioni (per ora non per il kernel, non si può) sarebbe meglio evitare linguaggi memory unsafe. -- 380° (lost in /traslation/) «Welcome to the chaos of the times If you go left and I go right Pray we make it out alive This is Karmageddon»
signature.asc
Description: PGP signature
