Cyber Resilience Act e SBOM: cosa cambia per il software PMI

La distanza tra il testo di legge e la scrivania

Le PMI italiane credono che il Cyber Resilience Act riguardi grandi aziende tech o produttori di hardware industriale. Nella pratica, il perimetro è molto più largo di così.
Il regolamento europeo è entrato in vigore nel 2024 e il calendario degli obblighi scatta a partire dal 2027, con alcune scadenze intermedie già operative. Chi sviluppa o integra software con elementi digitali — firmware, applicazioni embedded, software venduto come prodotto — è già nel campo di applicazione. Aspettare non è una strategia: è solo rinviare un problema che nel frattempo cresce.
Questo articolo spiega cosa prevede concretamente il CRA per una PMI, cosa significa SBOM e perché non è solo burocrazia, e cosa ha senso fare adesso rispetto a cosa si può rimandare.

Chi è davvero coinvolto

Il Cyber Resilience Act si applica ai “prodotti con elementi digitali” immessi sul mercato UE. La definizione è intenzionalmente ampia.
Rientra nel perimetro qualsiasi software che ha una funzione propria e viene distribuito — non solo come servizio cloud (SaaS puro è escluso), ma come prodotto installabile, firmware, componente integrato in un dispositivo fisico, oppure software venduto separatamente con licenza. Un gestionale custom distribuito a clienti terzi, un’app embedded in una macchina industriale, un modulo software venduto come prodotto B2B: tutti potenzialmente inclusi.
Le PMI che producono software per uso interno esclusivo sono fuori. Quelle che lo vendono, lo licenziano o lo integrano in prodotti destinati al mercato UE sono dentro.
Ci sono due categorie: prodotti “default” (la maggior parte) e prodotti “critici” (elencati negli allegati, includono software di sicurezza, sistemi operativi industriali, componenti di rete). Per i prodotti critici gli obblighi sono più stringenti e richiedono valutazione di conformità da terze parti. Per i prodotti default, l’autocertificazione è sufficiente, ma gli obblighi sostanziali restano.

Cosa chiede il CRA, fuori dal gergo

Il regolamento introduce obblighi concreti che si possono raggruppare in tre aree.
Sicurezza by design. I prodotti devono essere progettati e sviluppati con la sicurezza integrata, non aggiunta dopo. Vuol dire gestione delle vulnerabilità nel ciclo di sviluppo, autenticazione predefinita sicura, superficie di attacco minima, aggiornamenti di sicurezza garantiti per tutta la vita del prodotto dichiarata.
Trasparenza sulla supply chain software. Qui entra la SBOM.
Gestione e notifica delle vulnerabilità. Chi scopre una vulnerabilità attivamente sfruttata nel proprio prodotto deve notificarla all’ENISA entro 24 ore dalla scoperta. Non è un termine lungo.
L’obbligo di notifica rapida è quello che spaventa di più le PMI, e a ragione: richiede processi interni che oggi quasi nessuna piccola software house ha formalizzato.

Cos’è la SBOM e perché non è solo un documento

SBOM sta per Software Bill of Materials: un inventario strutturato di tutti i componenti che compongono un prodotto software. Librerie open source, dipendenze di terze parti, versioni, licenze, origine.
L’analogia con la lista ingredienti di un alimento è corretta ma parziale. La SBOM serve soprattutto a rispondere a una domanda precisa: se domani viene scoperta una vulnerabilità critica in una libreria specifica, so in quanti e quali miei prodotti quella libreria è presente?
Senza SBOM, la risposta richiede settimane di analisi manuale. Con una SBOM aggiornata, richiede una query.
Per le PMI che sviluppano software custom, la SBOM è spesso la parte più sottovalutata del CRA. Si tende a pensare che basti “sapere cosa si usa”. Ma la realtà di un progetto software moderno è che le dipendenze dirette sono poche decine, mentre quelle transitive — le dipendenze delle dipendenze — possono essere centinaia. Un progetto Laravel medio porta con sé facilmente 150-300 pacchetti Composer. Quanti di questi hanno avuto CVE critici nell’ultimo anno?
Gli strumenti per generare SBOM automaticamente esistono e sono maturi: Syft, CycloneDX, SPDX sono i formati standard riconosciuti anche dalla normativa. Il problema non è lo strumento, è integrarlo nel processo di build e tenerlo aggiornato a ogni rilascio.
Se stai costruendo software che finirà sul mercato UE e non hai ancora un processo di dependency tracking, questo è il primo punto da sistemare — prima ancora di leggere il resto del regolamento.
Parla con noi di come strutturare il tuo processo di sviluppo

