Cyber Resilience Act: portare gli obblighi nello sviluppo del prodotto

Il Cyber Resilience Act, il regolamento europeo sulla ciberresilienza, porta gli obblighi di cybersecurity all'interno del ciclo di vita dei prodotti con elementi digitali che rientrano nel suo ambito. Per un CTO, il compito pratico è collegare ciò che il team di engineering sviluppa, rilascia e mantiene con le evidenze necessarie a dimostrare il rispetto di tali obblighi.

Questo collegamento deve funzionare a livello di prodotto e di versione. Una policy di sicurezza aziendale non spiega se una determinata release ha impostazioni predefinite sicure, quali dipendenze contiene o come i clienti riceveranno un aggiornamento di sicurezza. Un ticket di vulnerabilità contrassegnato come "risolto" non stabilisce quali versioni supportate restino esposte.

Il punto di partenza utile è quindi un modello del ciclo di vita del prodotto: ambito, requisiti di sicurezza, evidenze di rilascio, gestione delle vulnerabilità, impegni di supporto e decisioni con responsabili chiari. Integrate questo modello nello sviluppo anziché assemblarlo separatamente prima di una valutazione.

Definire il confine del prodotto prima di assegnare i controlli

Il CRA riguarda i prodotti con elementi digitali che rientrano nel suo ambito di applicazione, compresi hardware e software interessati. Non è una regola universale per ogni servizio SaaS. Un servizio ospitato e un software distribuito ai clienti possono richiedere analisi diverse, e va esaminata anche l'elaborazione da remoto che è parte integrante di un prodotto.

Utilizzate le indicazioni della Commissione europea sul CRA come riferimento di partenza, poi risolvete le questioni giuridiche specifiche del prodotto. Registrate la conclusione anziché affidarvi a un'ipotesi informale del team.

Per ogni prodotto candidato, stabilite:

• Che cosa ricevono i clienti: hardware, software installato, componenti scaricabili o una combinazione.
• Quali funzioni di elaborazione da remoto sono necessarie perché il prodotto svolga le proprie funzioni.
• Come il prodotto viene messo a disposizione sul mercato dell'UE e quale soggetto lo fornisce.
• Il vostro ruolo di operatore economico: fabbricante, importatore, distributore o un altro ruolo pertinente.
• Esclusioni applicabili, normativa specifica di prodotto e considerazioni sull'open source.
• La categoria del prodotto e i conseguenti requisiti di valutazione della conformità.

L'open source richiede particolare attenzione. Il trattamento del software fornito al di fuori di un'attività commerciale non significa che un fabbricante commerciale possa ignorare i componenti open source integrati nel proprio prodotto. Distinguete la posizione del contributore upstream dalla vostra responsabilità per il prodotto che fornite.

Il deliverable tecnico dovrebbe essere una breve registrazione dell'ambito con un diagramma dell'architettura, gli identificativi del prodotto, i soggetti commerciali pertinenti, le ipotesi e una conclusione approvata. Indicate la persona responsabile di riaprire tale conclusione quando cambiano le funzionalità o la distribuzione.

Ad esempio, un'applicazione di gestione scaricabile e il relativo servizio di analisi ospitato non dovrebbero ricevere automaticamente un'unica decisione indifferenziata sull'ambito. Individuate quali funzioni operano in locale, quali dipendono dal servizio e se quell'elaborazione da remoto rientri nel confine del prodotto. Questa distinzione incide sulla valutazione del rischio, sulle registrazioni delle dipendenze e sulla responsabilità per gli incidenti.

Lavorare in base alle date di attuazione aggiornate

La Commissione indica l'11 settembre 2026 per gli obblighi di notifica e l'11 dicembre 2027 per i principali requisiti del CRA. Al 7 ottobre 2026, la data per le notifiche è già trascorsa. Trattate la prontezza alla notifica come un requisito operativo attuale, non come un compito da rinviare alla preparazione della conformità.

Mantenete visibili due filoni di lavoro:

I prodotti forniti prima della data di applicazione principale richiedono attenzione alle disposizioni transitorie e alle modifiche sostanziali. Non date per scontato che un prodotto più vecchio sia irrilevante ai fini delle notifiche solo perché la sua release originale è precedente al dicembre 2027.

