Le organizzazioni hanno bisogno di sviluppare applicazioni in modo rapido e agile. La sicurezza è essenziale, ma le lunghe revisioni manuali della sicurezza rappresentano un collo di bottiglia inaccettabile. Soluzioni per i test di sicurezza applicativa come quellli forniti dalle soluzioni Fortify di OpebText Cybersecurity affrontano questo problema automatizzando il processo di revisione della sicurezza.
Una volta automatizzato il test di sicurezza, emerge però un secondo collo di bottiglia: gli esseri umani devono ancora revisionare e agire sui risultati dei test. Il codice sorgente deve essere modificato per risolvere i problemi di sicurezza. Idealmente, anche questo compito dovrebbe essere automatizzato e questa idea viene chiamata auto-remediation ed è attualmente un tema caldo nell’industria della sicurezza applicativa.
Fortify Security Assistant per IntelliJ è il plugin di OpenText Cybersecurity capace di eseguire un’auto-remediation altamente affidabile per 13 categorie di vulnerabilità significative ed è disponibile per tutti i clienti Fortify SAST.
Il caso specifico dell’SQL injection: una vulnerabilità risolvibile
L’SQL injection è probabilmente la categoria di vulnerabilità più famosa della sicurezza applicativa; i difetti di SQL injection sono tipicamente causati dalla creazione di una dichiarazione SQL concatenando parti fisse e input utente. Il modo migliore per prevenire l’SQL injection è sostituire la concatenazione con una “dichiarazione preparata”. L’input dell’utente verrà quindi gestito come parametro, rendendo impossibile l’SQL injection.
Questo caso di auto-remediation viene spesso citato dai fornitori di soluzioni di sicurezza perché tutti concordano sulla strategia di remediation da adottare, che effettivamente funziona quasi sempre. Tra le soluzioni Fortify è il tool Fortify Security Assistant quello in grado di effettuare questa riscrittura, auto-risolvendo le vulnerabilità di SQL injection.
Tuttavia, non sarebbe corretto affermare che questo esempio possa essere utilizzato come caso rappresentativo di tutte le vulnerabilità in generale.
Certamente ci sono alcune categorie che assomigliano all’SQL injection negli aspetti sopra menzionati come, l’XML Entity Expansion causato da un parser XML configurato in modo non sicuro deve essere risolto impostando le caratteristiche del parser am non tutti le categorie riescpono col buco.
Le categorie di vulnerabilità problematiche per l’auto-remediation
Molte categorie di vulnerabilità, infatti, non possono essere affrontate con questo approccio.
Senza entrare in discussioni tecniche, per esempio il meccanismo sopra citato si dimostra inefficace nei casi di Cross-Site Scripting (XSS), di crittografia debole effettuata con algoritmi vetusti e di Hardcoded Secrets ovvero quando informazinoi segrete (chiavi, password) vengono memorizzate nel codice sorgente.
Più in generale, qualsiasi situazione problematica che richieda per essere risolta di una validazione degli input risulta problematica, sia perché esistono molte diverse architetture per implementare la validazione sia perché la corretta allow-list non sarà conosciuta dallo strumento.
In realtà, anche l’SQL injection può essere problematico perché, se è vero che la maggior parte degli sviluppatori conosce le dichiarazioni preparate, ci sono anche alcuni limiti: per esempio, il nome di una tabella SQL non può essere un parametro di una dichiarazione preparata.
Ridurre l’arretrato di sicurezza combinando audit e remediatino
L’auto-remediation è una tecnologia importante che aiuta i professionisti ad agire rapidamente sui risultati dei test di sicurezza applicativa. Tuttavia la sua portata o la percentuale di casi in cui funzionerà veramente è intrinsecamente limitata. Pertanto, non è una soluzione miracolosa per eliminare il collo di bottiglia umano e ridurre gli inevitabili arretrati che il responsabile della sicurezza si trova ad affrontare.
Come dovrebbe essere allora uno strumento ideale per ridurre l’arretrato di sicurezza? Definiamo alcuni principi chiave.
Il primo è di combinare audit e remediation. Gli strumenti di sicurezza applicativa producono sempre una certa quantità di rumore ovvero “falsi positivi”. Questi risultati non richiedono una remediation associata, quindi non dovremmo mai risolvere automaticamente tutti i risultati prodotti da uno strumento di sicurezza applicativa. Prima di tutto, è necessario eseguire un audit per determinare se i risultati sono corretti. Se acceleriamo la remediation ma manteniamo invariato l’audit, avremo ancora un grande collo di bottiglia nel nostro processo, quindi dovremo accelerare anche questo.
Va notato che le attività di audit e remediation si sovrappongono notevolmente: per entrambe, è necessario ottenere una comprensione approfondita di cosa sta accadendo nell’applicazione al di là dei dati e delle descrizioni standard prodotte dallo strumento di sicurezza applicativa. Se abbiamo svolto questo lavoro per l’audit, dovrebbe essere integrato nel processo di remediation per evitare lavoro doppio.
Quindi, per molte ragioni, ha senso considerare audit e remediation contemporaneamente.
L’automazione completa funziona solo in pochi casi e, nella maggior parte delle volte, abbiamo ancora bisogno dello sviluppatore.
Facilitare il lavoro dello sviluppatore
Ciò significa l’obiettivo da perseguire dovrebbe essere di rendere il lavoro dello sviluppatore il più semplice possibile. Infatti, è vero che gli strumenti di sicurezza applicativa avanzati forniscono molte informazioni utili, tra cui descrizioni delle vulnerabilità e diagrammi di flusso, tutti collegati al codice sorgente, combinati con consigli di remediation (generici); ma comprendere tutto ciò e trarre le giuste conclusioni richiede molto lavoro, anche per un esperto.
Utilizzando l’AI generativa, possiamo rendere questo compito molto più semplice. L’AI generativa può considerare le evidenze raccolte da uno strumento di sicurezza applicativa, insieme al codice sorgente effettivo e quindi annotare i risultati dello strumento con la propria analisi. Agendo come compagno dello sviluppatore, rende i risultati dello strumento molto più facili da comprendere.
Se c’è una soluzione ovvia per risolvere il problema, l’AI può aggiungerla al risultato. Ma se stiamo affrontando uno di quei casi in cui non è ovvio, l’AI può comunque fornire suggerimenti su come eseguire la remediation che è qualcosa di difficile da immaginare quando si fa auto-remediation direttamente sul codice sorgente.
Anche nei casi in cui l’auto-remediation è un’opzione, mantenere lo sviluppatore coinvolto è una buona cosa. La partecipazione attiva e la responsabilità del cambiamento miglioreranno le loro competenze e renderanno meno probabile che questo problema si ripresenti.
Il valore aggiunto di Fortify Aviator
Fortify Aviator è un nuovo strumento per l’audit e la remediation che segue i principi appena descritti.
Basato su un avanzato Large Language Model (LLM), Fortify Aviator è in grado di ragionare sui risultati prodotti da Fortify SAST.
Innanzitutto, esegue un audit determinando se il problema deve essere risolto o meno (sopprimendo i risultati non rilevanti). Aggiunge inoltre un commento al problema motivando la sua decisione e se il problema deve essere risolto, il consiglio di remediation è incluso nel commento.
Le informazioni aggiunte da Fortify Aviator aumentano la produttività dello sviluppatore e, poiché sono aggiunte direttamente al problema, sono disponibili ovunque: l’interfaccia web di Fortify, gli IDE, Audit Workbench, i ticket generati per i tracker dei problemi, i report generati e così via. Qualsiasi flusso di lavoro dello sviluppatore è supportato.
L’auto-remediation andrebbe, quindi, considerata utile per alcuni casi e supportata ma è solo tramite un approccio combinato come quello offerta da Fortify Aviator che un responsabile della sicurezza potrà riuscire davvero a ridurre il lavoro arretrato.