Quali evidenze servono per documentare requisiti, cybersecurity, tracciabilità e aggiornamenti del software in vista del 20 gennaio 2027.

A cura di Viviana Scot
[Head of Software V&V Division – Area Ingegneria del Software ]

Dal 20 gennaio 2027, dimostrare la conformità di una macchina significherà poter ricostruire anche il modo in cui il software rilevante per la sicurezza è stato specificato, sviluppato, verificato, protetto e aggiornato. Le evidenze derivano da requisiti tracciati, rischi valutati, versioni controllate, test documentati e decisioni ricostruibili lungo l’intero ciclo di vita.

Nel nostro primo approfondimento  abbiamo analizzato le principali novità del Regolamento (UE) 2023/1230: il ruolo del software nelle funzioni di sicurezza, i requisiti di cybersecurity, i sistemi con comportamento autoevolutivo e gli effetti delle modifiche sostanziali.

In questo secondo articolo passiamo dalle regole alle evidenze attraverso quattro domande operative:

1. In quanto tempo sapreste produrre le evidenze del vostro software di sicurezza?
2. Sapreste dimostrare che software e dati sono protetti da alterazioni accidentali o intenzionali?
3. Il vostro componente di sicurezza utilizza comportamenti o logiche autoevolutivi?
4. Il prossimo aggiornamento software potrebbe costituire una modifica sostanziale?

Le quattro domande hanno un elemento comune: la conformità non nasce dallo strumento utilizzato, ma dalla capacità di mantenere requisiti, rischi, verifiche, versioni e decisioni collegati e ricostruibili nel tempo. L’approccio di NIER si fonda sull’esperienza maturata nella verifica e validazione di sistemi safety-critical in ambito ferroviario, biomedicale e industriale.

Quattro domande sulla conformità del software secondo il Regolamento Macchine.

1) In quanto tempo sapreste produrre le evidenze del vostro software di sicurezza?

La capacità di produrre rapidamente le evidenze dipende dalla tracciabilità costruita durante lo sviluppo. Requisiti, rischi, versioni, verifiche e risultati dei test dovrebbero essere collegati e aggiornati lungo il ciclo di vita, non ricostruiti manualmente alla fine del progetto.

La documentazione tecnica prevista dall’Allegato IV deve specificare i mezzi utilizzati per assicurare la conformità della macchina o del prodotto correlato ai requisiti essenziali applicabili. Ai sensi dell’articolo 10, paragrafo 3, su richiesta motivata dell’autorità nazionale competente devono inoltre essere messi a disposizione, se pertinenti e necessari alla verifica, il codice sorgente o la logica di programmazione del software rilevante per la sicurezza.

In un processo software strutturato, le evidenze utili a sostenere e rendere ricostruibile la dimostrazione di conformità possono comprendere:

• requisiti di sicurezza identificati e approvati;
• collegamenti tra requisiti, rischi e test;
• matrici di tracciabilità;
• report di verifica e validazione;
• storico delle versioni e delle modifiche;
• registrazioni di revisioni e approvazioni;
• documentazione coerente con la configurazione effettivamente rilasciata.

Le organizzazioni che hanno strutturato i propri processi sul quadro precedente potrebbero non disporre ancora di tutte queste evidenze con il livello di tracciabilità oggi necessario. Il tempo per costruirle c’è, ma è opportuno iniziare dalla documentazione e dai processi già disponibili.

2) Sapreste dimostrare che software e dati sono protetti da alterazioni accidentali o intenzionali?

La protezione tecnica non è sufficiente: occorrono evidenze che colleghino minacce, requisiti di cybersecurity, misure implementate e risultati delle verifiche.

Il Regolamento richiede che software, dati e componenti rilevanti per la sicurezza siano protetti da alterazioni accidentali o intenzionali e che i sistemi di comando resistano anche a tentativi deliberati ragionevolmente prevedibili che possano generare situazioni pericolose. Non basta quindi introdurre misure di protezione: occorre poter dimostrare come i rischi siano stati identificati, trattati e verificati.

Le evidenze possono comprendere:

• analisi delle minacce e dei rischi;
• requisiti di cybersecurity derivati dall’analisi;
• architetture e misure di protezione;
• registrazioni delle versioni e degli interventi;
• risultati di vulnerability assessment e penetration test;
• prove su protocolli e scenari degradati;
• monitoraggio degli asset e delle reti OT durante l’esercizio.