Mantenete un registro datato dei requisiti giuridici. Per soglie degli eventi, termini di notifica a più fasi, destinatari e procedure di trasmissione, verificate il testo giuridico vigente e le indicazioni ufficiali di attuazione. Non sostituite il processo specifico del CRA con un modello generico di risposta agli incidenti.

Tradurre i requisiti di sicurezza in criteri di progettazione e di rilascio

I requisiti essenziali del CRA riguardano le proprietà di sicurezza del prodotto e la gestione delle vulnerabilità. La loro implementazione dovrebbe seguire la valutazione dei rischi di cybersecurity del prodotto, anziché una checklist universale applicata senza contesto architetturale.

Partite da come il prodotto può causare danni. Descrivete utenti, ambienti di deployment, interfacce esposte, operazioni privilegiate, dati sensibili e usi impropri prevedibili. Includete le ipotesi operative del cliente: un'appliance installata in una rete industriale ha vincoli di esposizione e di ripristino diversi da un'utility desktop.

Un esercizio pratico di threat modeling può supportare questo lavoro; la guida di OWASP al threat modeling offre un approccio consolidato. L'output dovrebbe collegare le minacce a requisiti, decisioni di implementazione e test specifici.

Ecco come requisiti familiari diventano verificabili:

Si tratta di esempi pratici di implementazione, non di un sostituto dei requisiti applicabili. Determinatene pertinenza e sufficienza attraverso la valutazione del rischio.

Aggiungete criteri di accettazione di sicurezza allo sviluppo delle funzionalità. Una nuova API amministrativa dovrebbe arrivare con decisioni su autenticazione, autorizzazione, gestione degli input e logging, non con la promessa che la sicurezza la esaminerà più avanti. Rivedete il modello delle minacce quando aggiungete un'interfaccia remota, un componente privilegiato o un nuovo confine di fiducia.

L'approvazione del rilascio dovrebbe individuare le vulnerabilità irrisolte, la loro sfruttabilità, le configurazioni interessate e il trattamento. Applicate il requisito del CRA di mettere i prodotti a disposizione sul mercato senza vulnerabilità sfruttabili note, tenendo conto della valutazione del rischio e dei requisiti essenziali applicabili; registrare o accettare un rischio non basta di per sé a soddisfare tale requisito. Il risultato di uno scanner da solo non può prendere questa decisione: contano raggiungibilità, prerequisiti e comportamento del prodotto. Al contrario, un punteggio di gravità numericamente basso non è un motivo sufficiente per trascurare una vulnerabilità che ha conseguenze rilevanti nel vostro modello di deployment.

La registrazione del rilascio dovrebbe collegare la revisione del codice sorgente approvata, l'artefatto di build, l'inventario delle dipendenze, i risultati dei test e la decisione di sicurezza. In questo modo la valutazione è riproducibile quando un cliente o un'autorità chiede in seguito informazioni su una versione specifica.

Rendere la due diligence sui componenti parte del processo di build

I componenti di terze parti creano obblighi che non si assolvono inoltrando un avviso di sicurezza upstream. Dovete capire che cosa avete rilasciato, se ne è interessato e come potete porvi rimedio.

Il CRA prevede, tra i requisiti relativi alla gestione delle vulnerabilità, una distinta base del software (SBOM): in un formato di uso comune e leggibile meccanicamente, che copra almeno le dipendenze di primo livello. Come raccomandazione pratica, raccogliete informazioni più approfondite sulle dipendenze ovunque i vostri strumenti di build possano produrre risultati affidabili. Spesso sono le dipendenze transitive a determinare l'esposizione.

Una SBOM è utile solo se corrisponde a un artefatto di prodotto reale. Associatela all'identificativo della release e alla build e distinguete i componenti rilasciati dagli strumenti usati solo in sviluppo. Includete, ove pertinenti, firmware, pacchetti del sistema operativo, librerie incluse e componenti commerciali; un'esportazione del package manager può non coglierne diversi.

