Nuove vulnerabilità nei pacchetti open source in calo del 20% rispetto allo scorso anno
29 Giugno 2020 - Tempo di lettura: 7 minuti
Le nuove vulnerabilità nei pacchetti open source sono diminuite del 20% rispetto allo scorso anno, suggerendo che la sicurezza dei pacchetti e dei conteiners open source sta andando in una direzione positiva, secondo Snyk.
Le vulnerabilità ben note, come lo scripting cross-site, continuano a essere segnalate ma non incidono su tutti i progetti degli anni precedenti. Ciò è ulteriormente incoraggiato quando le organizzazioni iniziano a guidare un cambiamento culturale che incarna la sicurezza open source e container come una responsabilità fondamentale condivisa e integrata tra i team di sviluppo, sicurezza e operazioni.
Quest'anno il rapporto ha esaminato ancora di più la vulnerabilità e le tendenze a livello di ecosistema che incidono sulla posizione generale di sicurezza delle organizzazioni che si affidano a librerie open source.
Tra i sei ecosistemi popolari esaminati dal rapporto, nel 2019 sono state segnalate meno nuove vulnerabilità rispetto al 2018 - una scoperta promettente - ma ci sono ancora miglioramenti significativi da perseguire con poco meno di due terzi delle vulnerabilità che impiegano ancora più di 20 giorni per rimediare .
Le minacce comuni vengono catturate e sanate in anticipo
Mentre le vulnerabilità ben note nei pacchetti open source, come lo scripting cross site, sono riportate in numero elevato e il numero di progetti che hanno un impatto è piuttosto basso. Queste minacce comuni sembrano essere scoperte e risolte in anticipo a differenza di alcune vulnerabilità meno note.
Ad esempio, il rapporto ha rilevato che alcune vulnerabilità sono state segnalate in pacchetti molto popolari, che interessano migliaia di progetti e quindi aumentano la probabilità che vengano sfruttati dagli aggressori. Sulla base del rapporto, la principale vulnerabilità che attualmente ha un impatto sui progetti acquisiti è il prototipo dell'inquinamento in quasi il 27% di tutti i progetti.
Per la prima volta negli ultimi quattro anni, c'è stato un grande cambiamento nella mentalità della sicurezza mentre le organizzazioni iniziano ad abbracciare gli elementi chiave di DevSecOps e iniziano a implementare programmi più scalabili e best practice per garantire la responsabilità condivisa.
Chi dovrebbe essere responsabile della progettazione e dell'implementazione dei controlli di sicurezza?
Quando agli intervistati è stata posta la domanda a risposta multipla su chi ritenevano fossero responsabili della progettazione e dell'implementazione dei controlli di sicurezza nello sviluppo del software, i team di sviluppo sono stati comunemente identificati oltre alle operazioni e ai team di sicurezza. Questo è molto più uniforme tra i tre diversi team rispetto allo scorso anno in cui meno del 25% ha ritenuto che la sicurezza e le operazioni avessero un ruolo.
Tuttavia, il fatto che le risposte fossero tutte inferiori al 65% indica ancora che gli intervistati in genere non hanno identificato tutti e tre i gruppi come responsabili congiuntamente. Sebbene siano stati compiuti progressi, è chiaro che è ancora necessario un passaggio più significativo verso una cultura della responsabilità condivisa.
“Il rapporto di quest'anno è molto incoraggiante, poiché stiamo vedendo il volume delle vulnerabilità dell'open source scendere per la prima volta in quattro anni. Inoltre, emergono tendenze positive intorno alla collaborazione di team di sviluppo, sicurezza e operazioni per rispondere alla crescente domanda di sviluppo di applicazioni sicure", ha affermato Alyssa Miller, Application Security Advocate, Snyk.
"Nonostante i progressi di anno in anno, dobbiamo continuare a dare la priorità alla sicurezza e consentire alle organizzazioni di implementare programmi per aiutare DevSecOps e gli sviluppatori a essere coinvolti nella protezione del loro codice fin dall'inizio. Dobbiamo concentrarci sul continuare questi sforzi per garantire che queste tendenze emergenti continuino su questa traiettoria positiva nel 2021 e oltre."