Cosa conviene fare adesso

Le scadenze formali danno ancora qualche mese di margine, però il tempo per costruire i processi è adesso. Aspettare il 2027 per cominciare significa trovarsi a certificare in fretta quello che si doveva costruire con calma.
Tre cose concrete da fare entro fine 2026:

1. Mappare il perimetro. Quali prodotti software distribuisci o vendi? Rientrano nella definizione CRA? Sono nella categoria default o critica? Questa analisi non richiede un consulente legale: richiede onestà su cosa fa il tuo software e a chi lo vendi.
2. Avviare la generazione automatica di SBOM. Integrare Syft o uno strumento equivalente nella pipeline CI/CD non è un progetto lungo. È qualche giorno di lavoro per un developer. Il risultato è un file CycloneDX o SPDX generato a ogni build, che diventa la base della tua documentazione di conformità.
3. Definire un processo minimo di vulnerability management. Chi monitora i CVE sulle dipendenze? Con quale frequenza? Chi decide se e quando rilasciare una patch? Se queste domande non hanno una risposta scritta, il processo non esiste.

La compliance digitale PMI nel 2026 non si risolve comprando uno strumento. Si costruisce formalizzando pratiche che i team più attenti già seguono informalmente.

Cosa si può rimandare (e cosa è overhyped)

Non tutto il rumore intorno al CRA merita attenzione immediata.
La valutazione di conformità di terze parti riguarda solo i prodotti critici. Se il tuo software non è in quegli elenchi, l’autocertificazione basta. Non serve ingaggiare un ente notificato adesso.
Il dibattito sul “CRA che uccide l’open source” è ampiamente sopravvalutato. Il regolamento esclude esplicitamente il software open source sviluppato e distribuito senza scopo commerciale. Chi mantiene librerie open source come parte di un’attività commerciale è coinvolto, ma le linee guida interpretative della Commissione hanno chiarito i confini meglio di quanto i titoli allarmistici facessero intendere.
L’obbligo di marcatura CE per i prodotti digitali arriva con le scadenze più lontane. È reale, ma non è il primo problema da risolvere.
La nostra opinione netta: il CRA è una normativa ben costruita che risolve un problema reale — la supply chain software è il vettore di attacco più sottovalutato delle PMI manifatturiere italiane. Chi si lamenta degli obblighi di trasparenza spesso non vuole che si sappia quanto sia fragile la base su cui ha costruito i suoi prodotti. La compliance, in questo caso, è un’occasione per fare ordine in casa.

Il punto di partenza pratico

Il Cyber Resilience Act non è un problema di grandi aziende rimandato alle PMI per burocrazia europea. È una risposta a un problema concreto: software distribuito senza sapere cosa contiene, vulnerabilità scoperte mesi dopo l’attacco, catene di dipendenze opache.
Per una PMI che sviluppa software, il punto di partenza non è la certificazione. È capire cosa distribuisce, cosa c’è dentro, e avere un processo per rispondere quando qualcosa va storto.
Chi parte adesso ha il tempo di farlo bene. Chi aspetta il 2027 lo farà in fretta e male.
Se stai valutando come adeguare il tuo processo di sviluppo agli obblighi del CRA — dalla SBOM alla gestione delle vulnerabilità — raccontaci il tuo caso e vediamo insieme da dove partire.