Google propone di stabilire nuove regole per migliorare la sicurezza open source

La sicurezza del software open source ha attirato l'attenzione del settore, ma le soluzioni richiedono il consenso sulle sfide e la cooperazione nell'attuazione.

Il problema è complesso e ci sono molte sfaccettature da coprire, dalla catena di approvvigionamento, gestione delle dipendenze, identità, tra le altre cose. Per fare ciò, Google ha recentemente rilasciato un framework ("Know, Prevent, Fix") che spiega come il settore può pensare alle vulnerabilità nell'open source e alle aree specifiche che devono essere affrontate per prime.

Google ne spiega le ragioni:

“A causa dei recenti eventi, il mondo del software ha acquisito una comprensione più profonda del rischio reale di attacchi alla catena di fornitura. Il software open source dovrebbe essere meno rischioso dal punto di vista della sicurezza, poiché tutto il codice e le dipendenze sono aperti e disponibili per l'ispezione e la verifica. E sebbene questo sia generalmente vero, si presume che le persone stiano effettivamente facendo questo lavoro di ispezione. Con così tante dipendenze, è impossibile monitorarle tutte e molti pacchetti open source non sono ben mantenuti.

“È normale che un programma dipenda, direttamente o indirettamente, da migliaia di pacchetti e librerie. Ad esempio, Kubernetes ora dipende da circa 1000 pacchetti. L'open source probabilmente utilizza le dipendenze piuttosto che il software proprietario e proviene da una gamma più ampia di fornitori; il numero di entità indipendenti di cui ci si può fidare può essere molto elevato. Ciò rende estremamente difficile capire come l'open source viene utilizzato nei prodotti e quali vulnerabilità possono essere rilevanti. Inoltre, non vi è alcuna garanzia che ciò che viene creato corrisponderà al codice sorgente.

All'interno del framework proposto da Google, si suggerisce di suddividere questa difficoltà in tre aree problematiche largamente indipendenti, ciascuna con obiettivi specifici:

Conosci le vulnerabilità del tuo software

Conoscere le vulnerabilità del software è più difficile di quanto potresti aspettarti per molte ragioni. sì ok esistono meccanismi per segnalare le vulnerabilità, non è chiaro se influenzano davvero le versioni specifiche del software che stai utilizzando:

• Obiettivo: dati accurati sulla vulnerabilità: in primo luogo, è fondamentale acquisire metadati accurati sulla vulnerabilità da tutte le origini dati disponibili. Ad esempio, sapere quale versione ha introdotto una vulnerabilità aiuta a determinare se il software è interessato e sapere quando è stata applicata la patch si traduce in correzioni accurate e tempestive (e una finestra ristretta per il possibile sfruttamento). Idealmente, questo flusso di lavoro di classificazione dovrebbe essere automatizzato.
• In secondo luogo, la maggior parte delle vulnerabilità risiede nelle tue dipendenze, piuttosto che nel codice che scrivi o controlli direttamente. Quindi, anche quando il tuo codice non cambia, il panorama delle vulnerabilità che interessano il tuo software può cambiare costantemente: alcune sono corrette, altre vengono aggiunte.
• Scopo: schema standard per database di vulnerabilità L'infrastruttura e gli standard di settore sono necessari per monitorare e mantenere le vulnerabilità open source, comprenderne le conseguenze e gestirne le mitigazioni. Uno schema di vulnerabilità standard consentirebbe l'esecuzione di strumenti comuni su più database di vulnerabilità e semplificherebbe l'attività di tracciamento, soprattutto quando le vulnerabilità attraversano più lingue o sottosistemi.

Evita di aggiungere nuove vulnerabilità

L'ideale sarebbe evitare la creazione di vulnerabilità E mentre gli strumenti di test e analisi possono aiutare, la prevenzione sarà sempre un argomento difficile.

qui, Google propone di concentrarsi su due aspetti specifici:

• Comprendi i rischi quando decidi una nuova dipendenza
• Migliora i processi critici di sviluppo del software

Riparare o rimuovere le vulnerabilità

Google riconosce che il problema generale della riparazione esula dalla sua competenza, ma l'editore crede che ci sia molto di più che gli attori possano fare per affrontare il problema specifico per gestire le vulnerabilità nelle dipendenze.

Inoltre menziona: 

“Oggi c'è poco aiuto su questo fronte, ma man mano che miglioriamo la precisione, vale la pena investire in nuovi processi e strumenti.

“Un'opzione, ovviamente, è riparare direttamente la vulnerabilità. Se puoi farlo in modo retrocompatibile, la soluzione è disponibile per tutti. Ma la sfida è che è improbabile che tu abbia esperienza con il problema o la capacità diretta di apportare modifiche. La risoluzione di una vulnerabilità presuppone inoltre che i responsabili della manutenzione del software siano consapevoli del problema e abbiano le conoscenze e le risorse per rivelare la vulnerabilità.

fonte: https://security.googleblog.com