Trascurare gli sviluppatori open source mette a rischio Internet

Il software è al centro di tutte le aziende moderne ed è fondamentale in ogni aspetto delle operazioni. Quasi tutte le aziende utilizzeranno software open source, consapevolmente o meno, poiché anche il software proprietario dipende da librerie open source. di OpenUK Il rapporto "State of Open" del 2022 ha rilevato che l'89% delle aziende si affidava a software open source, ma non tutte sono chiare sui dettagli del software su cui fanno affidamento.

Le aziende richiedono sempre più informazioni sui loro software operativi critici. Le aziende responsabili si interessano in dettaglio alla loro catena di fornitura del software e creano una distinta base del software (SBOM) per ciascuna applicazione. Questo livello di informazioni è fondamentale in modo che quando vengono identificati difetti di sicurezza nel loro software, possano essere immediatamente certi di quale software e versioni sono in uso e quali sistemi sono interessati. La conoscenza è potere in queste situazioni!

Affidarsi ai volontari

Alla fine del 2021 è stata chiamata una vulnerabilità di sicurezza Log4Shell è stato identificato in un framework di registrazione Java ampiamente utilizzato, Log4j. Poiché si tratta di una libreria open source ampiamente utilizzata, la vulnerabilità è stata ben pubblicizzata e sono previste correzioni. in ogni caso, il i manutentori del progetto erano volontari. Avevano lavori giornalieri e non erano disponibili per soluzioni di sicurezza urgenti, anche se un gran numero di sistemi era interessato. Si stima che questa vulnerabilità da sola abbia colpito il 93% degli ambienti cloud aziendali.

A quel tempo, c'era una certa stampa negativa sull'open source, ma la verità è che se si trattava di un componente closed-source, la vulnerabilità potrebbe non essere mai stata pubblicamente nota, lasciando le organizzazioni aperte agli attacchi. La natura open source della libreria significava che poteva essere ispezionata, riscontrati problemi e consigli offerti da altri. Quindi, sì, i manutentori non erano disponibili per problemi di sicurezza nel loro progetto di volontariato. La grande domanda, quindi, è: come siamo entrati in una situazione in cui le grandi aziende dipendevano dal software che era responsabilità di qualcuno che fa qualcos'altro per pagare i propri conti?

Trascurare le dipendenze del software è un affare rischioso qualunque sia la licenza del software, ma quando è open source e molto diffuso, diventa particolarmente pericoloso. Attenersi alla storia di una vulnerabilità; il problema esisteva nella codebase da anni, ma non è stato individuato. Lo strumento che è stato così ampiamente utilizzato non è stato, in effetti, così ampiamente supportato - e quello che è successo dopo è storia.

Questa storia si ripete più e più volte, in così tante aziende che hanno dipendenze critiche ma non intraprendono azioni per supportare né i manutentori né i progetti stessi. Avere una SBOM per il software utilizzato da un'azienda significa avere le informazioni a portata di mano. Per le organizzazioni che forniscono software ad altri, l'aspettativa di fornire la SBOM insieme al codice è sempre più la norma.

Conoscere le dipendenze per valutare il rischio

Portare la conoscenza delle dipendenze rende più facile valutare il rischio associato a ciascuna di esse. Questi progetti open source sono i più semplici da valutare: i problemi sono stati risolti e ci sono stati dei rilasci di recente? Essere in grado di vedere i manutentori e l'attività del progetto per ogni progetto fornisce una buona visione dello stato di salute del progetto.

Le aziende possono fare la loro parte per ridurre i rischi sostenendo i progetti da cui dipendono. Alcuni progetti accettano la sponsorizzazione direttamente tramite lo schema GitHub Sponsors, altri potrebbero invece apprezzare offerte di hosting o un audit di sicurezza. Ogni progetto open source apprezza i contributi. Se la tua azienda avesse creato questa libreria da sola, gli ingegneri all'interno dell'azienda dovrebbero correggere ogni bug da soli.

L'open source è più simile a uno schema di proprietà condivisa. Non tutti dobbiamo costruire la stessa cosa ripetutamente, ma possiamo contribuire, il che è meno sforzo e porta, di conseguenza, a una migliore qualità. Una delle cose più impattanti che le aziende possono fare è utilizzare un po' delle loro risorse ingegneristiche e contribuire a correzioni di bug o funzionalità ai progetti che sono così fondamentali per il business.

Coinvolgere i tuoi ingegneri in un progetto ha molti vantaggi. Lo conoscono e possono tenere d'occhio le nuove funzionalità o quando è disponibile una nuova versione. Fondamentalmente, l'azienda ha una visione della salute e dello stato del progetto dipendente e fa parte di ciò che lo mantiene sano, riducendo il rischio per l'azienda di un problema con una dipendenza. Diverse organizzazioni, tra cui Aiven, hanno un OSPO (ufficio programmi open source), con personale dedicato a contribuire o addirittura mantenere i progetti utilizzati dall'organizzazione. Questi dipartimenti spesso contribuiscono alla presenza generale dell'azienda nell'ecosistema open source e consentono ad altri dipendenti di interagire con l'open source.

Un altro approccio è supportare le organizzazioni che esistono per supportare l'open source. Il OpenSSF (Fondazione per la sicurezza open source) lavora per migliorare la sicurezza dei progetti open source ed è finanziato dalle organizzazioni che dipendono da tali progetti. Pubblica inoltre eccellenti risorse di apprendimento in modo che le aziende possano informarsi sui rischi del software che utilizzano. Un'altra organizzazione simile è Tidelift, che collabora con i manutentori per garantire il rispetto di determinati requisiti di base, sempre finanziati dalle organizzazioni. Tidelift fornisce anche strumenti e formazione per aiutare le aziende a gestire la catena di fornitura del software e ad adottare le migliori pratiche in questo settore.

Garantire un futuro software più sicuro

Le aziende dipendono dal software e questo include il software open source, ampiamente utilizzato e generalmente più sicuro delle alternative proprietarie.

Questa è una mossa intelligente, ma una mossa ancora più intelligente consiste nell'avere una chiara conoscenza della catena di fornitura del software e delle sue dipendenze. Quando si verifica un problema, dipendere da progetti sani e avere i dettagli del software disponibili aiuta ogni organizzazione. Se ogni organizzazione lo fa, il rischio di eventi come la vulnerabilità di Log4Shell viene ridotto.