Il percorso parte dall’analisi del sistema, delle sue dipendenze e dei possibili scenari di minaccia. Le attività possono comprendere analisi dei rischi, verifica delle misure, test sui protocolli e monitoraggio degli asset durante l’esercizio.

L’articolo 20, paragrafo 9, prevede inoltre che le macchine e i prodotti correlati certificati, o accompagnati da una dichiarazione di conformità, nell’ambito di un pertinente sistema europeo di certificazione della cibersicurezza possano beneficiare di una presunzione di conformità rispetto ai punti 1.1.9 e 1.2.1 dell’Allegato III, limitatamente ai requisiti effettivamente coperti dal certificato o dalla dichiarazione.

3) Il componente di sicurezza utilizza comportamenti o logiche autoevolutivi?

Non tutto il software che svolge una funzione di sicurezza rientra automaticamente nella categoria dei componenti autoevolutivi dell’Allegato I, parte A.

Quando il comportamento di un componente di sicurezza evolve integralmente o parzialmente attraverso tecniche di apprendimento automatico, è necessario verificare con attenzione la classificazione del prodotto e la procedura di valutazione applicabile.

I componenti di sicurezza dotati di comportamento integralmente o parzialmente autoevolutivo, che utilizzano approcci di apprendimento automatico e garantiscono funzioni di sicurezza, sono inclusi nell’Allegato I, parte A. Per tali categorie, l’articolo 25 richiede una procedura di valutazione della conformità che coinvolge un organismo notificato. Non è quindi sufficiente concentrarsi sul funzionamento finale del componente: occorre poter ricostruire anche come il comportamento è stato definito, addestrato, verificato e controllato.

In funzione del prodotto, dell’architettura e della procedura applicabile, tra le evidenze tecniche da considerare possono rientrare:

• finalità e limiti della funzione di sicurezza;
• dati utilizzati per addestramento, verifica e validazione;
• versioni dei modelli;
• risultati dei test;
• modifiche introdotte nel tempo.

Per le macchine alimentate da sensori, azionate da remoto o autonome, l’Allegato IV richiede inoltre, quando applicabile, una descrizione delle caratteristiche, delle capacità e delle limitazioni del sistema, nonché dei dati e dei processi di sviluppo, prova e convalida utilizzati.

Il Regolamento introduce inoltre obblighi specifici di registrazione. Le versioni del software di sicurezza caricate dopo l’immissione sul mercato o la messa in servizio devono poter essere tracciate per cinque anni dal caricamento. Per i sistemi autoevolutivi interessati devono inoltre poter essere registrati i dati relativi al processo decisionale in materia di sicurezza, da conservare per un anno dalla raccolta, ai fini della dimostrazione della conformità su richiesta motivata dell’autorità competente.

Questi obblighi devono essere considerati nella progettazione del sistema e nell’organizzazione della documentazione tecnica.

Il lavoro preparatorio è determinante: la valutazione di terza parte è più efficace quando requisiti, rischi, dati, modelli, test e decisioni sono già organizzati in una documentazione tecnica coerente e ricostruibile.

NIER affianca i costruttori nella definizione delle evidenze necessarie, nella loro produzione all’interno del processo di sviluppo e nella preparazione della documentazione tecnica richiesta dalla procedura applicabile.

4) Il prossimo aggiornamento software potrebbe costituire una modifica sostanziale?

Ogni aggiornamento che incide sulle funzioni, sulle prestazioni o sui rischi della macchina deve essere valutato rispetto ai possibili effetti sulla sicurezza.

Quando una modifica non prevista o non pianificata dal fabbricante incide sulla sicurezza e determina una modifica sostanziale, il Regolamento attribuisce gli obblighi del fabbricante al soggetto che ha effettuato l’intervento. Ai sensi dell’articolo 3, punto 16, una modifica può essere qualificata come sostanziale quando, dopo l’immissione sul mercato o la messa in servizio, non era stata prevista o pianificata dal fabbricante, incide sulla sicurezza creando un nuovo pericolo o aumentando un rischio esistente e rende necessaria una delle misure ulteriori individuate dal Regolamento: l’aggiunta di ripari o dispositivi di protezione che comporti la modifica del sistema di comando di sicurezza esistente, oppure l’adozione di misure supplementari per assicurare la stabilità o la resistenza meccanica della macchina o del prodotto correlato.

Quando ricorrono queste condizioni, il soggetto che effettua la modifica sostanziale assume, per il prodotto interessato, gli obblighi del fabbricante previsti dal Regolamento e deve applicare la pertinente procedura di valutazione della conformità.

Per ogni release è opportuno documentare:

