Negli ultimi anni, le aziende sono state aumentando il loro uso di codice open source per aiutare a costruire applicazioni più potenti più veloce.
componenti open source ridurre i tempi di sviluppo delle applicazioni, fornendo potenti funzionalità che gli sviluppatori non devono scrivere da soli, accelerando la distribuzione di nuove versioni. Formare la spina dorsale del software di oggi, componenti open source comprendono ora tra 60-80% di applicazioni moderne.
Aprire librerie e strumenti di origine – una responsabilità per la sicurezza
I team di sviluppo possono facilmente sfruttare le varie librerie open source e strumenti, che vengono aggiornate e fornito dalla comunità open source, prendendoli dalle risorse popolari come GitHub.
Insieme con gli evidenti vantaggi per gli sviluppatori, utilizzando componenti open source non è senza rischi. Mantenere il proprio prodotto software sicuro può essere una sfida e richiedono gli strumenti giusti per affrontare le minacce. Nel caso di componenti open source, al contrario di codice proprietario che è scritto in-house da una società, il rischio principale per prodotti utilizzando software open source sono noti vulnerabilità. Queste sono le vulnerabilità che sono stati pubblicati on-line e sono disponibili per chiunque di visualizzare ed eventualmente utilizzare per sfruttare le vittime. La questione della utilizzando componenti con vulnerabilità note è probabilmente già sul radar, dopo aver tenuto un posto in primo piano infame di OWASP 10 da 2013.
Come software di terze parti, i componenti open source possono essere utilizzati in migliaia di prodotti, e una vulnerabilità trovata in un singolo componente può avere un impatto su una vasta gamma di applicazioni. Perché i componenti open source sono gestiti dalla comunità open source, dipendiamo da loro per avvertirci di nuove vulnerabilità quando questi ricercatori di sicurezza a trovare.
Nel cercare di tenere gli altri sicuro, questi ricercatori potranno inviare le loro conclusioni su quali componenti open source sono vulnerabili e come eseguire le gesta di avvisi di sicurezza e database come l'U.S.. sostenuta dal governo National Vulnerability Database (NVD). Anche se questo può essere utile per i team di sicurezza vigili che possono utilizzare queste informazioni per correggere rapidamente le loro applicazioni, gli hacker stanno anche guardando qui per libera intelligenza su cosa e come bersaglio.
La sfida è a stare un passo avanti degli attaccanti. Sfortunatamente, la stragrande maggioranza dei team di sviluppo sono semplicemente a conoscenza di quanto i loro prodotti si basano su componenti open source, e non tenere un inventario corretto di quelli che essi hanno nei loro prodotti. Questo può essere un problema significativo poiché possono essere presi di mira attraverso un componente vulnerabile che non sapevano nemmeno di utilizzare.
Questo è ciò che è accaduto nel caso Equifax lo scorso settembre, quando la società è stata violata attraverso una versione vulnerabile di Apache Struts 2 (CVE-2017-5638), che porta al furto di 145.9 milione di record dati personali, compresa la sicurezza sociale e numeri di carte di credito. Secondo i rapporti, l'attacco è avvenuto due mesi dopo la vulnerabilità è stata divulgata, imbarazzante l'azienda di non aver preso le misure necessarie per mantenere i loro dati sicuro.
Automazione è fondamentale per fissare componenti open source
In parte a causa del rapido ritmo di sviluppo, e forte dipendenza componenti open source per rimanere nei tempi previsti, monitoraggio manuale dei componenti open source non è semplicemente un'opzione per le organizzazioni che vogliono rimanere sicuro.
La scalabilità è la chiave, e solo soluzioni automatizzate offrono una risposta su come rimanere in cima a tutti i componenti open source che entra nell'ambiente di sviluppo. Solo software di composizione analisi (SCA) strumenti sono in grado di identificare i componenti open source e avvisando i team di sicurezza a rischi.
Al fine di implementare correttamente un processo di sicurezza open source, soprattutto in un modello DevOps, squadre di sicurezza e di sviluppo devono lavorare insieme per la cattura di problemi all'inizio, adotta un approccio spostamento a sinistra. Quando si integrano uno strumento di SCA in loro server CI / CD, gli strumenti in grado di identificare i componenti vulnerabili prima di fare nella build, impedendo operazioni più costose più tardi quando gli sviluppatori avrebbero dovuto strappare e sostituire il componente vulnerabile prima del rilascio.
Contemporaneamente, è essenziale per spostare a destra con gli avvisi quando vengono scoperte nuove vulnerabilità, dando team di sicurezza l'avvertimento di cui hanno bisogno di patch rapidamente i loro prodotti prima che i pirati informatici tentano di fare il loro violazione.
Implementando un continuo, strumento automatizzato SCA, le organizzazioni possono applicare policy in tutto il loro sviluppo e prodotti, mitigare in modo significativo i rischi per la vulnerabilità note nella loro componente open source utilizzo.
Circa l'autore: Zev Brodsky
Di giorno, Zev è il Community Manager alle open source leader di gestione della sicurezza WhiteSource. Di notte, lui è un appassionato di taco, così così il giocatore pedine, e collettore di Stamp rare.