Impostate la revisione dei componenti attorno a domande che cambiano le decisioni tecniche:

• Il componente è manutenuto e la sua durata di supporto è compatibile con la nostra?
• Possiamo ottenere tempestivamente informazioni sulle vulnerabilità e aggiornamenti di sicurezza?
• Abbiamo accesso al codice sorgente, un canale di patch del fornitore o una strategia di sostituzione?
• Il componente introduce esecuzione privilegiata o una nuova connessione esterna?
• Il prodotto può ancora essere manutenuto se il fornitore smette di supportarlo?

Per i componenti commerciali, l'ufficio acquisti dovrebbe stabilire contatti di sicurezza, modalità di notifica e accesso alle correzioni. I tempi del fornitore devono lasciare spazio alla vostra valutazione e ai vostri obblighi di notifica. Il fabbricante del prodotto ha comunque bisogno di un percorso di escalation interno quando la risposta di un fornitore è incompleta.

Per le dipendenze open source, conservate la provenienza e un piano di manutenzione realistico. Il fatto che un repository sia pubblicamente accessibile non dimostra che qualcuno produrrà una patch compatibile durante il vostro periodo di supporto.

Progettare insieme periodo di supporto e meccanismo di aggiornamento

Il supporto è un impegno tecnico con conseguenze commerciali. Il CRA richiede in generale un periodo di supporto di almeno cinque anni, salvo che il periodo di utilizzo previsto del prodotto sia più breve. Determinate il periodo applicabile utilizzando i criteri del regolamento anziché scegliere una data arbitraria che si adatti alla roadmap.

Registrate la motivazione, comunicate ai clienti le informazioni di supporto richieste e collegatele alle versioni di prodotto manutenute. L'impegno di supporto deve tenere conto della capacità di fornire aggiornamenti di sicurezza, non limitarsi a mantenere un indirizzo dell'helpdesk.

Prima di approvare il piano di supporto di un prodotto, chiedetevi se siete in grado di:

• Ricompilare i rami supportati più vecchi con toolchain manutenute.
• Produrre, autenticare e distribuire in modo sicuro gli aggiornamenti di sicurezza.
• Testare le correzioni su tutte le configurazioni hardware e di deployment supportate.
• Gestire le chiavi di firma e ripristinare la situazione in modo sicuro in caso di compromissione di una chiave.
• Mantenere disponibili per i clienti le informazioni sugli aggiornamenti e sulla sicurezza.
• Gestire le dipendenze il cui supporto upstream termina prima del vostro.

Gli aggiornamenti di sicurezza vanno in generale forniti gratuitamente durante il periodo di supporto, fatte salve le disposizioni del regolamento. Ogni aggiornamento di sicurezza rilasciato in quel periodo deve restare disponibile per almeno dieci anni dal rilascio o per il resto del periodo di supporto, se più lungo. Pianificate le correzioni di sicurezza separatamente dallo sviluppo delle funzionalità, così che i clienti non siano costretti senza necessità ad accettare modifiche funzionali non correlate.

Testate più del solo percorso ideale. Un'installazione interrotta, spazio di archiviazione insufficiente, credenziali scadute e una verifica fallita possono trasformare una patch valida in un problema di disponibilità. Decidete quali meccanismi di ripristino siano necessari per il profilo di rischio del prodotto.

Alla fine del supporto, comunicazione ai clienti e registrazioni interne devono concordare. Non lasciate una pagina di download che lascia intendere una manutenzione di sicurezza continuativa quando il registro dei prodotti indica che l'impegno è terminato.

Costruire un runbook di notifica che regga all'incertezza

Una normale vulnerabilità rilevata, una vulnerabilità attivamente sfruttata e un incidente grave non sono intercambiabili. Il processo di notifica del CRA richiede una valutazione documentata dell'evento scatenante pertinente: né la notifica automatica di ogni alert dello scanner, né l'archiviazione automatica di qualsiasi evento in assenza di un'indagine forense completata.