• ragioni della modifica;
• componenti e requisiti interessati;
• effetti sulle funzioni di sicurezza;
• nuovi pericoli o variazioni del rischio;
• test da ripetere o integrare;
• aggiornamenti della documentazione tecnica;
• conclusione motivata sulla qualificazione della modifica e sulle attività di conformità eventualmente necessarie.

Questo è uno dei motivi principali per investire nella tracciabilità. Quando requisiti, test e documenti sono versionati, l’impatto di una release può essere valutato in modo più rapido, coerente e dimostrabile.

Il confronto tra versioni dei requisiti supportato da VyxT e la gestione della storicità documentale in DocDec possono contribuire a rendere questo processo più controllato.

Cinque controlli preliminari sul processo software

Nell’esperienza maturata da NIER nelle attività di verifica e validazione, il punto critico non è sempre l’assenza delle informazioni, ma la difficoltà di collegarle in modo coerente alla configurazione effettivamente rilasciata.

Prima di avviare il percorso di adeguamento è utile verificare:

• ogni requisito di sicurezza è associato a uno o più test?
• ogni report identifica la versione software verificata?
• le modifiche sono collegate ai requisiti e ai rischi interessati?
• revisioni, approvazioni e responsabilità sono ricostruibili?
• per ogni release è documentata una valutazione dell’impatto sulla sicurezza?

Questi controlli consentono di distinguere le evidenze già disponibili da quelle che devono essere completate o rese maggiormente tracciabili.

Come prepararsi: un percorso in tre fasi.

Il percorso parte da una gap analysis dello stato attuale. L’obiettivo è identificare le evidenze già disponibili, gli scostamenti da colmare e le priorità di intervento.

1. Misurare: Definire il perimetro, verificare le evidenze disponibili e identificare gli scostamenti rispetto ai requisiti applicabili.

• classificare il software e le funzioni rilevanti per la sicurezza;
• verificare la documentazione e tracciabilità;
• analizzare minacce e rischi di cybersecurity;
• identificare carenze e informazioni non aggiornate.

In questa fase, P4UL può supportare l’analisi di minacce e rischi, VyxT la verifica della copertura della tracciabilità e DocDec il confronto con la struttura documentale prevista.

2. Adeguare: Colmare gli scostamenti attraverso ruoli, flussi, requisiti, test, controlli di versione e misure di cybersecurity:

• definire ruoli e approvazioni;
• completare requisiti e criteri di accettazione;
• collegare requisiti e test;
• aggiornare misure, template e documentazione.

DocDec può supportare flussi, versioni e approvazioni; VyXT la tracciabilità end-to-end e la preparazione dei test; P4UL la definizione delle misure derivate dall’analisi dei rischi.

3. Dimostrare e mantenere: Verificare l’efficacia delle misure, mantenere aggiornate le evidenze e valutare l’impatto di ogni modifica.

• eseguire verifica e validazione;
• produrre report, matrici e registrazioni;
• verificare e monitorare le misure di cybersecurity;
• mantenere allineata la documentazione alla configurazione rilasciata.

TOMz può supportare la verifica delle misure attraverso penetration test; EmuXP le prove sui protocolli e sugli scenari degradati; SCAI il monitoraggio delle reti OT e dei PLC durante l’esercizio.

Le evidenze nascono dal processo.

Il Regolamento Macchine 2023/1230 non richiede soltanto documenti aggiuntivi. Richiede che sia possibile ricostruire come i requisiti di sicurezza siano stati identificati, implementati, verificati e mantenuti nel tempo.

Un processo strutturato riduce il rischio di dover ricostruire le evidenze alla fine del progetto, facilita la gestione delle modifiche e rende più solide le interlocuzioni con autorità, organismi notificati, clienti e partner della filiera.

Dal 20 gennaio 2027, dimostrare la conformità di una macchina richiederà, quando il software è rilevante per la sicurezza, anche evidenze che consentano di ricostruire come è stato specificato, sviluppato, verificato, protetto e aggiornato.

Quanto è pronto il vostro processo software per il 2027?

Una gap analysis consente di:

• identificare le evidenze già disponibili;
• individuare carenze di tracciabilità e documentazione;
• definire le priorità di intervento;
• impostare una roadmap di adeguamento.

Il team Ingegneria del Software di NIER può affiancare i costruttori nell’individuazione del software rilevante per la sicurezza, nella verifica delle evidenze già disponibili e nella definizione delle priorità di adeguamento verso il 2027. Compila il form in basso e richiedi una gap analysis