La conformità delle licenze open source e i rischi per la sicurezza

La sicurezza e la conformità di applicazioni e prodotti sono diventate fondamentali per via delle crescenti minacce alla sicurezza e dei maggiori requisiti normativi, oltre ai maggiori controlli.

Control Tower

Recentemente la società CAST ha proposto il proprio prodotto “Control Tower” che si collega direttamente ai repository di codice sorgente e aggrega automaticamente i risultati dell’analisi in tutte le applicazioni in dashboard intuitivi. In parole povere la “torre di controllo” consente a legali, esperti di sicurezza e operativi di prendere decisioni informate coinvolgendo gli sviluppatori solo quando necessario.

“Control Tower” verifica la conformità delle licenze open source e i rischi per la sicurezza in tutte le applicazioni, senza fare affidamento sugli sviluppatori. Operativo in poche settimane, a costi decisamente competitivi.

L’adozione e l’utilizzo di componenti e librerie open source

Tradizionalmente, le aziende implementano vari controlli di sicurezza e conformità durante lo sviluppo di applicazioni e prodotti tramite Secure Design Review (SDR), Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), GDPR e Conformità PCI. Tuttavia, la sicurezza e la conformità dei componenti open source vengono spesso ignorate.

L’adozione e l’utilizzo di componenti e librerie open source aumentano di giorno in giorno. Una tipica in modo diretto o indiretto e molte versioni di componenti open source presentano vulnerabilità note. Si possono stimare oltre 30 componenti vulnerabili per applicazione.

Un numero significativo di componenti o librerie open source dispone di rigide licenze copy-left o doppie licenze che ne limitano l’utilizzo nelle applicazioni closed source. La consapevolezza delle diverse licenze open source e delle loro restrizioni all’utilizzo è limitata nella comunità degli sviluppatori e l’uso improprio spesso porta a enormi problemi legali e sanzioni.

La guida LTI

Per apprendere le migliori pratiche sulla selezione del prodotto giusto per la conformità legale e di sicurezza open source, ci ispiriamo alla guida, realizzata da Santhosh Anumolu, Associate Director, per gli acquirenti di LTI, un’azienda tecnologica con 40.000 dipendenti.

L’ approccio suggerito per affrontare questa fondamentale esigenza di conformità e controllo è quello di introdurre controlli di conformità open source nel ciclo di vita dello sviluppo dell’applicazione o del prodotto. Questi controlli devono essere introdotti in anticipo e ripetuti frequentemente (ad es. ad ogni sprint).

La convalida manuale di questi controlli è noiosa e ostacolerebbe i tempi di consegna. L’approccio migliore consiste nell’utilizzare una soluzione automatizzata per la sicurezza dei componenti open source e i controlli di conformità legale. Sono disponibili strumenti sia commerciali che open source come OWASP Dependency Track per soddisfare questa esigenza.

Come procedere

▪ Formare un team di sviluppo sulla sicurezza e la conformità open source

▪ Introdurre strumenti open source automatizzati per il controllo della sicurezza e della conformità nel ciclo di vita dello sviluppo dell’applicazione o del prodotto

▪ Eseguire scansioni del codice sorgente: manuale/automatico, ad esempio, integrato in CI/CD (meglio escludere git, prova file e cartelle, ecc. per avere risultati più puliti e scansioni più veloci e invece includere le cartelle di output della build per una migliore copertura)

▪ Convalidare e correggere i problemi segnalati dallo strumento:

Componenti con vulnerabilità note
Licenze per componenti rischiose
Componenti obsoleti

▪ Risolvere i problemi in base ai consigli degli strumenti e ripetere la scansione dopo le correzioni dei problemi

▪ Ripetere le scansioni per ogni sprint per garantire la conformità continua

Come selezionare gli strumenti

Nessuno strumento soddisfa da solo ogni esigenza. Alcuni strumenti hanno più funzioni, ma alcuni sono specializzati e svolgono meglio funzioni specifiche. Tutti gli strumenti commerciali includono funzionalità di base, ma alcuni strumenti funzionano meglio in alcune aree. E’ necessario valutare le proprie esigenze in termini di controlli di conformità open source e scegliere gli strumenti più adatti.

Questi criteri possono aiutare nella selezione degli strumenti:

▪ Funzionalità: la valutazione dei componenti con vulnerabilità note, i controlli di conformità della licenza legale e le informazioni sui componenti obsoleti sono indispensabili. Qualsiasi funzionalità aggiuntiva come le metriche sulla qualità del codice, il calcolo del debito tecnico, i controlli di disponibilità del cloud, l’integrazione con CI/CD e le raccomandazioni per la correzione delle interruzioni possono costituire una scelta utile.

▪ Precisione dei risultati: tutti i risultati dello strumento automatizzato contengono alcuni falsi positivi (ad esempio, lo strumento segnala un componente con un problema, ma non è detto che sia un problema reale). Il tasso di falsi positivi per gli strumenti SCA è da moderato a basso, ma la selezione di uno strumento con tassi di falsi positivi bassi aiuta ulteriormente a ridurre lo sforzo complessivo speso nella risoluzione dei problemi.

▪ Suggerimenti per le correzioni: raccomandazioni e linee guida dettagliate sulle correzioni aiuteranno a risolvere più rapidamente i problemi o a implementare soluzioni alternative ove richiesto. Se i consigli per la correzione non fossero utili, gli sviluppatori dovrebbero dedicare più tempo alla comprensione e alla risoluzione dei problemi.

▪ Tecnologie supportate: la maggior parte degli strumenti supporta le principali tecnologie e linguaggi di programmazione. Tuttavia, identificare lo stack tecnologico organizzativo aiuterà a identificare lo strumento giusto per supportare qualsiasi tecnologia di nicchia.

▪ Tempo per trarne vantaggio: alcuni strumenti richiedono molto più tempo e impegno di altri per essere distribuiti e iniziare a ottenere risultati utilizzabili. Gli strumenti che hanno modelli di distribuzione più semplici sono da preferire se la velocità è una priorità.

▪ Tempo di scansione: il tempo di scansione varia da strumento a strumento. La scelta di uno strumento con tempi di scansione più brevi può aiutare ad accelerare il tempo della pipeline CI/CD. La maggior parte degli strumenti è comunque abbastanza veloce.

▪ Costo: primo step è selezionare comunque gli strumenti in base alle funzionalità richieste. Solo in seconda battuta ha senso esaminare ciò che è disponibile in base al proprio budget o alla propensione al rischio; in ogni caso va tenuta in conto la criticità aziendale di applicazioni e prodotti.