Classifica delle librerie che richiedono un controllo di sicurezza particolare

Il fondo creato dall'organizzazione Linux Foundation Core Infrastructure Initiative, nell'ambito del quale importanti aziende hanno unito i propri sforzi per garantire il supporto ai progetti open source coinvolti in aree chiave dell'industria informatica, ha condotto un secondo studio nell'ambito del programma Census, volto a identificare i progetti open source che necessitano di un'urgente verifica della sicurezza.

Il secondo studio è focalizzato sull'analisi del codice open source condiviso, utilizzato implicitamente in vari progetti aziendali sotto forma di dipendenze scaricate da repository esterni. Le vulnerabilità e la compromissione dei sviluppatori di componenti di terze parti coinvolti nel funzionamento delle applicazioni (supply chain) possono annullare tutti gli sforzi per migliorare la sicurezza del prodotto principale. Come risultato dello studio, è stato determinado 10 dei pacchetti più comunemente utilizzati in JavaScript e Java, la cui sicurezza e attività di manutenzione richiedono particolare attenzione.

Librerie JavaScript dal repository npm:

• async (196 mila righe di codice, 11 autori, 7 committenti, 11 problemi aperti);
• inherits (3.8 mila righe di codice, 3 autori, 1 committente, 3 problemi aperti);
• isarray (317 righe di codice, 3 autori, 3 committenti, 4 problemi aperti);
• kind-of (2 mila righe di codice, 11 autori, 11 committenti, 3 problemi aperti);
• lodash (42 mila righe di codice, 28 autori, 2 committenti, 30 problemi aperti);
• minimist (1.2 mila righe di codice, 14 autori, 6 committenti, 38 problemi aperti);
• natives (3 mila righe di codice, 2 autori, 1 committente, nessun problema aperto);
• qs (5.4 mila righe di codice, 5 autori, 2 committenti, 41 problemi aperti);
• readable-stream (28 mila righe di codice, 10 autori, 3 committenti, 21 problemi aperti);
• string_decoder (4.2 mila righe di codice, 4 autori, 3 committenti, 2 problemi aperti).

Librerie Java dai repository Maven:

• jackson-core (74 mila righe di codice, 7 autori, 6 committenti, 40 problemi aperti);
• jackson-databind (74 mila righe di codice, 23 autori, 2 committenti, 363 problemi aperti);
• guava.git, librerie Google per Java (1 milione di righe di codice, 83 autori, 3 committenti, 620 problemi aperti);
• commons-codec (51 mila righe di codice, 3 autori, 3 committenti, 29 problemi aperti);
• commons-io (73 mila righe di codice, 10 autori, 6 committenti, 148 problemi aperti);
• httpcomponents-client (121.000 righe di codice, 16 autori, 8 committers, 47 problemi non risolti);
• httpcomponents-core (131.000 righe di codice, 15 autori, 4 committers, 7 problemi non risolti);
• logback (154.000 righe di codice, 1 autore, 2 committers, 799 problemi non risolti);
• commons-lang (168.000 righe di codice, 28 autori, 17 committers, 163 problemi non risolti);
• slf4j (38.000 righe di codice, 4 autori, 4 committers, 189 problemi non risolti);

Il rapporto esamina anche questioni di standardizzazione dello schema di denominazione dei componenti esterni, sicurezza degli account degli sviluppatori e mantenimento delle versioni obsolete dopo il rilascio di nuove versioni significative. Inoltre, l'organizzazione Linux Foundation ha pubblicato documento raccomandazioni pratiche per organizzare un processo di sviluppo sicuro per progetti open source.

Il documento affronta questioni relative alla distribuzione dei ruoli nel progetto, alla creazione di team responsabili della sicurezza, alla definizione delle politiche di sicurezza, al monitoraggio delle autorizzazioni dei partecipanti al progetto, all'uso corretto di Git nella correzione delle vulnerabilità per evitare perdite prima della pubblicazione della correzione, alla definizione dei processi di risposta ai report di problemi di sicurezza, all'implementazione di sistemi di testing della sicurezza, all'applicazione di procedure di revisione del codice e alla considerazione dei criteri di sicurezza nella formazione delle versioni.

Fonte: opennet.ru