Cyber Resilience Act: dove si trovano davvero le lacune

Il Cyber Resilience Act entrerà in piena applicazione l’11 dicembre 2027, ma il lavoro preparatorio decisivo si sta svolgendo ben prima di questa data. Un recente sondaggio riportato da heise online mostra che molte aziende non conoscono ancora a sufficienza i requisiti relativi agli obblighi di segnalazione e alle distinte base del software (SBOM). Per le funzioni di governance, rischio e conformità, la domanda non è più se il CRA sia rilevante, ma quali evidenze debbano effettivamente essere disponibili entro le prossime scadenze, e chi sia responsabile di fornirle.

A che punto è realmente l’industria con l’attuazione del CRA?

Secondo un sondaggio del fornitore di cybersicurezza ONEKEY, citato da heise online, il 45 percento delle aziende intervistate conosce poco o per nulla i requisiti del CRA.

Un secondo dato pesa maggiormente più a valle nella catena di fornitura: secondo lo stesso sondaggio, solo il 18 percento dei fornitori trasmette le informazioni CRA necessarie, sebbene i produttori restino responsabili anche per i componenti forniti da terzi. Il rischio reale risiede quindi meno nel reparto di sviluppo interno dell’azienda che nella catena dei fornitori a monte.

Ciononostante, secondo heise online, un terzo delle aziende dichiara di voler soddisfare tutti i requisiti entro la scadenza di dicembre 2027. In molti casi, permane un divario tra questa ambizione e una preparazione effettivamente documentata. Un’incertezza analoga riguardo all’effettivo ambito di applicazione emerge anche in relazione ad altre normative europee, come illustra l’articolo « NIS2-Registrierungslücke: Was sie über Scope-Unsicherheit zeigt ».

Quali scadenze intercorrono fino alla piena applicazione?

Il Cyber Resilience Act è entrato in vigore il 10 dicembre 2024, l’obbligo di segnalazione delle vulnerabilità e degli incidenti si applica dall’11 settembre 2026, e il regolamento entra in piena applicazione dall’11 dicembre 2027.

Il vero tempo di preparazione si colloca tra queste date. Le aziende che intendono rispettare l’obbligo di segnalazione a partire da settembre 2026 devono disporre, entro tale data, di una catena di rilevamento ed escalation funzionante, non di una semplice bozza. La piena conformità, incluso l’obbligo relativo alla SBOM, segue poco più di un anno dopo, ma i processi necessari non possono essere costruiti nelle ultime settimane prima della scadenza.

L’Ufficio federale tedesco per la sicurezza informatica (BSI) accompagna questo periodo transitorio con una linea guida tecnica che specifica i requisiti relativi a SBOM e segnalazioni, ma tale linea guida non sostituisce la valutazione dei rischi che ogni azienda deve condurre autonomamente.

Cosa richiede concretamente l’obbligo di segnalazione ai sensi dell’articolo 14 del CRA?

I produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti di sicurezza gravi all’autorità coordinatrice competente e a ENISA, con un’allerta precoce entro 24 ore e una notifica di follow-up entro 72 ore.

Entrambe le notifiche transitano attraverso la piattaforma di segnalazione unica prevista dal CRA, che le inoltra contemporaneamente al CSIRT coordinatore e a ENISA. Il conteggio del tempo inizia nel momento in cui il produttore viene a conoscenza del problema, non quando un reparto specializzato o un soggetto esterno lo conferma.

Per una funzione GRC, ciò significa che i percorsi di escalation entro il termine di 24 ore devono essere documentati per iscritto e testati prima della scadenza di settembre 2026. Quanto una simile catena di segnalazione dipenda da processi effettivamente collaudati, e non solo dalla tecnologia, è descritto nell’articolo « ISMS: Menschen, Prozesse und Technologie sind entscheidend ».

Quali evidenze mancano più spesso per la distinta base del software?

La SBOM fa parte della documentazione tecnica e deve coprire almeno le dipendenze software dirette, ma proprio queste informazioni mancano spesso alle aziende per quanto riguarda i componenti forniti da terzi.

Il CRA non impone un formato tecnico unico; nella pratica si sono affermati CycloneDX e SPDX. Ciò che conta non è tanto il formato quanto l’aggiornamento costante: una SBOM creata una sola volta perde rilevanza a ogni aggiornamento software e dovrebbe essere strettamente collegata ai processi di build e rilascio.

Il dato relativo ai fornitori si applica direttamente anche qui: senza informazioni affidabili provenienti dalla catena di fornitura, la SBOM di un’azienda rimane incompleta, indipendentemente da quanto sia ben organizzata la documentazione interna. Come sia possibile rilevare sistematicamente tali dipendenze da terzi è descritto nell’articolo « Was das Third-Party Cyber Risk Management von etablierten Sicherheitsfunktionen lernen kann ».

Quale primo passo può essere pianificato concretamente fin da ora?

Il prossimo passo verificabile è un inventario completo dei prodotti che registri, per ciascun prodotto, se esiste una SBOM leggibile automaticamente e quali fornitori devono ancora fornire le informazioni mancanti.

I responsabili della sicurezza o della conformità dovrebbero disporre, entro la scadenza dell’11 settembre 2026, di un processo di escalation documentato per le vulnerabilità attivamente sfruttate, comprensivo dell’accesso alla piattaforma di segnalazione e di un responsabile nominato per il rispetto del termine di 24 ore. Parallelamente, vale la pena fare un bilancio su quali prodotti e fornitori dispongano attualmente di dati SBOM leggibili automaticamente.

Poiché le segnalazioni CRA sono riferite al prodotto, mentre altri regimi come la NIS2 prevedono segnalazioni a livello organizzativo, vale la pena esaminare anche le interfacce tra i due obblighi, come illustra l’articolo « Cyber Resilienz neu denken im Kontext von NIS2 ». Le aziende che iniziano già ora questo bilancio hanno ancora tempo, prima della scadenza di settembre 2026, per effettuare un test della catena di segnalazione.