Il futuro dell'open source è in pericolo?

Il software Open Source (OSS) è la spina dorsale dell'odierna architettura applicativa. Accelerando il time-to-market e riducendo l'onere per gli sviluppatori spesso oberati di lavoro, l'open source ha consolidato la sua posizione rivoluzionaria all'interno del panorama DevOps. Sebbene profondamente trasformativo per lo sviluppo di applicazioni moderne, il copia e incolla open source continua a rappresentare un grave rischio per la sicurezza sia per le organizzazioni che per gli individui. Combattere questo richiede una lista nera totale di codice open source o l'implementazione proattiva di contromisure come una soluzione WAF di nuova generazione .

Il codice di terze parti è vitale per lo sviluppo di app

Le librerie sono scorte incredibilmente utili di codice sorgente per componenti di applicazioni Web o mobili. Queste librerie possono essere open source, disponibili a tutti gratuitamente, o proprietarie, che bloccano il codice dietro pagamento. Sebbene l'open source rivendichi gran parte della gloria, anche il codice proprietario svolge un ruolo nel funzionamento continuo delle applicazioni aziendali.

Questo software di terze parti, se utilizzato in modo responsabile, impedisce agli sviluppatori di dover continuamente reinventare la ruota. Ciò migliora drasticamente l'efficienza del processo di sviluppo, favorendo al tempo stesso la produzione di un prodotto finale di alta qualità. In definitiva, l'uso gratuito e liberale del codice open source crea un ciclo di feedback positivo, consentendo agli sviluppatori di rilasciare più rapidamente il loro prodotto minimo praticabile, il che apre la strada a una rapida raccolta e implementazione del feedback e della valutazione degli utenti. Sebbene gli sviluppatori siano profondamente consapevoli della posizione critica dell'open source all'interno del processo DevOps, i dirigenti sono spesso sorpresi di apprendere che l'80% del codice che supporta le applicazioni moderne proviene da codice preesistente.

Il pericolo oscuro delle dipendenze transitive

Non è una novità che il codice open source abbia dei rischi. Debolezze recenti e diffuse come Log4j e HeartBleed hanno posto irrevocabilmente il rischio open source sulla mappa. Ciò che rimane un'area di comprensione crescente è la semplice frequenza con cui viene utilizzato l'open source e la furtività con cui le vulnerabilità possono insinuarsi in un progetto attivo. Nonostante il rischio in corso presentato dai progetti open source, sono state condotte pochissime ricerche sul tipo specifico di rischio presentato dall'open source. I ricercatori di Endor Labs hanno deciso di cambiare questa situazione chiarendo l'origine delle principali minacce OSS.

All'interno del software, le dipendenze transitive descrivono una relazione unicamente indiretta tra due componenti. Ad esempio, supponiamo che il tuo team di sviluppo aggiunga il pacchetto B a un progetto in corso. Il pacchetto B, a sua volta, scarica automaticamente il pacchetto C. In questo scenario, mentre il software in via di sviluppo gode di un rapporto diretto con il pacchetto B, il pacchetto C rimane in agguato sullo sfondo – integrale ma in gran parte invisibile. Frustrante qualsiasi tentativo di pratiche di sviluppo più sicure è il fatto che solo il 5% delle dipendenze del software open source viene selezionato manualmente per l'implementazione all'interno del processo DevOps. In questo modo, la maggior parte delle dipendenze viene semplicemente inserita automaticamente nella base di codice. Questo descrive l'origine di una vulnerabilità transitiva. Un recente rapporto di Endor Labs ha rilevato che un sorprendente 95% delle vulnerabilità open source proviene da dipendenze transitive .

I dati sono stati raccolti dal rapporto Census II di Core Infrastructure, che elenca il software open source gratuito più popolare. Questi dati sono stati poi arricchiti con altre fonti che hanno consentito ai ricercatori di Endor di scansionare i gestori di pacchetti più diffusi e le librerie OSS. I ricercatori hanno scoperto che, su 254 pacchetti menzionati nei dati di Census II, la maggior parte soffre di una media di 14 dipendenze transitive. Nel vuoto, 14 potrebbe non sembrare incredibilmente alto, ma la maggior parte delle applicazioni si basa su dozzine, se non centinaia, di dipendenze dirette; le loro controparti transitive scalano in modo esponenziale.

La principale preoccupazione espressa dai ricercatori si basa sulla diffusa sottovalutazione del problema da parte dell'industria. I dirigenti continuano a minare la quantità di codice sorgente in uso all'interno del processo di sviluppo: le dipendenze transitive non sono ancora nemmeno sul radar. La profondità dei problemi di sicurezza continua a nascondersi sotto la superficie, aumentando il raggio d'azione degli attacchi di typosquatting e di esecuzione di codice in modalità remota. Se il costante riutilizzo del codice open source deve essere pienamente all'altezza del suo potenziale, la sicurezza deve diventare una priorità più alta all'interno del processo DevOps.

Come proteggersi dalle vulnerabilità in agguato

Il processo di mantenimento di uno stack tecnologico sicuro non è mai stato così complesso. Con gli avvisi sulle patch che stanno rapidamente diventando travolgenti, è giunto il momento per la sicurezza aziendale di dare priorità alla protezione automatizzata e senza patch. Le misure tradizionali che danno priorità alla sicurezza perimetrale insieme all'analisi statica e dinamica si basano su aggiornamenti manuali, il che significa che non esiste alcuna protezione contro i giorni zero. Il codice backdoor utilizzato dagli aggressori all'interno del famigerato attacco SolarWinds non è stato rilevato da alcuna analisi statica, poiché tecnicamente non si sono verificati errori.

Identificare e bloccare il tentativo di sfruttamento richiede una piccola suite di software di interblocco. Per aiutare innanzitutto a definire e proteggere il perimetro di un'applicazione, è possibile implementare un Web Application Firewall (WAF) di nuova generazione. Seduto al confine tra esterno e interno, il WAF monitora tutto il traffico in entrata e in uscita da un'applicazione. L'aspetto di nuova generazione consente a questo WAF di adattare e implementare automaticamente nuove policy. L'implementazione automatizzata di questa costante evoluzione libera tempo ed energia significativi per il team di sicurezza che un WAF della vecchia scuola altrimenti consumerebbe.

Mentre WAF tiene sotto controllo qualsiasi tentativo esterno di eseguire codice, Runtime Application Self Protection (RASP) protegge da punti deboli interni e code injection. Questo livello di protezione valuta tutti i payload (come query SQL e comandi del sistema operativo) in tempo reale. Questo processo non richiede firme o una fase di apprendimento e si svolge interamente all'interno del contesto dell'applicazione. Poiché opera all'interno dell'applicazione, copre quasi tutti i contesti. Ciò significa che, anche se un exploit consente di violare il perimetro, a un utente malintenzionato viene impedito di spostarsi lateralmente, poiché qualsiasi comportamento sospetto dell'applicazione attiva l'arresto di RASP. Ciò interrompe l'attività sospetta e allerta i team di sicurezza. In questo modo, RASP è complementare a un WAF di nuova generazione; mentre il WAF aiuta a tenere fuori il traffico dannoso, il rischio rappresentato da exploit transitivi in ​​agguato è mitigato da RASP. Con questi componenti che proteggono uno stack tecnologico, l'onere che attualmente l'OSS pone sulla sicurezza è notevolmente alleggerito.