La scadenza di 24 ore del CRA sta cambiando la visibilità della catena di fornitura del software.

      TL;DRA partire dall'11 settembre, il Regolamento dell'UE sulla Resilienza Cibernetica richiederà ai produttori di notificare le autorità di regolamentazione entro 24 ore dalla scoperta che una vulnerabilità nel loro prodotto è attivamente sfruttata. Per le aziende i cui prodotti contengono software di più fornitori, il collo di bottiglia non è avere un SBOM, ma sapere se riflette accuratamente il codice sottostante. Aaron Branson di FossID sostiene che l'analisi del codice sorgente fornisce il livello di verifica che trasforma i documenti SBOM in informazioni affidabili sulla catena di fornitura.

      Secondo un'analisi pubblicata da The Hacker News, i produttori di prodotti con elementi digitali venduti nell'Unione Europea affronteranno una scadenza dell'11 settembre ai sensi del Regolamento sulla Resilienza Cibernetica (CRA) per notificare le autorità di regolamentazione entro 24 ore dopo aver appreso che una vulnerabilità è attivamente sfruttata, con un rapporto più completo previsto entro 72 ore. Per i dirigenti della produzione, la finestra di 24 ore potrebbe portare maggiore attenzione alla visibilità della catena di fornitura del software. Prodotti complessi possono contenere software proprietario, applicazioni sviluppate dai fornitori, pacchetti commerciali, software per microcontrollori e librerie open-source, con dipendenze che si estendono su più livelli. Un produttore può mantenere numerosi rapporti con i fornitori pur avendo una visibilità limitata sul software incorporato nei singoli componenti.

      Ai sensi del CRA, il prodotto pertinente può comprendere il prodotto finito completo, creando la necessità di connettere informazioni da numerosi fornitori in un inventario software coerente. I produttori di automobili, dispositivi medici, aerospaziali e elettronica di consumo possono affrontare versioni particolarmente intricate di questa sfida.

      Le Software Bills of Materials, o SBOM, forniscono una base importante per organizzare tali informazioni. Secondo IBM, un SBOM fornisce un inventario leggibile dalla macchina di componenti software, librerie, moduli e dipendenze, aiutando le organizzazioni a comprendere il software incluso in prodotti e sistemi. IBM descrive anche un'adozione più ampia delle pratiche SBOM attraverso i settori poiché i requisiti normativi e le preoccupazioni sulla catena di fornitura del software si sono ampliati. Tuttavia, per i grandi produttori, i file dei fornitori possono arrivare in formati diversi e con livelli di dettaglio variabili. Una raccolta di documenti può quindi diventare difficile da riconciliare a livello di prodotto, in particolare quando il software sottostante cambia dopo che è stato prodotto un SBOM.

      Quella distinzione potrebbe diventare particolarmente importante quando la segnalazione delle vulnerabilità è sensibile al tempo. L'analisi di The Hacker News sul CRA sostiene che le organizzazioni potrebbero trovare la richiesta dell'11 settembre più impegnativa quando non possono stabilire rapidamente quale software è presente in un particolare prodotto o quando una vulnerabilità è stata conosciuta per la prima volta. Un foglio di calcolo o un archivio email possono documentare la composizione del software in un dato momento, mentre rilasci successivi, patch, cambiamenti di dipendenza o componenti recentemente identificati possono alterare il quadro.

      Credito: Aaron Branson

      Questo è l'ambiente in cui FossID, un'azienda di analisi della composizione del software focalizzata sull'intelligenza del codice sorgente e sulla trasparenza della catena di fornitura del software, ha sviluppato il suo ruolo. Il Chief Growth Officer Aaron Branson vede la questione sottostante attraverso l'affidabilità delle informazioni che raggiungono i produttori. “Un SBOM è utile solo quanto la fiducia che un'organizzazione può riporre nelle informazioni al suo interno,” afferma. “Per le aziende che ricevono software da numerosi fornitori, quella fiducia richiede un ulteriore livello di esame nel punto in cui le informazioni del fornitore entrano nell'azienda.”

      L'analisi del codice sorgente mira a fornire quel livello esaminando il software stesso per identificare componenti, dipendenze, licenze e vulnerabilità. La tecnologia di FossID può scansionare il codice e identificare componenti open-source e di terze parti, inclusi frammenti di codice più piccoli e dipendenze che potrebbero essere difficili da stabilire solo dalle informazioni sui pacchetti dichiarati. Secondo Branson, questo crea una distinzione importante tra ricevere un SBOM e esaminare se l'SBOM corrisponde al software sottostante.

      La relazione con il fornitore può aggiungere un ulteriore livello alla sfida della visibilità. Per i grandi produttori, l'utilità di un SBOM può dipendere in parte dal fatto che le informazioni provenienti da diversi fornitori possano essere valutate in modo coerente e portate in un registro comune. Questa è un'area in cui l'analisi della composizione del software può svolgere un ruolo più ampio. Le informazioni fornite dai fornitori possono essere esaminate rispetto al software stesso, aiutando a distinguere un documento che è stato presentato da informazioni che sono state sufficientemente validate.

      Branson sostiene che questa distinzione potrebbe diventare sempre più importante man mano che la responsabilità normativa si estende attraverso catene complesse di dipendenze software. Il lavoro di FossID si inserisce in uno sforzo più ampio per rendere le informazioni software dei fornitori più utilizzabili per i team di ingegneria, sicurezza e conformità responsabili del prodotto finito.

      La complessità può aumentare quando il software di un fornitore contiene dipendenze da fornitori aggiuntivi e progetti open-source. Un produttore può ricevere informazioni su un componente senza avere lo stesso livello di visibilità sul software sottostante. Questo può creare una domanda più ampia su come i produttori possano stabilire fiducia nelle informazioni software che provengono al di fuori dei propri team di ingegneria.

      “Il nostro lavoro nell'analisi del codice sorgente è rilevante per quella domanda perché esamina la composizione del software a livello di codice, fornendo un altro mezzo per valutare le informazioni fornite attraverso l'ecosistema più ampio,” spiega Branson. “Ma la questione più grande è che i produttori potrebbero aver bisogno di processi che consentano di verificare le informazioni software attraverso più livelli di responsabilità.” Secondo Branson, FossID ha discusso questa sfida più ampia con analisti del settore mentre le organizzazioni passano dal semplice generare SBOM a incorporarli nei processi di catena di fornitura del software in corso.

      Katie Norton, Senior Research Manager di IDC, vede la flessibilità come una parte importante di quella transizione. “Man mano che le aziende operazionalizzano gli SBOM, hanno bisogno di processi che possano adattarsi alle differenze tra fornitori, requisiti normativi e revisione interna,” afferma Norton. “La sfida è supportare quelle variazioni senza imporre lo stesso flusso di lavoro a ogni organizzazione.”

      Branson vede questo come un cambiamento nello scopo della gestione degli SBOM stessa. “La domanda sta passando da ‘Abbiamo un SBOM?’ a ‘Possiamo verificare continuamente la catena di fornitura del software che l'SBOM rappresenta?’” afferma. Quella distinzione colloca l'analisi della composizione del software all'interno di un processo operativo più ampio che coinvolge ingegneria, sicurezza, approvvigionamento e team normativi. Un SBOM può servire come registro, mentre l'analisi del codice sorgente può fornire un mezzo per testare quel registro rispetto al software da cui è stato derivato.

      In ultima analisi, il requisito dell'11 settembre potrebbe rappresentare una pietra miliare iniziale in una più ampia evoluzione della governance del software. The Hacker News osserva che gli obblighi di reporting del CRA arrivano prima dei requisiti di ingegneria più ampi della regolamentazione, che dovrebbero entrare in vigore a dicembre 2027. Questa sequenza potrebbe dare ai produttori l'opportunità di esaminare i sistemi che supportano l'identificazione delle vulnerabilità, le informazioni sui fornitori e la visibilità del software a livello di prodotto.

      Man mano che i prodotti connessi incorporano software da catene di fornitura sempre più complesse, la prontezza normativa potrebbe dipendere sempre più dalla qualità e dalla tempestività delle informazioni dietro l'inventario software di un'organizzazione. La sfida emergente potrebbe riguardare più il mantenimento di una comprensione affidabile del software che rimane connesso a un prodotto per tutto il suo ciclo di vita.