Il runbook dovrebbe partire dalla ricezione delle segnalazioni. Ricercatori, assistenza clienti, fornitori e team di engineering hanno bisogno di un canale noto verso la funzione di sicurezza del prodotto. Conservate la segnalazione originale e registrate quando le informazioni pertinenti sono diventate note; non azzerate i timestamp di conoscenza quando un ticket passa a un altro team.

Per gli eventi potenzialmente soggetti a notifica, raccogliete:

• Identificativi del prodotto e versioni supportate interessate.
• Evidenze dello sfruttamento o dell'impatto dell'incidente, con grado di confidenza e incertezze.
• Condizioni di attacco note, funzioni interessate e ipotesi sul deployment.
• Mitigazioni disponibili e stato delle misure correttive.
• La valutazione dell'evento scatenante, il responsabile della notifica e il calcolo dei termini applicabili.
• Notifiche trasmesse, conferme di ricezione, aggiornamenti successivi e comunicazioni ai clienti.

Verificate su fonti ufficiali i termini di notifica a più fasi, i requisiti della relazione finale, i destinatari e la procedura di notifica vigente. Le vulnerabilità attivamente sfruttate e gli incidenti gravi hanno dettagli di notifica distinti; un unico campo con una scadenza copiata non basta.

Nominate un responsabile principale della notifica e un sostituto con l'autorità di coordinare engineering, ufficio legale e comunicazione ai clienti. Predisponete in anticipo l'accesso al meccanismo di notifica applicabile. La revisione legale dovrebbe essere disponibile entro la finestra di notifica anziché diventare una coda di approvazione senza limiti di tempo.

Esercitatevi con informazioni incomplete. Una simulazione utile parte da una segnalazione di sfruttamento credibile, da un elenco incerto delle versioni interessate e da un fornitore di componenti irraggiungibile. Il team dovrebbe essere in grado di prendere una decisione di notifica tempestiva e documentata mentre l'indagine prosegue.

La notifica ai sensi del CRA non sostituisce altri obblighi applicabili. Un evento relativo a un prodotto può richiedere anche una valutazione ai sensi della normativa sulla protezione dei dati o di un contratto con un cliente. Coordinate queste valutazioni, ma mantenetene distinti eventi scatenanti, destinatari e registrazioni delle decisioni.

Confermare la classificazione prima di scegliere il piano di valutazione

La classificazione del prodotto incide sul percorso di valutazione della conformità disponibile. Non date per scontato che ogni prodotto connesso richieda la stessa valutazione esterna, né che ogni fabbricante possa ricorrere alla valutazione interna.

Determinate la categoria applicabile in base alle funzioni del prodotto e alle definizioni e agli allegati del regolamento. Confermate poi il percorso consentito, comprese eventuali condizioni relative a norme armonizzate, specifiche riconosciute, sistemi di certificazione o valutazione da parte di terzi.

La pianificazione relativa alle norme richiede un registro esplicito delle dipendenze: quali riferimenti sono applicabili, qual è il loro stato attuale e che cosa cambia se un percorso previsto non è disponibile. Evitate che il piano di rilascio dipenda da un'ipotesi non confermata sulle norme o sulla capacità di valutazione.

Rivedete la classificazione quando cambiano le funzionalità. L'aggiunta di funzioni di gestione della sicurezza o di controllo della rete può incidere sull'analisi, ma il nome di una funzionalità da solo non determina una categoria. Valutate la funzione effettiva e documentate la conclusione.

Mantenete classificazione, percorso scelto e deliverable di conformità collegati alla documentazione tecnica. La marcatura CE e la dichiarazione di conformità devono seguire il processo applicabile; non sostituiscono l'implementazione dei requisiti sottostanti.

Mantenere un pacchetto di evidenze in grado di spiegare un rilascio

La documentazione tecnica dovrebbe descrivere sia il prodotto sia il ragionamento alla base delle sue decisioni di sicurezza. Conservate valutazioni del rischio e documentazione man mano che il prodotto cambia e applicate alle registrazioni pertinenti gli obblighi di conservazione previsti dalla legge.

Un pacchetto di evidenze di prodotto utile comprende la decisione sull'ambito, l'architettura, la valutazione del rischio, i requisiti di sicurezza, le informazioni sui componenti, i risultati delle verifiche, le procedure di gestione delle vulnerabilità, la motivazione del periodo di supporto e le registrazioni sulla conformità. Ogni elemento ha bisogno di un responsabile e di una versione identificabile.

