La recente scoperta di una backdoor nell'utilità di compressione dati XZ Utils, presente in quasi tutte le principali distribuzioni Linux, ci ricorda chiaramente che le organizzazioni che utilizzano componenti open source hanno in ultima analisi la responsabilità di proteggere il software.

XZ Utils, come migliaia di altri progetti open source, è gestito da volontari e, nel suo caso, ha un unico manutentore che lo gestisce. Tali progetti spesso dispongono di risorse scarse o nulle per la gestione dei problemi di sicurezza, il che significa che le organizzazioni utilizzano il software a proprio rischio. Ciò significa che i team di sicurezza e sviluppo devono implementare misure per la gestione del rischio open source nello stesso modo in cui fanno con il codice sviluppato internamente, affermano gli esperti di sicurezza.

"Sebbene sia improbabile che un'organizzazione possa prevenire efficacemente [tutta] l'esposizione ai rischi della catena di fornitura, le organizzazioni possono assolutamente concentrarsi su una strategia per ridurre la probabilità che un attacco alla catena di fornitura abbia successo", afferma Jamie Scott, product manager fondatore di Endor Labs.

L’open source non è la stessa cosa dell’outsourcing: “I manutentori del software open source sono volontari. A livello industriale dobbiamo trattarli come tali. Possediamo il nostro software; siamo responsabili del software che riutilizziamo.”

Ben intenzionati, con risorse insufficienti

Preoccupazioni sulla sicurezza del software open source non sono affatto una novità. Ma spesso ci vogliono scoperte come la Vulnerabilità Log4Shell e la backdoor in XZ Utilis per far capire davvero quanto le organizzazioni siano vulnerabili ai componenti del loro codice. E spesso, il codice proviene da progetti open source ben intenzionati ma irrimediabilmente con risorse insufficienti e mantenuti minimamente.

XZ Utilis, ad esempio, è essenzialmente un progetto condotto da una sola persona. Un altro individuo è riuscito a farlo intrufolare la backdoor nell'utilità in un periodo di quasi tre anni, guadagnando gradualmente sufficiente fiducia da parte del manutentore del progetto. Se uno sviluppatore Microsoft non si fosse imbattuto in questo caso alla fine di marzo mentre indagava su comportamenti strani associati a un'installazione Debian, la backdoor sarebbe potuta finire su milioni di dispositivi in ​​tutto il mondo, compresi quelli appartenenti a grandi aziende e agenzie governative. Come si è scoperto, la backdoor ha avuto un impatto minimo perché ha interessato le versioni di XZ Utils che erano presenti solo nelle versioni unstable e beta di Debian, Fedora, Kali, open SUSE e Arch Linux.

Il prossimo compromesso del codice open source potrebbe essere molto peggiore. "La parte più spaventosa per le organizzazioni aziendali è che le loro applicazioni sono costruite su progetti software open source proprio come XZ Utils", afferma Donald Fischer, co-fondatore e CEO di Tidelift. "XZ Utils è un pacchetto di decine di migliaia utilizzato ogni giorno dalle tipiche organizzazioni aziendali", afferma.

La maggior parte di queste organizzazioni non ha una visibilità sufficiente sulla sicurezza e sulla resilienza di questa parte della catena di fornitura del software per poter valutare i rischi, osserva.

Una recente Harvard Business School Uno studio ha stimato che il valore dal lato della domanda del software open source ammonta all’incredibile cifra di 8.8 trilioni di dollari. I manutentori sono al centro di questo ecosistema e molti di loro operano da soli, afferma Fischer. Un sondaggio condotto da Tidelift lo scorso anno ha rilevato che il 44% dei manutentori di progetti open source si descrive come gli unici manutentori dei propri progetti. Il sessanta per cento si è identificato come hobbista non retribuito e la stessa percentuale ha affermato di aver lasciato o di aver preso in considerazione l'idea di lasciare il proprio ruolo di manutentori del progetto. Molti manutentori descrivono i loro sforzi come un lavoro stressante, solitario e finanziariamente poco gratificante, afferma Fischer.

