C'è codice open source all'interno di quasi tutti i progetti di sviluppo software a cui puoi pensare. Gli sviluppatori lo adorano. Ma devi comprendere i rischi nascosti e come ridurli al minimo, oppure potresti lasciare la tua applicazione aperta a vulnerabilità di sicurezza sconosciute.
Codifica prima dell'open source
h2>
C'era una volta che gli sviluppatori di software scrivevano tutto da zero. Poi hanno iniziato a comparire librerie di codici, toolkit e altri componenti aggiuntivi. Potresti ottenere un vantaggio utilizzando un toolkit per fornire alcune funzionalità, come un modulo di reporting o un widget di interfaccia. Potresti inserirli nel tuo progetto come componenti già pronti e utilizzarli immediatamente. L'alternativa era sprecare tempo, denaro e sforzi di sviluppo reinventando la ruota.
Naturalmente, nel tempo avresti creato la tua libreria di routine e moduli che erano stati scritti internamente. Quindi, quando stavi sviluppando una nuova routine di codice o un elemento di interfaccia, avevi tre opzioni. Scrivilo tu stesso, riutilizza del codice interno precedentemente scritto o acquistalo in una libreria o in un toolkit.
L'ascesa dell'open source
L'avvento del codice open source ha cambiato tutto questo. Il software open source rende il codice sorgente di un progetto liberamente disponibile per l'uso da parte di altri, entro i limiti di una licenza solitamente benigna. La crescita e l'adozione dell'open source sono state sbalorditive. La parola proliferazione non sembra coprirlo. C'è stato un fenomenale aumento del software open source, e non solo in termini di numero sbalorditivo di progetti e prodotti open source esistenti, ma anche nell'uso dell'open source all'interno dei prodotti commerciali.
< p>Il software open source ha raggiunto la massa critica alcuni anni fa ed è passato da una posizione di nicchia ai margini a una risorsa di sviluppo mainstream pienamente accettata. Poiché è stato guidato e sviluppato da una comunità e non da un'impresa commerciale tradizionale, è stato considerato anche una specie di dilettante.
Pubblicità
Ora sembra che l'open source sia cresciuto e maturato. E ce l'ha. Ma il cambiamento più grande è stato un più ampio apprezzamento dell'open source, una comprensione dei vantaggi che porta e il riconoscimento che includere l'open source nel tuo prodotto non è nulla di cui vergognarsi.
Le stime suggeriscono che i progetti software non banali scrivono al massimo circa il 20% del codice originale. L'altro 80% è open source. Il principale sito di hosting di repository open source, GitHub, ha raggiunto oltre 100 milioni di repository nel 2018. E ci sono molte altre piattaforme Git ospitate, come GitLab e BitBucket.
L'open source è un fenomeno di sviluppo software. Ma non è tutto rose e fiori nel giardino di sviluppo. Ci sono problemi di cui devi essere consapevole e gestire.
I problemi di sicurezza
L'utilizzo di componenti open source in grandi progetti software riduce i costi di sviluppo, accorcia i tempi di sviluppo end-to-end e, si è affermato, promuove l'innovazione. Poiché libera il tuo personale di sviluppo dal banale, consente loro di concentrarsi sugli aspetti unici e attraenti per il mercato del tuo prodotto.
Ci sono alcuni prodotti open source che hanno un'entità commerciale dietro di loro. L'organizzazione rilascia il proprio prodotto in base a uno schema di doppia licenza. Una versione commerciale avrà un canale di supporto ufficiale, professionale e potrebbe contenere altri vantaggi come extra proprietari in bundle con il prodotto. Rilasciano anche una versione supportata dalla comunità che beneficerà degli sforzi di codifica del team commerciale e dei contributi della propria comunità. Contributi significativi della community torneranno anche nella versione commerciale.
Tuttavia, la maggior parte dei progetti open source è completamente guidata dalla comunità. Possono avere il sostegno di entità commerciali, ma tale sostegno sono donazioni e sponsorizzazioni, non contributi di codice.
Pubblicità
Indipendentemente dalla loro provenienza, i componenti open source scelti per essere inclusi in nuovi progetti di sviluppo tendono ad essere progetti ben consolidati e rispettabili a pieno titolo. Hanno guadagnato un alto grado di fiducia. Ma non è sempre così. A volte la funzionalità di cui hai bisogno è disponibile, ma è contenuta in un progetto nuovo e in qualche modo non provato. Ma tu hai il codice sorgente, giusto? Puoi fare una revisione del codice.
Dal punto di vista della sicurezza, l'open source non è né più né meno sicuro del codice proprietario sviluppato in casa. Dopotutto, è tutto codice scritto dall'uomo. I sostenitori dell'open source puntano alla legge di Eric S. Raymond che ha chiamato in onore di Linus Torvalds, che afferma che “con abbastanza occhi, tutti i bug sono superficiali”. Con un numero sufficiente di persone che esaminano il codice e lo sottopongono a beta test, i problemi dovrebbero essere identificati, caratterizzati e risolti rapidamente.
Questo è vero fino a quel momento. Ma i problemi di sicurezza non sono necessariamente bug. Una vulnerabilità può essere una circostanza che si presenta come un effetto collaterale di una logica complessa in un progetto di molti moduli di codice sorgente pari a milioni di righe di codice. Il prodotto fa quello che dovrebbe, quindi sembra funzionare come previsto. E così supera la revisione del codice, la verifica del prodotto, i test sul campo e ottiene un buono stato di salute.
Al di fuori della cieca fortuna e del caso, quel ciclo di revisione, test, prova e rilascio non porterà alla luce le vulnerabilità della sicurezza.
Perché l'open source è attraente per gli hacker
Inoltre, ci sono aspetti dell'open source che sono positivamente attraenti per gli hacker e gli attori delle minacce. Possono vedere anche il codice sorgente. Possono cercare le vulnerabilità con una mentalità diversa rispetto al contributore medio della comunità che, sebbene possa essere uno sviluppatore competente, è improbabile che abbia un reale background di sicurezza.
Naturalmente, i contributori all'open source venire in tutti i gusti con sfondi diversi. Alcuni di loro avranno senza dubbio un'esperienza di sicurezza nel mondo reale, ma saranno la minoranza. Gli attori delle minacce sono un'altra bestia. E non si limitano a trovare vulnerabilità, possono anche iniettarle.
Pubblicità
Ci sono stati molti casi in cui un attore di minacce ha introdotto una vulnerabilità tramite una patch creata e inviata a un progetto. Si è fatto strada attraverso la revisione del codice, nel code-base e nella prossima versione del prodotto.
Forse l'esempio più recente è stato un componente JavaScript chiamato event-stream. Questo progetto open source è stato gestito da un singolo sviluppatore. L'onere della gestione del progetto lo superò. È stato convinto a consegnarlo a un nuovo manutentore.
Il nuovo manutentore era un attore di minacce. Hanno rilevato il progetto, l'hanno eseguito normalmente per un breve periodo, quindi hanno aggiunto del codice dannoso. Ogni copia di ogni altro programma che utilizzava quel componente software dirottava silenziosamente alcuni tipi di portafoglio Bitcoin per l'autore delle minacce.
Cosa puoi fare per ridurre il rischio
Come per molti aspetti della sicurezza, gestisci questo rischio applicando dei controlli. Ciò richiede governance, in altre parole, politiche e procedure. Per fortuna, esiste un software che può aiutare.
Crea un registro open source
Devi quantificare l'open source che stai utilizzando. Crea un registro che elenchi i componenti open source che utilizzi nei tuoi progetti. Elenca ogni componente open source, la versione o le versioni che hai utilizzato, i progetti in cui li hai utilizzati, qual è la versione più recente e dove può essere scaricata. Nella documentazione di progettazione per ciascuno dei tuoi progetti, dovresti elencare i componenti open source che sono in uso.
Il diavolo è nei dettagli. Non dimenticare le dipendenze e la natura gerarchica di gran parte dell'open source. I progetti open source spesso utilizzano altri progetti al loro interno, annidati come bambole russe, o richiedono l'installazione di altri componenti open source sulla macchina di destinazione in modo che possano utilizzarli.
Pubblicità
Approfondisci queste dipendenze ed elencale nel tuo registro open-source.
Esegui audit automatici
Le vulnerabilità nei pacchetti open source sono un grosso problema per NPM, il gestore di pacchetti per JavaScript. Per risolvere questo problema, hanno creato uno strumento di controllo automatico che cercherà pacchetti scaduti con aggiornamenti di sicurezza.
Questo, ovviamente, ha i suoi limiti ed è importante essere consapevoli e non affidarsi interamente agli strumenti automatici. Catturerà solo i pacchetti con vulnerabilità e aggiornamenti noti. Se il pacchetto presenta una vulnerabilità, ma non è stato aggiornato per risolverlo, il controllo NPM non ti dirà nulla.
RELAZIONATO: Controlla le tue dipendenze NPM, Rappresentano l'86% dei bug di sicurezza
Crea una mappa delle vulnerabilità
Il tuo registro open source ti fornisce un quadro chiaro dell'open source che utilizzi. Il passaggio successivo consiste nel mappare le vulnerabilità note su quel registro. A volte, questi possono essere scoperti visitando la home page del progetto e guardando l'elenco dei problemi noti.
Il National Vulnerability Database (NVD) ti fornirà un quadro molto più dettagliato. Puoi utilizzare la loro pagina di ricerca per cercare i prodotti in base al nome per scoprire quali vulnerabilità ed esposizioni comuni influiscono su quel componente software. L'NVD è una grande risorsa, anche se il suo formato richiede un po' di tempo prima che ti ci abitui.
Aggiorna il tuo registro e la mappa delle vulnerabilità
Naturalmente, questo è qualcosa che devi tenere d'occhio. Vengono scoperte continuamente nuove vulnerabilità, quindi è probabile che lo stato di sicurezza del tuo prodotto al momento del lancio si riduca lentamente nel tempo.
Pubblicità
Riconoscendo questa nuova esigenza, ci sono annunci commerciali (Black Duck, WhiteSource) applicazioni che ti aiuteranno in questo. Possono scansionare i tuoi progetti e identificare il codice open source e cercare automaticamente le vulnerabilità. Alcuni di questi (FOSSA) offrono un livello gratuito.
L'analisi statica della tua base di codice—inclusi i componenti open source—dovrebbe essere comunque una parte standard del tuo rigore di sviluppo. Strumenti come Coverity Scan possono trovare difetti nel codice come buffer overflow che possono portare a vulnerabilità. Ti consiglierà anche su come possono essere corretti.
Controlla le licenze open source e rispettale
Assicurati di comprendere le licenze in vigore sull'open source che utilizzi . Esistono molte licenze diverse, quindi verifica di soddisfare tutti i requisiti. Coinvolgi il tuo responsabile delle licenze o della conformità, se ne hai uno.
Il mancato rispetto di una licenza open source può portare a controversie. I progetti open source rispondono alle violazioni delle licenze con la stessa rapidità delle software house commerciali.
Aggiorna i tuoi componenti open source
Poiché le vulnerabilità vengono risolte dalle comunità dell'open source utilizzare, assicurati di aggiornare le tue versioni in modo da beneficiare di tali correzioni. L'open source utilizza un “pull” modello. Annunciano una nuova correzione e quindi devi andare a scaricare quella nuova versione. Questo è l'opposto di molti software commerciali che hanno un “push” modello in cui gli aggiornamenti vengono trasmessi agli utenti registrati.
Annuncio
Monitorare le pagine del progetto per gli annunci di nuove versioni e scaricare e testare le nuove build.
Il costo dell'open source
Il software open source è gratuito, ma comporta un sovraccarico di gestione e governance. Le implicazioni devono essere comprese e controllate per poterlo utilizzare in sicurezza e con il minimo rischio.