Cyber Resilience Act e SBOM: risposte brevi
Le domande che i fabbricanti pongono più spesso sul CRA, ciascuna con una risposta in poche frasi e la fonte ufficiale.
Che cos'è il Cyber Resilience Act e a chi si applica?
Il Cyber Resilience Act (CRA, regolamento sulla ciberresilienza) è il Regolamento (UE) 2024/2847, la norma UE sui requisiti di cibersicurezza per i prodotti con elementi digitali. Si applica all'hardware con software e ai prodotti software messi a disposizione sul mercato dell'UE, e i suoi obblighi ricadono soprattutto sui fabbricanti, indipendentemente dalle loro dimensioni. I settori con norme proprie, come i dispositivi medici, i veicoli a motore e l'aviazione civile, sono esclusi, e il puro software-as-a-service senza un prodotto in genere non vi rientra. Il regolamento è entrato in vigore il 10 dicembre 2024.
Gli obblighi di notifica del CRA nel dettaglio →
Fonte: Regolamento (UE) 2024/2847, EUR-Lex, Cyber Resilience Act, Commissione europea
Che cosa prevede l'obbligo di segnalazione del CRA?
Dall'11 settembre 2026 i fabbricanti devono segnalare ogni vulnerabilità attivamente sfruttata nel proprio prodotto e ogni incidente grave che ne compromette la sicurezza, anche per i prodotti già presenti sul mercato. Il preallarme va inviato entro 24 ore dal momento in cui se ne viene a conoscenza, la notifica entro 72 ore e la relazione finale entro 14 giorni dalla disponibilità di una correzione (vulnerabilità) o entro un mese dalla notifica (incidenti). Le segnalazioni passano dalla piattaforma unica di segnalazione dell'ENISA al CSIRT coordinatore e all'ENISA; la piattaforma non offre un'API ai fabbricanti, quindi ogni segnalazione viene inviata a mano nel browser.
Notifiche CRA: presupposti, termini, destinatari → Guarda: Il flusso di notifica CRA (4 min)
Fonte: Regolamento (UE) 2024/2847, articolo 14, EUR-Lex, ENISA
Come si crea una SBOM?
La generi automaticamente nella pipeline di build invece di scriverla a mano. Usi uno dei due formati leggibili da dispositivo automatico più diffusi, CycloneDX o SPDX, e crei una SBOM per ogni versione rilasciata. Esistono generatori per la maggior parte degli ecosistemi, ad esempio Syft o cdxgen per container e file system, i plugin CycloneDX per Maven, Gradle e npm e l'output SPDX del Yocto Project per Linux embedded.
- Scelga il formato. CycloneDX o SPDX: entrambi sono leggibili da dispositivo automatico.
- La generi nella CI. Esegua il generatore SBOM del suo ecosistema a ogni build di release.
- Conservi una SBOM per release. La archivi con la release come parte della documentazione tecnica.
- La confronti con i dati sulle vulnerabilità. Kernwatch controlla i componenti con identificativo di pacchetto (purl) ogni giorno nei piani a pagamento, ogni settimana nel piano Free.
SBOM per il CRA → Guarda: Prodotti, release e SBOM (4 min) Guarda: Caricare le SBOM dalla CI con una chiave API (2 min)
Fonte: CycloneDX, SPDX
Da quando la SBOM è obbligatoria secondo il CRA?
La SBOM rientra nei requisiti del CRA che si applicano dall'11 dicembre 2027: da quel momento i prodotti con elementi digitali necessitano della conformità al CRA e della marcatura CE per essere immessi sul mercato dell'UE. L'allegato I richiede una SBOM in un formato di uso comune e leggibile da dispositivo automatico, che copra almeno le dipendenze di primo livello. Fa parte della documentazione tecnica: non deve essere pubblicata, ma le autorità di vigilanza del mercato possono richiederla. Poiché le segnalazioni sono obbligatorie dall'11 settembre 2026, una SBOM aggiornata è anche il modo più rapido per capire se una vulnerabilità sfruttata riguarda i suoi prodotti.
Che cosa richiede il CRA a una SBOM →
Fonte: Regolamento (UE) 2024/2847, allegato I, EUR-Lex
Che cosa fa uno strumento per la segnalazione delle vulnerabilità CRA?
Trasforma i risultati del monitoraggio e le scadenze in attività. In Kernwatch un rilevamento presente in un elenco di vulnerabilità sfruttate attivamente diventa un'attività nell'inbox delle attività per aprire un caso di notifica, con scadenza 24 ore dal momento in cui ne è venuto a conoscenza, e il preallarme, la notifica e la relazione finale vengono redatti a partire dai dati su prodotto, release e valutazione per la sua approvazione. Lei invia la segnalazione sulla piattaforma dell'ENISA e registra il riferimento; quando una release più recente non contiene più la versione vulnerabile, Kernwatch propone la data della correzione da cui parte il termine di 14 giorni per la relazione finale. Le attività compaiono in tutti i piani; approvare casi di notifica e notifiche richiede Starter o superiore.
Piani e prezzi → Guarda: L'inbox delle attività (6 min)