CauSec: Unboxing the Causal Drivers of Static Vulnerability Analysis Performance
Questo articolo introduce CAUSEC, un framework di analisi causale che formalizza e valida le assunzioni sottostanti degli strumenti di Static Application Security Testing (SAST) per determinare se i loro compromessi progettuali producano effettivamente i guadagni di prestazioni previsti, dimostrandone l'utilità attraverso uno studio sistematico di 57 assunzioni di uso improprio di API crittografiche attraverso quattro strumenti popolari.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Nel mondo digitale, gli strumenti software agiscono come i guardiani della sicurezza, scansionando il codice per trovare falle nascoste prima che possano essere sfruttate. Questi strumenti, noti come tester di sicurezza delle applicazioni statiche (static application security testers), sono utilizzati ovunque, dalle piccole startup alle grandi multinazionali. Essi funzionano formulando supposizioni istruite su come si comporta il codice, spesso scegliendo di ignorare determinate parti di un programma per eseguire più velocemente o per evitare di segnalare come pericoloso del codice innocuo. Il settore è da tempo basato su un insieme di convinzioni non provate: che saltare tipi specifici di codice renderà lo strumento più accurato, o che ignorare certe librerie ridurrà i falsi allarmi. Queste convinzioni guidano la costruzione degli strumenti, ma finora nessuno aveva testato sistematicamente se tali assunzioni fossero effettivamente vere o se fossero solo storie convenienti che i progettisti raccontavano a se stessi.
Un team di ricercatori della William & Mary ha deciso di mettere alla prova queste convinzioni. Hanno costruito un nuovo framework chiamato CAUSEC, che tratta le assunzioni dietro gli strumenti di sicurezza non come fatti, ma come ipotesi che possono essere provate o smentite. Invece di limitarsi a guardare se uno strumento trova bug, si sono chiesti perché li trova e cosa succede quando si cambiano le regole. Applicando un metodo chiamato inferenza causale, che aiuta a separare le vere relazioni di causa-effetto dalle semplici coincidenze, sono stati in grado di isolare specifiche scelte di progettazione e misurarne il reale impatto. Il loro lavoro rivela che le regole seguite dagli strumenti di sicurezza sono spesso più fragili e specifiche di quanto si fosse realizzato.
I ricercatori hanno iniziato esaminando la storia degli strumenti progettati per intercettare errori nel modo in cui il software utilizza la crittografia, la matematica che protegge i dati. Hanno setacciato vent'anni di articoli di ricerca e trovato cinquantasette assunzioni distinte fatte dai progettisti degli strumenti. Queste assunzioni spaziavano dall'idea che concentrarsi su regole di codice specifiche migliori l'accuratezza, alla convinzione che ignorare le librerie di terze parti renda lo strumento più veloce e preciso. Il team si è reso conto che molte di queste affermazie erano basate su correlazioni — cose che accadevano insieme — piuttosto che su cause provate. Ad esempio, uno strumento potrebbe saltare le librerie di terze parti e per caso avere meno falsi allarmi, ma ciò non significa che l'aver saltato le librerie sia la vera ragione del miglioramento. Potrebbero esserci altri fattori nascosti in gioco.
Per dirimere la questione, il team si è concentrato su un'assunzione molto comune: che la segnalazione di avvisi di sicurezza provenienti da librerie di terze parti diminuisca la precisione dello strumento, ovvero che crei più falsi allarmi. Hanno raccolto un enorme dataset di oltre 57.000 avvisi generati da quattro popolari strumenti di sicurezza: Semgrep, CodeQL, CogniCrypt e CryptoGuard. Successivamente, hanno controllato manualmente ogni singolo avviso per vedere se fosse un problema reale o un falso allarme, creando una "verità fondamentale" (ground truth) rispetto alla quale gli strumenti potessero essere misurati. Utilizzando il loro nuovo framework, hanno simulato cosa sarebbe successo se avessero costretto ciascuno strumento a segnalare avvisi da librerie di terze parti, tenendo conto con cura di altre variabili come la dimensione dell'applicazione o la sua popolarità.
I risultati sono stati sorprendenti e hanno mostrato che l'assunzione non era una verità universale. Per due degli strumenti, l'assunzione reggeva: quando hanno iniziato a segnalare avvisi da librerie di terze parti, il tasso di falsi allarmi è effettivamente aumentato. Tuttavia, per gli altri due strumenti, è accaduto l'esatto contrario. Quando questi strumenti includevano avvisi da librerie di terze parti, la loro accuratezza è effettivamente migliorata. Questa scoperta ha dimostrato che la progettazione dello strumento stesso agisce come un modificatore; la stessa regola può avere effetti completamente diversi a seconda dello strumento. I ricercatori hanno scoperto che l'impatto dell'inclusione di codice di terze parti variava enormemente a seconda del tipo specifico di libreria e dello strumento utilizzato. Per uno strumento, le librerie di utilità causavano un calo significativo dell'accuratezza, mentre per un altro, quelle stesse librerie miglioravano l'accuratezza.
Lo studio ha anche evidenziato come molte delle assunzioni fatte dai progettatori degli strumenti fossero basate su compromessi non verificati. I progettisti spesso sacrificano la capacità di trovare ogni possibile bug in cambio di velocità o di meno falsi allarmi, credendo che questo compromesso sia necessario. I ricercatori hanno scoperto che, sebbene questi compromessi siano reali, i risultati specifici sono spesso imprevedibili. Hanno scoperto che il modo in cui uno strumento viene costruito — le sue regole specifiche, come filtra i dati e come gestisce il contesto — determina se una scelta di progettazione aiuti o danneggi. Ciò significa che un team di sicurezza non può semplicemente copiare le scelte di progettazione di uno strumento di successo e aspettarsi gli stessi risultati. Ciò che funziona per uno strumento non è garantito per un altro.
In definitiva, l'articolo sostiene che la comunità della sicurezza debba allontanarsi dall'accettare le assunzioni come fatti. I ricercatori hanno dimostrato che, utilizzando l'analisi causale, è possibile testare rigorosamente queste assunzioni e capire esattamente come influenzino le prestazioni. Hanno scoperto che, sebbene alcune assunzioni siano valide, molte non lo sono, e la loro validità dipende interamente dal contesto specifico dello strumento utilizzato. Lo studio conclude che i progettatori di strumenti non dovrebbero ereditare assunzioni dal lavoro precedente senza testarle nel proprio ambiente specifico. Invezione, dovrebbero trattare ogni scelta di progettazione come un'ipotesi da testare, assicurando che gli strumenti che costruiscono siano basati sull'evidenza piuttosto che sull'intuizione. Questo approccio offre una via più chiara per costruire strumenti di sicurezza che non siano solo veloci, ma veramente efficaci nel proteggere il software.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.