Gli sviluppatori utilizzano abitualmente codice di terze parti per costruire le loro applicazioni, in nome dell'efficienza e del risparmio di tempo. Tuttavia, questo affidamento a componenti esterni, in particolare a software open-source (OSS), introduce rischi significativi, tra cui vulnerabilità e problemi di licenza. Secondo un'indagine di GitHub del 2023, il 31% degli sviluppatori considera la ricerca e la correzione delle vulnerabilità di sicurezza il secondo compito più importante, subito dopo la scrittura del codice (32%).
Di conseguenza, molte organizzazioni sono preoccupate per la loro dipendenza dagli OSS, spesso presi di mira dagli hacker. Le organizzazioni si trovano ad affrontare le sfide legate all'aumento della vulnerabilità nella catena di fornitura del software e a capire come mitigare efficacemente il rischio sulla scia dei recenti attacchi di alto profilo.
Una ricerca di ESG rivela che il 91% delle organizzazioni ha subito un incidente nella catena di fornitura del software negli ultimi 12 mesi. Gli incidenti più comuni includono:
Vulnerabilità importanti come Log4J, Curl, Apache Struts e OpenSSL hanno portato a numerosi casi di danni operativi. Questi casi evidenziano il grave impatto che le organizzazioni subiscono quando viene sfruttata una singola debolezza all'interno della catena di fornitura del software. In risposta a questi rischi crescenti, gli enti normativi di tutto il mondo stanno ponendo l'accento sulla trasparenza e sulla sicurezza del software. L'adozione di un Software Bill of Materials (SBOM) sta diventando una strategia chiave per gestire i rischi della catena di fornitura del software.
I regolamenti SBOM acquistano slancio
Le normative SBOM sono sempre più diffuse. Molti governi hanno pubblicato raccomandazioni sull'implementazione dello SBOM. Negli Stati Uniti, le raccomandazioni SBOM sono incluse in diverse linee guida governative, tra cui:
Nel 2023, la CISA ha pubblicato tre documenti chiave per promuovere l'adozione di SBOM. Questi si sono concentrati sull'aumento dell'uso della SBOM, sull'esplorazione di nuove tecnologie e applicazioni e sulla promozione della collaborazione tra le comunità.
In Europa, l'Agenzia europea per la sicurezza informatica (ENISA) ha pubblicato le "Linee guida per la sicurezza della Supply Chain per l'Internet degli oggetti", che offrono alle organizzazioni preziose indicazioni per migliorare la sicurezza informatica e gestire i rischi della catena di fornitura del software.
Altri Paesi hanno emanato linee guida simili, tra cui:
Consiglia alle organizzazioni di utilizzare gli SBOM per valutare i rischi associati ai componenti software che utilizzano e per identificare e risolvere le vulnerabilità in tali componenti.
In "Information Security Manual: Guidelines for Software Development", l'ACSC raccomanda di utilizzare gli SBOM per migliorare la trasparenza della catena di fornitura informatica, facilitando l'identificazione e la gestione dei rischi per la sicurezza legati ai singoli componenti software utilizzati nelle applicazioni.
Come gli standard PCI DSS richiedono la generazione di SBOM
Riconoscendo i rischi crescenti per i dati delle carte di pagamento, il Payment Card Industry Data Security Standard (PCI DSS) è diventato una forza trainante per l'adozione delle SBOM. L'ultima versione, PCI DSS 4.0, impone l'uso di SBOM, sottolineando il loro ruolo critico nella salvaguardia delle informazioni sensibili. Fornendo un inventario dettagliato dei componenti software, le SBOM consentono alle organizzazioni di identificare e risolvere le vulnerabilità in modo proattivo, riducendo il rischio di costose violazioni dei dati e di perdite finanziarie.
Istituito nel 2004, il PCI DSS è uno standard di sicurezza completo progettato per proteggere le informazioni delle carte di credito. Delinea una serie di requisiti rigorosi per le aziende che gestiscono transazioni con carta di credito, adattati al volume di transazioni elaborate annualmente. La versione 2022 di PCI DSS v4.0 ha introdotto cambiamenti significativi, tra cui il mandato SBOM, per far fronte all'evoluzione delle minacce. La conformità agli standard PCI DSS v4.0 è obbligatoria entro aprile 2024, con requisiti specifici introdotti gradualmente entro il 31 marzo 2025.
Fonte: PCI DSS V4.0 in sintesi
Rendendo obbligatori gli SBOM, gli standard PCI DSS consentono alle organizzazioni di ottenere una comprensione completa del loro ecosistema software, permettendo loro di identificare e risolvere le vulnerabilità in modo proattivo. Questo approccio riduce significativamente il rischio di costose violazioni dei dati e di perdite finanziarie.
Una nuova versione degli standard PCI DSS, la versione 4.0.1, è stata rilasciata a metà del 2024. Ciò significa che la versione precedente, la 4.0, non sarà più valida dopo il 31 dicembre 2024. Tuttavia, la nuova versione non aggiunge o elimina alcuna regola e non modifica le scadenze. Pertanto, le informazioni sui requisiti SBOM contenute in questo blog sono valide sia per la versione 4.0 che per la versione 4.0.1.
Conformità al requisito 6.3.2 di PCI DSS
Il requisito SBOM in PCI DSS v4.0 fa parte dei più ampi miglioramenti apportati al PCI DSS nella sua ultima versione. Introdotto come parte dei 64 nuovi requisiti aggiunti nella versione 4.0, il requisito SBOM affronta in modo specifico la necessità per le organizzazioni di mantenere un inventario dei componenti software, con particolare attenzione al software personalizzato e su misura.
Questo requisito è classificato nell'ambito del Requisito 6 degli standard PCI DSS, che impone la creazione e il mantenimento di sistemi e applicazioni sicuri attraverso l'implementazione di solide misure di sicurezza e l'esecuzione regolare di valutazioni e aggiornamenti delle vulnerabilità. Questo requisito è essenziale per ridurre i rischi posti dalle vulnerabilità del software e salvaguardare i dati dei titolari di carta. La Sezione 6 copre cinque aree principali:
- 6.1 I processi e i meccanismi per lo sviluppo e la manutenzione di sistemi e software sicuri sono definiti e compresi.
- 6.2 I software personalizzati e su misura sono sviluppati in modo sicuro.
- 6.3 Le vulnerabilità della sicurezza sono identificate e affrontate.
- 6.4 Le applicazioni web rivolte al pubblico sono protette dagli attacchi.
- 6.5 Le modifiche a tutti i componenti del sistema sono gestite in modo sicuro.
Più specificamente, il requisito 6.3.2 è un importante aggiornamento che deriva da diverse violazioni in cui le vulnerabilità dei componenti di terze parti, o le violazioni dei fornitori di componenti di terze parti, hanno portato alla compromissione dei dati dei titolari di carta. Il requisito recita come segue:
6.3.2.b Esaminare la documentazione del software, anche per il software personalizzato e su misura che integra componenti software di terzi, e confrontarla con l'inventario per verificare che l'inventario includa il software personalizzato e su misura e i componenti software di terzi.
Le organizzazioni devono documentare e gestire in modo approfondito i componenti e i servizi specifici utilizzati nelle loro applicazioni. Mentre alcune di queste informazioni potevano essere coperte dai diagrammi di flusso dei dati, i nuovi requisiti richiedono una documentazione molto più dettagliata. Tenere traccia di questi dettagli può essere impegnativo, dato che i componenti vengono aggiornati e modificati. È consigliabile utilizzare un modello standard per acquisire queste informazioni. Inoltre, alcuni repository di codice sorgente, come GIT, possono offrire strumenti per esportare un elenco dei componenti in uso. Come minimo, l'inventario dovrebbe includere:
- Componenti dell'applicazione (tipicamente progetti di repository)
- Elenco dei componenti di terze parti
- Elenco delle dipendenze dell'applicazione (ad es. Tomcat, Jboss, .NET, Middleware)
- Elenco degli script di pagina di pagamento autorizzati
Come OPSWAT SBOM può aiutare a soddisfare i requisiti PCI DSS
Le normative richiedono sempre più spesso gli SBOM per garantire la sicurezza della catena di fornitura del software. Tuttavia, le organizzazioni hanno difficoltà a creare inventari accurati della composizione del codice software.
Fonte: Rapporto EGS 2024
La creazione di SBOM accurati e completi, tuttavia, rappresenta una sfida sostanziale per le organizzazioni. Questi documenti richiedono un inventario meticoloso dei componenti software, con informazioni dettagliate sulle loro origini, versioni e interdipendenze. Senza SBOM precisi, le organizzazioni faticano a identificare, valutare e mitigare efficacemente i rischi insiti nella loro catena di fornitura del software.
Linee guida per la generazione di SBOM
OPSWAT SBOM automatizza la generazione di SBOM sia per il codice che per i container, migliorando la sicurezza e favorendo la conformità nella catena di fornitura del software.
- Identificare tutti i componenti e le dipendenze
Identificare accuratamente tutti i componenti software, comprese le librerie open-source e di terze parti, con le relative versioni e dipendenze. Questo costituisce la base per un robusto SBOM. - Valutare i rischi OSS
Valutare i rischi potenziali associati ai componenti OSS. Considerate fattori quali la conformità della licenza, le vulnerabilità della sicurezza e lo stato di manutenzione. Date la priorità ai componenti in base alla loro criticità per il software. - Scansione delle vulnerabilità OSS
Utilizzare strumenti di scansione delle vulnerabilità e di generazione di SBOM per identificare le vulnerabilità note all'interno dei componenti OSS. Dare priorità alle vulnerabilità in base alla loro gravità e all'impatto potenziale sul software.
Utilizzo di OPSWAT SBOM
OPSWAT SBOM automatizza la generazione di SBOM sia per il codice che per i container, migliorando la sicurezza e favorendo la conformità nella catena di fornitura del software.
Ecco come utilizzare OPSWAT SBOM per generare SBOM in modo efficace:
Fornendo un inventario di tutte le librerie e i componenti open-source utilizzati all'interno di un'applicazione, OPSWAT SBOM aiuta a gestire le vulnerabilità delle dipendenze nella catena di fornitura del software, consentendo agli utenti di identificare e correggere le vulnerabilità nelle applicazioni in modo efficiente.
Oltre a identificare le vulnerabilità, OPSWAT SBOM convalida le licenze associate a ciascun componente software. Ciò garantisce la conformità ai termini di licenza ed evita potenziali insidie legali. Per saperne di più sul ruolo cruciale del rilevamento delle licenze negli OSS.
OPSWAT SBOM supporta oltre 10 linguaggi di programmazione, tra cui Java, JavaScript, Go, PHP e Python. Questo ampio supporto garantisce un vulnerability detection completo in vari ecosistemi di sviluppo software.
Sanzioni in caso di non conformità
Le organizzazioni che non rispettano gli standard PCI DSS, compreso il requisito SBOM, possono incorrere in sanzioni finanziarie che vanno da 5.000 a 100.000 dollari al mese. Queste multe possono aumentare nel tempo se i problemi di conformità rimangono irrisolti.
Oltre alle sanzioni finanziarie, la non conformità agli standard PCI DSS può comportare notevoli problemi legali e operativi. Le conseguenze legali possono includere azioni legali, costi di difesa e risarcimenti sostanziali. Inoltre, la non conformità potrebbe innescare audit federali da parte di agenzie come la Federal Trade Commission (FTC), con conseguenti ulteriori sanzioni.
I prossimi passi per la conformità agli standard PCI DSS 4.0
L'integrazione di SBOM nel framework PCI DSS 4.0 rappresenta un passaggio fondamentale verso una catena di fornitura del software più sicura. Sfruttando strumenti avanzati come OPSWAT SBOM, le organizzazioni possono gestire efficacemente i rischi open-source, migliorare la conformità e proteggersi da costose violazioni dei dati.
L'utilizzo di SBOM non è più un'opzione, ma una necessità. Adottando misure proattive per comprendere e risolvere le dipendenze del software, le organizzazioni possono costruire una solida base di sicurezza che salvaguardi le loro operazioni e crei la fiducia dei clienti.
Migliorate la vostra sicurezza
Postura con OPSWAT
Iniziate subito a gestire le dipendenze di
open-source.
