Cyber Resilience Act e software supply chain: la sicurezza entra nella pipeline

L'11 settembre 2026 è entrata in applicazione la prima parte operativa del Cyber Resilience Act (CRA), il Regolamento (UE) 2024/2847 sulla sicurezza dei prodotti con elementi digitali. Da quel giorno i produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i loro prodotti. Il resto del regolamento, con i requisiti essenziali di sicurezza e la marcatura CE, si applicherà dall'11 dicembre 2027.

Essendo un regolamento, il CRA non ha bisogno di leggi di recepimento: vale direttamente in tutti gli Stati membri.

Cosa cambia da settembre 2026

Quando un produttore viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, deve rispettare tre scadenze:

• 24 ore per un preallarme;
• 72 ore per la notifica completa, con le misure correttive o di mitigazione adottate;
• 14 giorni per il rapporto finale, dopo che la correzione è disponibile (per gli incidenti, un mese).

Le segnalazioni passano dalla piattaforma unica gestita da ENISA e arrivano al CSIRT nazionale competente. Un dettaglio che molte aziende sottovalutano: l'obbligo vale anche per i prodotti già sul mercato, non solo per quelli nuovi.

Chi riguarda

Il CRA si applica ai prodotti con elementi digitali immessi sul mercato europeo: software installabile, applicazioni, firmware, dispositivi connessi e i componenti software venduti come prodotto. I servizi SaaS puri in genere ne sono esclusi e ricadono piuttosto sotto la direttiva NIS2. Rientrano però nel CRA le soluzioni di elaborazione dati da remoto necessarie al funzionamento di un prodotto, come il backend di un'app o di un dispositivo.

Capire con precisione se e quali prodotti sono coinvolti è il primo passo. In caso di dubbio la valutazione va fatta con un consulente legale, perché le conseguenze di una classificazione sbagliata sono concrete.

Il vero punto debole: le dipendenze

Per rispettare una scadenza di 24 ore bisogna rispondere in pochi minuti a una domanda semplice: questa vulnerabilità è presente nel nostro prodotto?

Nella maggior parte del software moderno il codice scritto da zero è una piccola parte del totale. Il resto è fatto di librerie open source, che a loro volta dipendono da altre librerie. È lì che si concentrano molti dei rischi, compresi gli attacchi alla supply chain, cioè pacchetti compromessi pubblicati apposta per infiltrarsi nei progetti di altri.

Senza un inventario aggiornato, rispondere richiede giorni. Con un inventario automatico, basta una query.

Come si traduce in pratica nella pipeline

SBOM generato a ogni build

Il Software Bill of Materials è l'elenco dei componenti di un prodotto, con versioni e hash di integrità. Il CRA chiede ai produttori di redigerlo come parte della documentazione tecnica. Generarlo automaticamente a ogni build, in formati standard come CycloneDX o SPDX, significa averlo sempre allineato a ciò che è davvero in produzione.

Controllo delle dipendenze prima del merge

La pipeline CI blocca le pull request che introducono pacchetti con vulnerabilità note (CVE), librerie abbandonate o licenze incompatibili con l'uso commerciale. Il problema viene fermato prima di arrivare in produzione, non scoperto dopo.

Monitoraggio continuo

Una libreria sicura oggi può avere una CVE pubblicata domani. Confrontare periodicamente gli SBOM dei prodotti rilasciati con i database di vulnerabilità permette di accorgersene subito.

Una policy di divulgazione coordinata (CVD)

Il CRA richiede un canale chiaro attraverso cui ricercatori e utenti possano segnalare vulnerabilità, e un processo interno definito: chi valuta la segnalazione, chi decide se è da notificare, chi prepara e distribuisce la correzione. Quando il tempo a disposizione è di 24 ore, questo processo va scritto e provato prima di averne bisogno.

Non solo adempimento

Tutto questo ha un costo, ma porta benefici che vanno oltre la conformità. Chi sa esattamente cosa c'è nel proprio software reagisce più in fretta a ogni incidente, aggiorna le dipendenze con meno paura e può dimostrare ai clienti, in modo documentato, come gestisce la sicurezza. Nelle gare e nei contratti B2B è sempre più spesso un requisito esplicito.

Come lavoriamo

Nei progetti che sviluppiamo integriamo la generazione degli SBOM e il controllo delle dipendenze direttamente nella pipeline CI/CD, così la sicurezza diventa un controllo automatico e non un'attività straordinaria prima del rilascio. Per i prodotti esistenti partiamo da un audit: inventario dei componenti, vulnerabilità note, licenze e un piano di intervento in ordine di priorità.

Vuoi sapere se il tuo software è pronto per il Cyber Resilience Act? Richiedi un audit.

---

Questo articolo ha scopo informativo e non costituisce consulenza legale.