Language
Country/Area
No result found
I pericoli nascosti del software open source: il tuo codice è già compromesso?
Nell'attuale contesto di sviluppo software, il software open source (OSS) è diventato la prima scelta per molte aziende e sviluppatori. Sapevi però che utilizzare software open source comporta anche dei potenziali rischi? L'analisi della composizione del software (SCA) è un metodo che aiuta gli sviluppatori a esaminare i componenti open source incorporati nel loro codice per verificare se sono aggiornati, se presentano vulnerabilità di sicurezza o se sono conformi ai requisiti di licenza.
Il software open source è ampiamente apprezzato per la sua flessibilità e i ridotti costi di sviluppo, ma i rischi che comporta vengono spesso trascurati.
Contesto del rischio
Questo approccio allo sviluppo di software a partire da componenti diversi è diventato sempre più comune dalla fine degli anni '90, con l'ascesa del software open source. Questo approccio suddivide la complessità di una grande base di codice in parti più piccole per aumentare la flessibilità e accelerare il processo di sviluppo. Tuttavia, i rischi posti dal software open source aumentano chiaramente con l'utilizzo di più componenti e possono essere suddivisi in cinque categorie principali:
- Controllo delle versioni: rischi delle nuove versioni
- Sicurezza: rischi di vulnerabilità nei componenti - Vulnerabilità ed esposizioni comuni (CVE)
- Licenze: rischi dei requisiti legali per la proprietà intellettuale
- Sviluppo: rischi di compatibilità tra la base di codice esistente e il software open source
- Supporto: rischio di documentazione incompleta e componenti obsoleti
L'analisi automatizzata e la gestione dei rischi stanno diventando una necessità per le organizzazioni che fanno ampio uso di componenti open source.
Come funziona SCA
I prodotti SCA in genere funzionano in questo modo: in primo luogo, il motore di scansione esamina il codice sorgente del software e i relativi artefatti utilizzati per compilarlo, identificando i componenti open source utilizzati e le loro versioni. Queste informazioni vengono poi memorizzate in un database, formando un catalogo dei componenti open source utilizzati. Questo catalogo viene poi confrontato con un database di vulnerabilità di sicurezza note, requisiti di licenza e versioni storiche.
Ad esempio, quando si esegue il rilevamento delle vulnerabilità della sicurezza, questo confronto viene spesso effettuato con le vulnerabilità di sicurezza note tracciate nel National Vulnerability Database (NVD). Alcuni prodotti potrebbero utilizzare database di vulnerabilità proprietari aggiuntivi per i loro controlli. Per quanto riguarda la proprietà intellettuale e la conformità legale, i prodotti SCA estraggono e valutano i tipi di licenze utilizzate dai componenti open source. Questi risultati vengono solitamente forniti agli utenti in diversi formati digitali e includono valutazioni dei rischi e raccomandazioni sui requisiti legali in base alle esigenze dei diversi prodotti, in particolare i requisiti per licenze di condivisione forti o deboli.
I risultati possono includere anche un Service Component Manifest (SBOM), che descrive in dettaglio i componenti open source utilizzati nell'applicazione software e le relative proprietà.
Utilizzo di SCA
Poiché la SCA ha un impatto su diverse funzioni organizzative, diversi team sfruttano questi dati, spesso a seconda delle dimensioni e della struttura dell'organizzazione. I dipartimenti IT utilizzano SCA per implementare e gestire la tecnologia e tra i principali stakeholder figurano il Chief Information Officer (CIO), il Chief Technology Officer (CTO) e il Chief Enterprise Architect (EA). I dati di sicurezza e autorizzazione vengono spesso utilizzati dal Chief Information Security Officer (CISO) per gestire i rischi per la sicurezza, mentre il Chief IP/Compliance Officer si concentra sui rischi per la proprietà intellettuale. A seconda delle capacità del prodotto SCA, questi strumenti possono essere utilizzati direttamente nell'ambiente di sviluppo integrato (IDE) dello sviluppatore oppure possono essere impiegati come passaggio necessario nel processo di controllo della qualità del software.
Vantaggi e svantaggi della SCAIn alcuni paesi, come gli Stati Uniti, la generazione di SBOM è obbligatoria per garantire la sicurezza del software fornito dai fornitori alle agenzie governative.
L'automazione è il principale vantaggio dei prodotti SCA. Quando gli sviluppatori utilizzano e integrano componenti open source, non è necessario svolgere ulteriore lavoro manuale. Ciò include anche la gestione automatizzata dei riferimenti indiretti ad altri componenti open source. Tuttavia, gli attuali prodotti SCA presentano anche alcuni punti deboli chiave, come: il processo di distribuzione è complesso e richiede molto tempo, e potrebbe richiedere mesi per essere pienamente operativo; ogni prodotto utilizza la propria libreria di componenti OSS proprietaria, le dimensioni e la copertura di queste librerie sono limitati; le percentuali possono variare notevolmente; e i dati sulle vulnerabilità sono spesso limitati a segnalare solo quelle vulnerabilità che sono state formalmente segnalate nell'NVD.
Inoltre, i prodotti SCA spesso non dispongono di una guida automatizzata, di raccomandazioni inadeguate sulle azioni da intraprendere sui dati nei report e di scarse indicazioni sui requisiti legali per le licenze OSS rilevate.
In questo contesto, stai anche pensando a come gestire in modo più efficace i potenziali rischi del software open source e proteggere il tuo codice dalle minacce?