Usate identificativi stabili per collegare queste registrazioni. Una registrazione di vulnerabilità dovrebbe spiegare versioni interessate, esposizione, trattamento, release e comunicazioni richieste. "Risolto" senza il contesto della versione lascia incompleta l'evidenza di prodotto.

I processi esistenti del SGSI possono fornire evidenze utili su governance, fornitori e sviluppo sicuro. Tuttavia, la ISO 27001 riguarda un sistema di gestione della sicurezza delle informazioni con un perimetro definito; la certificazione non dimostra la conformità al CRA di un singolo prodotto. Riutilizzate le evidenze pertinenti senza trattare le mappature tra framework come un'equivalenza giuridica.

Esempio pratico: una vulnerabilità in una dipendenza di un'appliance supportata

Consideriamo, a titolo illustrativo, un fabbricante che fornisce nell'UE un'appliance connessa in rete. Supponiamo che ambito e classificazione siano stati esaminati, che due rami di release restino supportati e che una libreria inclusa risulti attivamente sfruttata altrove.

Il primo compito non è chiudere l'advisory upstream. Il team di engineering individua quali build dell'appliance contengono la libreria vulnerabile e se la funzione interessata è raggiungibile. La SBOM suggerisce che entrambi i rami la contengono, ma l'analisi della configurazione mostra un'esposizione diversa. Questa distinzione viene registrata con le evidenze a supporto.

Il responsabile della sicurezza del prodotto valuta poi se i fatti disponibili soddisfino l'evento scatenante della notifica previsto dal CRA. L'incertezza su una configurazione di deployment viene registrata, ma non giustifica il fatto di lasciare senza nome il responsabile della decisione. Il runbook di notifica fornisce le fasi di notifica e la procedura vigenti.

Il team di engineering sviluppa una mitigazione temporanea e una build corretta per ogni ramo interessato. I test coprono il percorso vulnerabile, il funzionamento normale e l'installazione autenticata dell'aggiornamento. Se un ramo non può usare la patch upstream, il team registra il trattamento alternativo e il rischio residuo anziché segnare l'intero prodotto come corretto.

La comunicazione ai clienti indica le versioni interessate, le azioni di protezione immediate e come ottenere l'aggiornamento. I tempi della divulgazione sono coordinati con i requisiti applicabili di gestione delle vulnerabilità e con eventuali considerazioni di sicurezza giustificate.

La registrazione completa collega l'advisory, l'analisi delle build interessate, la decisione sulla notifica, le trasmissioni ove richieste, i commit della patch, i risultati dei test, gli artefatti di release e le comunicazioni. Un revisore può ora ricostruire sia la risposta tecnica sia la decisione di compliance.

Iniziare con un prodotto e una catena di evidenze completa

Scegliete un prodotto supportato rappresentativo e seguite una release recente e una vulnerabilità lungo l'intero ciclo di vita. Collegamenti mancanti alle versioni, impegni di supporto poco chiari e procedure di notifica inaccessibili emergeranno rapidamente. Trasformate ogni lacuna in un'attività con un responsabile, poi estendete il modello all'intero portafoglio.

Secani può supportare questo workflow delle evidenze collegando requisiti, evidenze, responsabili, attività e decisioni di revisione. Gli strumenti di engineering restano le fonti operative per build, release e vulnerabilità; lo spazio di lavoro per la compliance mette in relazione queste registrazioni con l'obbligo applicabile. Mantenete esplicita l'approvazione umana di mappature e conclusioni e preservate la tracciabilità delle fonti quando utilizzate bozze assistite dall'IA.

Il passo immediato successivo è testare il runbook di notifica. In parallelo, richiedete che la prossima release del prodotto sia accompagnata da una decisione sull'ambito collegata, da una valutazione del rischio aggiornata, da un inventario dei componenti e da un'approvazione di sicurezza. Questo crea una pratica tecnica ripetibile mentre la preparazione alla conformità prosegue.