"L'hacking di XZ utils mette in netto rilievo i rischi di investimenti insufficienti nella salute e nella resilienza della catena di fornitura di software open source [su cui] fanno affidamento le organizzazioni aziendali", afferma Fischer. “Le organizzazioni aziendali devono rendersi conto che la maggior parte dei pacchetti open source più affidabili sono gestiti da volontari che si descrivono come hobbisti non retribuiti. Questi manutentori non sono fornitori aziendali, ma ci si aspetta che lavorino e forniscano risultati come loro”.

Pericolo: dipendenze transitive

A studio condotto da Endor nel 2022 ha scoperto che il 95% delle vulnerabilità open source sono presenti nelle cosiddette dipendenze transitive, ovvero pacchetti o librerie open source secondari da cui potrebbe dipendere un pacchetto open source primario. Spesso si tratta di pacchetti che gli sviluppatori non selezionano direttamente ma che vengono automaticamente utilizzati da un pacchetto open source nel loro progetto di sviluppo.

"Ad esempio, quando ti fidi di un pacchetto Maven, in media ci sono altre 14 dipendenze di cui ti fidi implicitamente", afferma Scott. "Questo numero è ancora maggiore in alcuni ecosistemi software come NPM, dove in media importi altri 77 componenti software per ognuno di cui ti fidi."

Un modo per iniziare a mitigare i rischi dell'open source è prestare attenzione a queste dipendenze ed essere selettivi su quali progetti scegliere, afferma.

Le organizzazioni dovrebbero esaminare le dipendenze, in particolare i pacchetti più piccoli, una tantum, gestiti da team di una o due persone, aggiunge Dimitri Stiliadis, CTO e cofondatore di Endor. Dovrebbero determinare se le dipendenze nel loro ambiente hanno controlli di sicurezza adeguati o se un singolo individuo esegue il commit di tutto il codice; se hanno file binari nei loro repository di cui nessuno è a conoscenza; o anche se qualcuno sta mantenendo attivamente il progetto, dice Stiliadis.

"Concentra i tuoi sforzi sul miglioramento dell'efficacia della risposta: controlli fondamentali come il mantenimento di un inventario software maturo rimangono uno dei programmi di maggior valore che puoi avere in atto per identificare, definire l'ambito e rispondere rapidamente ai rischi software una volta identificati", Scott consiglia.

Anche gli strumenti di analisi della composizione del software, gli scanner di vulnerabilità, i sistemi EDR/XDR e le SBOM possono aiutare le organizzazioni a identificare rapidamente i componenti open source vulnerabili e compromessi.

Riconoscere la minaccia

"Mitigare l'esposizione inizia con la comprensione condivisa e il riconoscimento da parte dei dirigenti e anche a livello di consiglio che circa il 70% degli ingredienti del prodotto software medio sono software open source storicamente creati da contributori per lo più senza compenso", afferma Fischer di Tidelift.  

Nuove normative e linee guida nel settore dei servizi finanziari, FDA e NIST determineranno il modo in cui il software verrà sviluppato negli anni a venire e le organizzazioni devono prepararsi ora. "I vincitori qui si adatteranno rapidamente da una strategia reattiva a una strategia proattiva per gestire i rischi legati all'open source", afferma.

Fischer consiglia alle organizzazioni di chiedere ai propri team di sicurezza e di progettazione di identificare il modo in cui i nuovi componenti open source entrano nel loro ambiente. Dovrebbero inoltre definire i ruoli per il monitoraggio di queste componenti e rimuovere in modo proattivo quelle che non si adattano alla propensione al rischio dell’azienda. “Reagire ai problemi in fase avanzata è diventato un modo inefficace per affrontare la portata del rischio per l’azienda negli ultimi anni, e la Il governo degli Stati Uniti sta segnalando quell’era sta volgendo al termine”, dice.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security