Quest'anno il sondaggio annuale tra i professionisti del DevSecOps di GitLab ha rilevato numerosi problemi nella cultura organizzativa che potrebbero impedire un allineamento più profondo tra i team tecnici e della sicurezza. La maggioranza delle persone intervistate (58%) dichiara che è difficile far sì che i team di sviluppo diano priorità alla correzione delle vulnerabilità; il 52% riferisce che le procedure spesso ne impediscono la risoluzione rapida. Inoltre, gli specialisti di sicurezza intervistati riportano vari problemi specifici legati al proprio lavoro, tra cui difficoltà a comprendere i risultati delle analisi di sicurezza, un numero eccessivo di falsi positivi e lo svolgimento di test in una fase troppo tarda dello sviluppo software.
Il DevSecOps promette di offrire un'integrazione migliore tra il lavoro dei tecnici e quello dei team di sicurezza, ma è chiaro che persistono frustrazioni e un certo disallineamento. Queste difficoltà sono sintomi di un problema più ampio, legato all'idea che l'organizzazione ha della sicurezza, alla collaborazione tra team e al tempo dedicato alle attività di sicurezza.
Sfuggire al circolo vizioso della vulnerabilità
Le analisi mettono in evidenza tutte le potenziali vulnerabilità, ma il fatto che un pacchetto software presenti una vulnerabilità o un'esposizione comune non significa che sia raggiungibile o sfruttabile. Molti team della sicurezza e sviluppatori potrebbero essere occupati a categorizzare e filtrare i risultati delle vulnerabilità, cresciuti esponenzialmente negli anni da quando si è diffusa la scansione autenticata delle vulnerabilità.
Il passaggio alla scansione autenticata ha migliorato l'efficacia dei programmi di sicurezza sotto vari aspetti, ma ha anche inserito gli sviluppatori in un ciclo infinito di correzione di elementi poco rilevanti. Se i team usano il proprio tempo per lavorare su patch che non riguardano una vulnerabilità sfruttabile, non riescono a occuparsi di attività più critiche, come la correzione di falle vulnerabili e sfruttabili. Questa attualmente è la fonte di gran parte delle tensioni tra team di sicurezza e tecnici.
Come è possibile affrontare la causa principale di questi problemi e promuovere una migliore integrazione tra tecnici ed esperti di sicurezza? Ecco tre modi per eliminare alla fonte le frustrazioni più comuni dei team di sicurezza.
1. Silenzia il rumore, concentrati su segnali utili ad alta fedeltà
Secondo gli esperti di sicurezza intervistati durante il nostro sondaggio, l'eccesso di falsi positivi è il secondo problema più pressante. La sfida è evidente, ma spesso è solo un problema di gestione delle vulnerabilità sotto mentite spoglie.
La presenza di molti falsi positivi potrebbe indicare che non si è fatto tutto il possibile per garantire l'alta fedeltà dei risultati di sicurezza. I team di sicurezza devono quindi restringere il campo a ciò che conta di più. Ciò significa che le tradizionali soluzioni di test statico della sicurezza delle applicazioni (SAST) sono probabilmente insufficienti. Il SAST è uno strumento potente, ma perde gran parte del suo valore se i risultati sono ingestibili o mancano di un contesto appropriato. Affinché il SAST sia più efficace, deve integrarsi fluidamente con altri strumenti di sicurezza e sviluppo ed essere accessibile agli sviluppatori.
Un altro problema è che gran parte degli strumenti di analisi ha una finestra di contesto molto ristretta per comprendere i risultati delle vulnerabilità. Questo è uno dei campi in cui possono venire in aiuto le funzionalità basate sull'IA in grado di spiegare le vulnerabilità della sicurezza.
2. Ridurre al minimo lo stack tecnologico e la superficie di attacco
Concentrarsi su ciò che conta non è importante solo per i test di sicurezza, ma anche per lo sviluppo software in primo luogo.
Nonostante l'IA prometta di semplificare lo sviluppo software, la nostra indagine indica che molte aziende hanno ancora molta strada da fare. Rispetto agli intervistati che non usano l'IA, chi la usa è nettamente più propenso a consolidare la propria toolchain; questo dato indica che la proliferazione di diverse point solution che eseguono modelli di IA diversi potrebbe aggiungere complessità, non eliminarla.
La complessità crescente degli stack tecnologici aziendali è una delle principali difficoltà per i team di sicurezza. Un certo grado di complessità è inevitabile durante lo sviluppo di sistemi software estesi e sfaccettati, ma le organizzazioni devono cercare di evitare le complessità derivanti da decisioni di progettazione non ottimali, come codice difficile da aggiornare e dipendenze ridondanti. Questa complessità evitabile crea una superficie di attacco più ampia e genera più risultati delle analisi di sicurezza, che i team devono ordinare, a cui devono assegnare priorità e che devono affrontare.
Bisogna quindi affrontare lo sviluppo attraverso la lente della minimizzazione del software, ovvero adottare intenzionalmente alcuni strumenti e integrare intenzionalmente determinati elementi nelle codebase. In questo modo le dipendenze sono ridotte al minimo, la sicurezza della catena di fornitura del software è migliorata, i falsi allarmi generati dallo scanner di vulnerabilità sono ridotti e, nel complesso, gli sviluppatori hanno meno problemi non critici da correggere.
3. Normalizzare l'approccio orientato a una strada già battuta
Tra i problemi principali individuati dagli intervistati c'è anche lo svolgimento di test di sicurezza troppo tardi nel ciclo di sviluppo software. Alcuni dipendenti possono sentirsi frustrati quando vogliono distribuire un elemento ma non possono farlo perché una vulnerabilità viene rilevata in ritardo (e spesso era impossibile rilevarla prima). Ciò che è possibile, però, è usare componenti di sicurezza riutilizzabili e di cui è facile eseguire il deployment, limitando le variabili e le potenziali vulnerabilità.
Per evitare sorprese in fase avanzata di sviluppo si possono adottare pattern di progettazione collaudati e sicuri basati su casi d'uso ripetibili: è il cosiddetto approccio orientato a una strada già battuta. Una "strada battuta" ("paved way") è un percorso consigliato che include un set definito di strumenti, processi e componenti, utilizzabile dai team per creare applicazioni sicure in modo più efficiente, ad esempio usando GitOps per la versione ed eseguendo il deployment di una Infrastructure as Code ben progettata e testata che si distribuisce su larga scala per tutti i carichi di lavoro.
Adottare questo tipo di approccio può ridurre in parte la flessibilità, ma nel complesso limita il carico operativo e la rilavorazione necessaria per i team tecnici, migliorando la sicurezza. Per applicarlo, serve la collaborazione tra team di sicurezza e di sviluppo: i primi possono aiutare a definirlo, ma occorre coinvolgere i tecnici per gestirlo e aggiornarlo come parte della codebase.
La sicurezza è un dominio, non un team
La sicurezza si sta già integrando nel lavoro dei team tecnici, e possiamo aspettarci che i confini tra i due continueranno a confondersi. Ma con la rapida adozione dell'IA e la corrispondente accelerazione dello sviluppo software (il 66% degli intervistati dichiara di effettuare release due volte più velocemente, o comunque più velocemente, rispetto allo scorso anno), la sicurezza sarà fondamentale per creare sistemi e framework ottimizzati affinché diano il massimo vantaggio in termini di sicurezza. Per questo motivo, la disconnessione tra sviluppo e sicurezza è solo una sfaccettatura del problema. È essenziale promuovere una cultura della collaborazione, ma i team di sicurezza e tecnici devono anche collaborare per ripensare gli aspetti fondamentali dello sviluppo software, come l'ottimizzazione delle codebase esistenti e la creazione di soluzioni scalabili incentrate sugli aspetti tecnici, che possano essere adottate senza problemi dai team tecnici in tutta l'organizzazione.
La sicurezza delle applicazioni nell'era digitale
Leggi i risultati del sondaggio condotto tra oltre 5.000 professionisti di DevSecOps in tutto il mondo per scoprire come le organizzazioni affrontano l'aumento delle superfici di attacco e come sta cambiando l'atteggiamento nei confronti della sicurezza e dell'IA.