CRA Documentazione tecnica: guida Allegato VII

Il fascicolo tecnico è il pacchetto di prove per la conformità CRA. Le autorità di sorveglianza del mercato lo richiederanno. Gli Organismi Notificati lo esamineranno. Senza un fascicolo tecnico completo, non puoi immettere legalmente il tuo prodotto sul mercato dell'UE.

Questa guida analizza l'Allegato VII sezione per sezione, spiegando cosa richiede ciascuna parte e come prepararla.

Cos'è il fascicolo tecnico?

Il fascicolo tecnico (anche detto "documentazione tecnica") è il pacchetto completo di prove che dimostra che il prodotto è conforme ai requisiti del CRA.

Non è:

• Documentazione di marketing
• Solo manuali utente
• Un esercizio di spunta caselle

È:

• Prove tecniche complete
• Documentazione viva (aggiornata per tutta la vita del prodotto)
• La tua difesa nelle indagini di sorveglianza del mercato
• Necessario per la valutazione della conformità

Panoramica della struttura dell'Allegato VII

L'Allegato VII del CRA specifica i requisiti della documentazione tecnica:

STRUTTURA DEL FASCICOLO TECNICO (Allegato VII)

1. DESCRIZIONE GENERALE
   \-- Identificazione del prodotto e finalità prevista

2. PROGETTAZIONE, SVILUPPO, GESTIONE DELLE VULNERABILITÀ E PRODUZIONE
   \-- Sicurezza integrata, vulnerabilità gestite, produzione e monitoraggio validati

3. VALUTAZIONE DEI RISCHI DI CYBERSICUREZZA
   \-- Rischi identificati e affrontati

4. INFORMAZIONI SUL PERIODO DI SUPPORTO
   \-- Informazioni utilizzate per determinare il periodo di supporto (articolo 13, paragrafo 8)

5. NORME APPLICATE
   \-- Norme utilizzate e deviazioni

6. RISULTATI DEI TEST
   \-- Prove di verifica

7. DICHIARAZIONE UE DI CONFORMITÀ
   \-- O copia della stessa

8. DISTINTA DEI MATERIALI SOFTWARE
   \-- Componenti e dipendenze (su richiesta motivata)

Sezione 1: Descrizione generale

Scopo: Stabilire cos'è il prodotto e a cosa serve.

Contenuto richiesto

CHECKLIST DESCRIZIONE GENERALE

Identificazione prodotto:
[ ] Nome del prodotto e numero di modello
[ ] Versione/i hardware
[ ] Versione/i software/firmware
[ ] Formato o intervallo dei numeri di serie
[ ] Identificatore univoco del prodotto

Finalità prevista:
[ ] Descrizione della funzione principale
[ ] Utenti/ambiente di destinazione
[ ] Casi d'uso previsti
[ ] Usi non previsti (esclusioni)

Categoria prodotto:
[ ] Classificazione CRA (Default/Importante/Critico)
[ ] Giustificazione della classificazione
[ ] Regolamenti di prodotto correlati (se presenti)

Informazioni di mercato:
[ ] Data della prima immissione sul mercato UE
[ ] Stati membri di destinazione
[ ] Canali di distribuzione

Esempio

DESCRIZIONE GENERALE

Nome prodotto: SmartSense Pro Industrial Sensor
Numero modello: SSP-3000
Versione hardware: Rev C (PCB v3.2)
Versione firmware: 2.4.1

FINALITÀ PREVISTA:
Lo SmartSense Pro è un sensore ambientale industriale
progettato per il monitoraggio di impianti produttivi.
Misura temperatura, umidità e qualità dell'aria, trasmettendo
i dati via WiFi a server cloud o locali.

UTENTI DI DESTINAZIONE:
- Responsabili di stabilimento
- Integratori di automazione industriale
- Responsabili di conformità ambientale

AMBIENTE PREVISTO:
- Impianti industriali al chiuso
- Temperatura operativa: da -10°C a +60°C
- Rete: WiFi 802.11 b/g/n

NON PREVISTO PER:
- Applicazioni mediche o di sicurezza delle persone
- Installazione esterna
- Atmosfere esplosive
- Uso consumer/residenziale

CLASSIFICAZIONE CRA:
Prodotto default. Non elencato nell'Allegato III o IV.
Giustificazione: sensore generico senza funzioni di
sicurezza o applicazione su infrastrutture critiche.

IMMISSIONE SUL MERCATO UE:
Prima immissione sul mercato: 15 marzo 2027
Mercati di destinazione: tutti gli Stati membri dell'UE
Distribuzione: vendita diretta e distributori autorizzati

Sezione 2: Progettazione, sviluppo e gestione delle vulnerabilità

Scopo: Documentare come il prodotto è stato progettato e sviluppato, come le vulnerabilità sono gestite dopo il rilascio e come i processi di produzione e monitoraggio vengono validati. L'Allegato VII §2 li tratta come un blocco unico: progettazione e sviluppo al §2(a), processi di gestione delle vulnerabilità al §2(b), processi di produzione e monitoraggio al §2(c).

Progettazione e sviluppo: contenuto richiesto

CHECKLIST DOCUMENTAZIONE PROGETTAZIONE

Architettura:
[ ] Diagramma dell'architettura di sistema
[ ] Diagramma di interazione tra i componenti
[ ] Diagramma del flusso dei dati
[ ] Confini di fiducia identificati

Progettazione di sicurezza:
[ ] Descrizione dell'architettura di sicurezza
[ ] Implementazioni crittografiche
[ ] Meccanismi di autenticazione
[ ] Modello di autorizzazione
[ ] Protocolli di comunicazione sicura
[ ] Misure di protezione dei dati

Processo di sviluppo:
[ ] Descrizione del ciclo di sviluppo sicuro
[ ] Tracciabilità dei requisiti di sicurezza
[ ] Procedure di revisione del codice
[ ] Test di sicurezza in sviluppo
[ ] Gestione della configurazione

Gestione delle modifiche:
[ ] Procedure di controllo versione
[ ] Valutazione dell'impatto delle modifiche
[ ] Revisione di sicurezza per le modifiche

Come si presenta una documentazione "secure by design"

PANORAMICA ARCHITETTURA DI SICUREZZA

1. CONFINI DI FIDUCIA
   +-----------------------------------------+
   |            Backend Cloud                 |
   |  (Autenticazione, archiviazione dati)    |
   \---------------+-------------------------+
                   | TLS 1.3
   +---------------+-------------------------+
   |         Firmware del dispositivo         |
   |  +---------------------------------+    |
   |  |    Livello applicativo          |    |
   |  +---------------------------------+    |
   |  |    Servizi di sicurezza         |    |
   |  |  (Crypto, Auth, Secure Boot)    |    |
   |  +---------------------------------+    |
   |  |    Sicurezza hardware           |    |
   |  |  (Secure Element, RNG)          |    |
   |  \---------------------------------+    |
   \-----------------------------------------+

2. AUTENTICAZIONE
   - Dispositivo verso cloud: mTLS con certificati di dispositivo
   - Utente verso dispositivo: API locale con token di autenticazione
   - Provisioning certificati: provisioning in fabbrica, univoco per dispositivo

3. PROTEZIONE DEI DATI
   - Dati a riposo: cifratura AES-256-GCM
   - Dati in transito: TLS 1.3 con certificate pinning
   - Dati sensibili: archiviati nel secure element

4. MECCANISMO DI AGGIORNAMENTO
   - Aggiornamenti firmware firmati (ECDSA P-256)
   - Verifica della firma prima dell'installazione
   - Protezione contro il rollback tramite contatore di versione
   - Verifica automatica degli aggiornamenti (configurabile dall'utente)

Gestione delle vulnerabilità: contenuto richiesto

CHECKLIST GESTIONE VULNERABILITÀ

Acquisizione:
[ ] Metodi di contatto documentati (email, modulo web, security.txt)
[ ] Politica CVD pubblicata
[ ] Procedure di comunicazione con i ricercatori

Processo:
[ ] Procedure di triage
[ ] Metodologia di valutazione della severità
[ ] Percorsi di escalation
[ ] Workflow di sviluppo delle patch
[ ] Procedure di test per le patch

Comunicazione:
[ ] Procedure di notifica ai clienti
[ ] Processo di pubblicazione degli avvisi
[ ] Integrazione del reporting ENISA (per sfruttamento attivo)

Monitoraggio:
[ ] Monitoraggio delle vulnerabilità nelle dipendenze
[ ] Monitoraggio del database CVE
[ ] Fonti di threat intelligence

Documentazione della gestione delle vulnerabilità

PROCEDURE DI GESTIONE DELLE VULNERABILITÀ

1. METODI DI CONTATTO
   Principale: security@company.com
   Modulo web: https://company.com/security/report
   security.txt: https://company.com/.well-known/security.txt
   Politica CVD: https://company.com/security/disclosure-policy

2. IMPEGNI DI RISPOSTA
   Conferma di ricezione: entro 3 giorni lavorativi
   Valutazione iniziale: entro 10 giorni lavorativi
   Aggiornamenti di stato: ogni 14 giorni
   Obiettivo di risoluzione: 90 giorni (critico: 7 giorni)

3. PROCESSO INTERNO
   [Diagramma di flusso o descrizione del processo]
   Vedi: Documento di processo PD-VULN-003

4. DISTRIBUZIONE DELLE PATCH
   Meccanismo: aggiornamenti OTA tramite infrastruttura cloud
   Notifica: notifica in-app + email agli utenti registrati
   Verifica: aggiornamenti firmati con possibilità di rollback

5. REPORTING ENISA
   Trigger: rilevamento di sfruttamento attivo
   Tempistica: allerta precoce 24h, rapporto dettagliato 72h
   Responsabile: Security Team Lead
   Processo: vedi PD-ENISA-001

6. STORICO
   Vulnerabilità gestite (ultimi 24 mesi): 3
   Tempo medio di risoluzione: 45 giorni
   Rapporti ENISA inviati: 0

Produzione e monitoraggio: contenuto richiesto

Per i prodotti software non esiste una linea di fabbrica. L'Allegato VII, punto 2(c), si applica alla pipeline di build e rilascio che produce gli artefatti consegnabili, alla validazione che tali processi funzionino come previsto e al monitoraggio post-deployment che intercetta regressioni e nuove vulnerabilità. Documenta ciascun aspetto in modo che un auditor possa risalire da un rilascio a una build verificata e riproducibile.

CHECKLIST PRODUZIONE E MONITORAGGIO

Pipeline di build e rilascio:
[ ] Fonte di verità identificata (repository, protezione dei branch)
[ ] Build riproducibile documentata (versioni della toolchain fissate)
[ ] Provenienza della build catturata (livello SLSA, attestazioni in-toto)
[ ] Chiavi di firma e gestione delle chiavi documentate
[ ] Integrità degli artefatti di rilascio (binari firmati, SBOM al rilascio)

Validazione dei processi di produzione:
[ ] Gate di sicurezza in CI documentati (criteri di superamento SAST, DAST, SCA)
[ ] Suite di regressione che copre i requisiti tracciati nell'Allegato I
[ ] Workflow di approvazione del rilascio documentato
[ ] Piano di rollback per i rilasci falliti
[ ] Cadenza degli audit di riproducibilità

Monitoraggio post-deployment:
[ ] Cadenza del monitoraggio delle vulnerabilità nelle dipendenze (giornaliero/settimanale)
[ ] Processo di diff dell'SBOM a ogni rilascio
[ ] Integrazione dei feed CVE (NVD, GHSA, advisory dei vendor)
[ ] Verifica incrociata KEV per sfruttamento attivo
[ ] Telemetria per eventi rilevanti per la sicurezza (aggiornamenti falliti, fallimenti di firma)
[ ] Trigger di notifica ai clienti documentati

Documentazione di produzione e monitoraggio

PROCESSI DI PRODUZIONE E MONITORAGGIO

Prodotto: Industrial Gateway IG-200
Piattaforma di build: GitHub Actions su runner ubuntu-22.04
Provenienza: SLSA Level 3 (attestazioni in-toto firmate)
Firma: Cosign + Sigstore, chiave di root offline custodita in KMS

PIPELINE DI BUILD:
1. Sorgente: github.com/example/ig200-firmware (branch main protetto,
   gate di review 2-su-N, commit firmati richiesti)
2. Build: cross-compile riproducibile (rustc 1.78, Cargo.lock bloccato)
3. SAST: cargo-audit + lint di sicurezza clippy (gate: 0 finding alti+)
4. SCA: scansione trivy sul binario prodotto (gate: 0 CVE sfruttabili noti)
5. Test: suite di regressione (1247 test) + suite di conformità Allegato I (89 test)
6. Firma: cosign sign-blob + attest --predicate slsa-provenance.json
7. Rilascio: artefatto + SBOM (CycloneDX 1.5) + estratto della DoC pubblicato

VALIDAZIONE DEI PROCESSI:
- Definizione della pipeline rivista trimestralmente (Security Lead + Release Manager)
- Suite di test di conformità Allegato I rivista quando cambiano norme o rischi
- Audit annuale di riproducibilità (rebuild indipendente dal sorgente taggato)
- Modalità di fallimento: gate fallito -> rilascio bloccato, incidente registrato

MONITORAGGIO POST-DEPLOYMENT:
- Feed CVE delle dipendenze: Trivy + Renovate, scansione giornaliera sull'SBOM corrente
- Soglia: Critico o Alto con match KEV -> patch entro 7 giorni
- Soglia: Medio senza KEV -> patch nel rilascio mensile successivo
- Notifica ai clienti: feed RSS firmato + email per gli advisory
- Telemetria interna: eventi di aggiornamento falliti, fallimenti di verifica delle firme
- Cadenza di revisione: triage settimanale, revisione di tendenza mensile

Sezione 3: Valutazione dei rischi di cybersicurezza

Scopo: Documentare i rischi identificati e come vengono affrontati.

Contenuto richiesto

CHECKLIST VALUTAZIONE DEI RISCHI

Metodologia:
[ ] Metodologia di valutazione dei rischi descritta
[ ] Definizione dell'ambito
[ ] Identificazione degli asset
[ ] Approccio all'identificazione delle minacce

Analisi dei rischi:
[ ] Minacce enumerate
[ ] Vulnerabilità considerate
[ ] Valutazione dell'impatto
[ ] Valutazione della probabilità
[ ] Valutazione del rischio

Trattamento del rischio:
[ ] Decisioni di trattamento per ciascun rischio
[ ] Controlli di sicurezza mappati ai rischi
[ ] Valutazione del rischio residuo
[ ] Criteri di accettazione del rischio

Formato della valutazione dei rischi

VALUTAZIONE DEI RISCHI DI CYBERSICUREZZA

Prodotto: SmartSense Pro (SSP-3000)
Versione: 2.4.1
Data valutazione: gennaio 2027
Valutatore: [Nome, Team Sicurezza]

METODOLOGIA:
Basata su ISO 27005 adattata per la sicurezza di prodotto.
Rischio = Probabilità × Impatto
Scala: Basso (1-4), Medio (5-9), Alto (10-16), Critico (17-25)

-------------------------------------------------------------
ID RISCHIO: R-001
MINACCIA: Modifica non autorizzata del firmware
VULNERABILITÀ: Possibile installazione di firmware non firmato
IMPATTO: Alto (5) - Compromissione del dispositivo, violazione dati
PROBABILITÀ: Media (3) - Richiede accesso fisico
RISCHIO INERENTE: 15 (Alto)

CONTROLLO: Verifica della firma del firmware
IMPLEMENTAZIONE: Firma ECDSA P-256 verificata prima dell'installazione
RISCHIO RESIDUO: 3 (Basso) - Attacco crittografico improbabile

STATO: Mitigato
-------------------------------------------------------------
ID RISCHIO: R-002
MINACCIA: Attacco man-in-the-middle sulla comunicazione cloud
VULNERABILITÀ: Intercettazione del traffico di rete
IMPATTO: Alto (4) - Esposizione dati, command injection
PROBABILITÀ: Media (3) - Reti pubbliche possibili
RISCHIO INERENTE: 12 (Alto)

CONTROLLO: TLS 1.3 con certificate pinning
IMPLEMENTAZIONE: Certificato CA hardcoded, nessun fallback
RISCHIO RESIDUO: 2 (Basso) - Compromissione del certificato improbabile

STATO: Mitigato
-------------------------------------------------------------
[Continuare per tutti i rischi identificati...]

RIEPILOGO RISCHI:
Totale rischi identificati: 23
Critico: 0
Alto: 3 (tutti mitigati a Basso/Medio)
Medio: 8 (tutti mitigati a Basso)
Basso: 12 (accettati o mitigati)

ACCETTAZIONE DEL RISCHIO RESIDUO:
Tutti i rischi residui rientrano nella tolleranza accettabile.
Firmato: [Security Lead], [Data]

Sezione 4: Informazioni sul periodo di supporto

Scopo: Documentare le ragioni del periodo di supporto scelto, ai sensi dell'articolo 13, paragrafo 8. Il periodo di supporto è il tempo durante il quale il fabbricante si impegna a fornire aggiornamenti di sicurezza. L'Allegato VII, punto 4, richiede che il fascicolo tecnico riporti le informazioni che hanno guidato tale decisione.

Contenuto richiesto

RECORD DELLA DECISIONE SUL PERIODO DI SUPPORTO

Periodo di supporto dichiarato: [data inizio] - [data fine]
Minimo: 5 anni dall'immissione sul mercato (o vita del prodotto, se inferiore)

Elementi considerati (articolo 13, paragrafo 8):
[ ] Durata d'uso prevista del prodotto
[ ] Aspettative di utenti e clienti
[ ] Natura e finalità prevista del prodotto
[ ] Diritto dell'Unione pertinente (minimi settoriali)
[ ] Orientamenti emessi dalla Commissione
[ ] Aspettative ragionevoli di consumatori e altri utenti finali

Giustificazione documentata:
[ ] Vite utili di prodotti comparabili sul mercato
[ ] Tempistiche di supporto dei fornitori dei componenti (OS, runtime, librerie)
[ ] Contratti o SLA con i clienti che implicano finestre di aggiornamento
[ ] Calendari di end-of-life dell'hardware (se applicabile)

Come si presenta una buona documentazione

DETERMINAZIONE DEL PERIODO DI SUPPORTO
Prodotto: Industrial Gateway IG-200
Immissione sul mercato: 2026-09-01
Periodo di supporto dichiarato: 2026-09-01 - 2034-09-01 (8 anni)

Motivazione:
1. Vita operativa attesa: 8-10 anni (dati di campo,
   confrontabili con il predecessore IG-150 ancora attivo nel 2024 a 9 anni).
2. Supporto dei componenti: il kernel Linux LTS copre 6 anni;
   eseguiamo backport delle patch di sicurezza per 2 anni aggiuntivi
   sulla base degli impegni del fornitore.
3. Contratti clienti: i 3 clienti principali hanno accordi di servizio
   a 7 anni; gli altri rinnovano tipicamente su cicli di 5 anni.
4. Orientamenti settoriali: NIS2 copre operatori di servizi essenziali
   che usano questo gateway; assumiamo requisiti di aggiornamento
   per tutta la vita dell'asset.
5. Comunicazione di fine supporto: documentata nel manuale utente e
   nella politica EOL all'indirizzo https://example.com/security/eol.

Decisione approvata da: [Product Owner], [Security Lead], [Legal]
Data: 2026-08-15
Trigger di revisione: qualsiasi cambiamento sostanziale alle tempistiche di supporto dei componenti

Errori frequenti

• Ancorarsi al minimo di 5 anni senza giustificazione. I 5 anni dell'articolo 13, paragrafo 8 sono una soglia minima, non un valore predefinito. Prodotti con vita utile prevista più lunga richiedono un periodo più lungo.
• Dimenticare il limite "o vita del prodotto, se inferiore". Un dispositivo consumer venduto per 18 mesi deve comunque ricevere supporto agli aggiornamenti per il periodo durante il quale ci si aspetta ragionevolmente che il prodotto sia in uso.
• Non registrare gli elementi considerati. Le autorità di sorveglianza possono chiedere come è stato determinato il periodo. "Abbiamo scelto 5 anni" non è una risposta.
• Considerarlo immutabile. Se le tempistiche di supporto dei componenti cambiano (ad esempio, un OS upstream raggiunge l'EOL prima del previsto), il record di decisione deve essere aggiornato e l'impegno di supporto comunicato.

Mappatura dei requisiti essenziali (Allegato I)

Scopo: Dimostrare come ogni requisito dell'Allegato I sia soddisfatto.

Requisiti dell'Allegato I, parte I

Mappa ciascun requisito sulla tua implementazione:

MATRICE DI CONFORMITÀ AI REQUISITI ESSENZIALI

ALLEGATO I, PARTE I - REQUISITI DI SICUREZZA
═══════════════════════════════════════════════════════════

1. PROGETTATO SENZA VULNERABILITÀ SFRUTTABILI NOTE
   Stato: CONFORME
   Prove:
   - Rapporto di scansione delle vulnerabilità (Trivy): 0 critico/alto
   - Analisi delle dipendenze: tutti i componenti alle ultime versioni sicure
   - Rapporto di test di penetrazione: nessuna vulnerabilità sfruttabile riscontrata
   Riferimento: Rapporto di test TR-2027-001, pagine 15-23

2. CONFIGURAZIONE SICURA PER DEFAULT
   Stato: CONFORME
   Prove:
   - Documento di revisione della configurazione di default
   - Nessuna password di default (credenziali univoche richieste in setup)
   - Servizi non necessari disabilitati di default
   - Protocolli sicuri abilitati di default (TLS, non HTTP)
   Riferimento: Documento di progettazione DD-004, sezione 3.2

3. PROTEZIONE CONTRO L'ACCESSO NON AUTORIZZATO
   Stato: CONFORME
   Prove:
   - Documento sull'architettura di autenticazione
   - Implementazione del controllo accessi
   - Progettazione della gestione delle sessioni
   - Meccanismo di blocco dopo tentativi di login falliti
   Riferimento: Architettura di sicurezza SA-001, capitolo 4

4. RISERVATEZZA DEI DATI
   Stato: CONFORME
   Prove:
   - Specifiche di cifratura (AES-256-GCM)
   - Procedure di gestione delle chiavi
   - Classificazione e trattamento dei dati
   Riferimento: Documento di progettazione DD-005

5. INTEGRITÀ DI DATI E COMANDI
   Stato: CONFORME
   Prove:
   - Autenticazione dei messaggi (HMAC)
   - Logica di validazione dei comandi
   - Procedure di validazione degli input
   Riferimento: Architettura di sicurezza SA-001, capitolo 5

6. MINIMIZZAZIONE DEI DATI
   Stato: CONFORME
   Prove:
   - Documento di inventario dei dati
   - Giustificazione per ciascun tipo di dato raccolto
   - Politica di conservazione (cancellazione automatica dopo 90 giorni)
   Riferimento: Valutazione d'impatto sulla privacy PIA-001

[Continuare per tutti i requisiti dell'Allegato I...]

Requisiti dell'Allegato I, parte II

ALLEGATO I, PARTE II - GESTIONE DELLE VULNERABILITÀ
═══════════════════════════════════════════════════════════

1. IDENTIFICARE E DOCUMENTARE LE VULNERABILITÀ
   Stato: CONFORME
   Prove:
   - Sistema di tracciamento delle vulnerabilità (progetto JIRA VULN)
   - Documento di processo di monitoraggio dei CVE
   - Tracciamento delle dipendenze basato su SBOM
   Riferimento: Documento di processo PD-VULN-001

2. AFFRONTARE LE VULNERABILITÀ SENZA RITARDO
   Stato: CONFORME
   Prove:
   - Documento SLA di risposta alle vulnerabilità
   - Metriche storiche di tempo di risposta
   - Processo di sviluppo delle patch
   Riferimento: Documento di processo PD-VULN-002

3. APPLICARE TEST EFFICACI E PERIODICI
   Stato: CONFORME
   Prove:
   - Pianificazione dei test di sicurezza
   - Rapporti di scansione automatica (settimanali)
   - Rapporti annuali di test di penetrazione
   Riferimento: Piano di test TP-SEC-001

[Continuare per tutti i requisiti della parte II...]

Sezione 5: Norme applicate

Scopo: Documentare quali norme sono state utilizzate e in che modo.

Contenuto richiesto

CHECKLIST APPLICAZIONE DELLE NORME

Elenco delle norme:
[ ] Tutte le norme applicate elencate con numero di versione
[ ] Norme armonizzate identificate separatamente
[ ] Riferimento alla pubblicazione in Gazzetta Ufficiale (se armonizzate)

Prove di applicazione:
[ ] Come è stata applicata ciascuna norma
[ ] Quali clausole/sezioni si applicano
[ ] Eventuali deviazioni o applicazione parziale

Gestione delle deviazioni:
[ ] Deviazioni documentate con giustificazione
[ ] Misure alternative per i requisiti deviati
[ ] Valutazione dei rischi delle deviazioni

Formato di documentazione delle norme

NORME APPLICATE

NORME ARMONIZZATE (presunzione di conformità):
-------------------------------------------------------------
Norma: EN 303 645 (quando armonizzata per il CRA)
Titolo: Cybersicurezza per IoT consumer
Stato: Applicata integralmente
Pubblicazione: GUUE [riferimento quando pubblicata]
Prove: Rapporto di conformità alle norme SCR-001
-------------------------------------------------------------

ALTRE NORME APPLICATE:
-------------------------------------------------------------
Norma: IEC 62443-4-1:2018
Titolo: Sicurezza per l'automazione industriale - Sviluppo sicuro
Stato: Applicata (requisiti selezionati)
Clausole applicate: 5, 6, 7, 8, 10
Prove: Documentazione SDL SLD-001
-------------------------------------------------------------
Norma: ISO/IEC 27001:2022
Titolo: Gestione della sicurezza delle informazioni
Stato: Organizzazione certificata (Certificato n. 12345)
Rilevanza: l'ISMS copre i processi di sviluppo prodotto
-------------------------------------------------------------
Norma: NIST Cybersecurity Framework 2.0
Titolo: Framework per migliorare la cybersicurezza delle infrastrutture critiche
Stato: Framework di riferimento per la valutazione dei rischi
Prove: Documento di metodologia della valutazione dei rischi
-------------------------------------------------------------

DEVIAZIONI:
-------------------------------------------------------------
Norma: EN 303 645
Clausola: 5.3-2 (Credenziali univoche per dispositivo)
Deviazione: Credenziali univoche per dispositivo ma non pre-provviste
Giustificazione: il dispositivo richiede setup utente; le credenziali
                 sono create durante la prima configurazione
Misura alternativa: requisiti di password robusti applicati,
                    blocco account dopo tentativi falliti
Valutazione del rischio: rischio residuo accettabile (vedi R-015)
-------------------------------------------------------------

Consiglio: Automatizza la generazione dell'SBOM in CI/CD. La creazione manuale di SBOM è soggetta a errori e non scala tra le versioni di prodotto.

Sezione 6: Risultati dei test

Scopo: Fornire prove che i requisiti siano effettivamente soddisfatti.

Contenuto richiesto

CHECKLIST DOCUMENTAZIONE DEI TEST

Pianificazione dei test:
[ ] Piano di test con ambito e obiettivi
[ ] Casi di test mappati ai requisiti
[ ] Descrizione dell'ambiente di test
[ ] Criteri di superamento/fallimento

Esecuzione dei test:
[ ] Registri di esecuzione dei test
[ ] Riepilogo dei risultati dei test
[ ] Test falliti e relativa risoluzione
[ ] Prove di re-test

Tipi di test:
[ ] Test funzionali di sicurezza
[ ] Scansione delle vulnerabilità
[ ] Test di penetrazione (se applicabile)
[ ] Fuzz testing (se applicabile)
[ ] Revisione della configurazione

Formato dei risultati dei test

RIEPILOGO RISULTATI TEST

Prodotto: SmartSense Pro (SSP-3000) v2.4.1
Periodo di test: dicembre 2026 - gennaio 2027
Test Lead: [Nome]

═══════════════════════════════════════════════════════════
CAMPAGNA DI TEST: TC-2027-001
═══════════════════════════════════════════════════════════

1. TEST FUNZIONALI DI SICUREZZA
   Ambito: autenticazione, autorizzazione, cifratura, secure boot
   Casi di test: 85
   Superati: 85
   Falliti: 0
   Riferimento: Rapporto di test TR-FUNC-001

2. SCANSIONE DELLE VULNERABILITÀ
   Strumento: Trivy v0.48.0 + Nessus Professional
   Ambito: firmware, servizi di rete, interfaccia web
   Risultati:
     Critico: 0
     Alto: 0
     Medio: 2 (accettati con giustificazione)
     Basso: 5 (accettati)
   Riferimento: Rapporto di scansione SR-VULN-001

3. TEST DI PENETRAZIONE
   Fornitore: [Nome società terza]
   Ambito: test black-box del dispositivo deployato
   Durata: 5 giorni
   Risultati:
     Critico: 0
     Alto: 0
     Medio: 1 (rimediato prima del rilascio)
     Basso: 3 (accettati)
   Riferimento: Rapporto di pentest PT-2027-001

4. ANALISI DEL FIRMWARE
   Strumento: EMBA v1.3
   Ambito: analisi del binario, credenziali hardcoded, problemi crittografici
   Risultati:
     Critico: 0
     Alto: 0
     Informativo: 4
   Riferimento: Rapporto di analisi del firmware FA-001

5. REVISIONE DELLA CONFIGURAZIONE
   Ambito: sicurezza della configurazione di default
   Risultati: tutti i default soddisfano i requisiti di sicurezza
   Riferimento: Revisione della configurazione CR-001

═══════════════════════════════════════════════════════════
VALUTAZIONE COMPLESSIVA: SUPERATO
Tutti i risultati critici e alti rimediati.
Risultati medio/basso accettati con giustificazione documentata.
═══════════════════════════════════════════════════════════

Sezione 7: Dichiarazione UE di conformità

Scopo: Includere la dichiarazione formale o un riferimento alla stessa.

Contenuto richiesto

Il fascicolo tecnico deve includere una copia della Dichiarazione UE di Conformità o un riferimento al luogo in cui può essere ottenuta.

DICHIARAZIONE UE DI CONFORMITÀ

(Vedi documento DoC separato o includere copia nel fascicolo tecnico)

Riferimento: DoC-SSP3000-2027-001
Data: 1 marzo 2027
Posizione: Fascicolo tecnico, Appendice A

La Dichiarazione UE di Conformità accompagna ciascun prodotto
ed è disponibile per il download all'indirizzo:
https://company.com/support/ssp3000/doc

Sezione 8: Distinta dei materiali software

Scopo: Fornire trasparenza sui componenti per il tracciamento delle vulnerabilità. L'Allegato VII, punto 8, rende l'SBOM parte del fascicolo tecnico su richiesta motivata di un'autorità di sorveglianza del mercato. In pratica, i fabbricanti lo preparano e lo mantengono insieme al resto del fascicolo.

Guide correlate: I prodotti hardware richiedono inoltre un HBOM, e la qualità dell'SBOM è disciplinata da BSI TR-03183. Lo stato di vulnerabilità dei componenti SBOM è comunicato tramite VEX. Vedi la guida ai requisiti SBOM per CycloneDX vs SPDX, livelli di qualità BSI TR-03183, ambito HBOM e uso di VEX; e la guida alla segnalazione delle vulnerabilità per come VEX supporta l'obbligo di "nessuna vulnerabilità sfruttabile nota".

Contenuto richiesto

CHECKLIST REQUISITI SBOM

Formato:
[ ] Formato leggibile dalla macchina (CycloneDX o SPDX)
[ ] Riepilogo leggibile dall'utente

Contenuto:
[ ] Elenco di tutti i componenti software
[ ] Versioni dei componenti specificate
[ ] Informazioni sul fornitore incluse
[ ] Informazioni sulla licenza incluse
[ ] Vulnerabilità note al momento della valutazione

Ambito:
[ ] Dipendenze dirette
[ ] Dipendenze transitive
[ ] Componenti del sistema operativo (se applicabile)
[ ] Librerie di terze parti

Documentazione SBOM

DISTINTA DEI MATERIALI SOFTWARE

Prodotto: SmartSense Pro (SSP-3000)
Versione firmware: 2.4.1
Formato SBOM: CycloneDX 1.5
Generato: 2027-01-15
Strumento: Trivy + syft

FILE SBOM:
sbom-ssp3000-v2.4.1.json (allegato)

RIEPILOGO COMPONENTI:
-------------------------------------------------------------
Totale componenti: 127
  Dipendenze dirette: 23
  Dipendenze transitive: 104

Per tipo:
  Librerie: 98
  Framework: 12
  Sistema operativo: 1 (FreeRTOS)
  Moduli firmware: 16

Per licenza:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Proprietario: 21 (componenti interni)
-------------------------------------------------------------

STATO DELLE VULNERABILITÀ ALLA VALUTAZIONE:
-------------------------------------------------------------
Data scansione: 2027-01-15
Scanner: Trivy v0.48.0

Critico: 0
Alto: 0
Medio: 2 (accettati - vedi sotto)
Basso: 5 (accettati)

VULNERABILITÀ ACCETTATE:
CVE-2026-XXXXX (Medio): Componente xyz v1.2.3
  Stato: non sfruttabile nella nostra configurazione
  Giustificazione: funzionalità non abilitata, percorso di codice non raggiungibile
  Data di revisione: 2027-04-15

CVE-2026-YYYYY (Medio): Componente abc v2.0.1
  Stato: mitigato da controlli di rete
  Giustificazione: richiede accesso locale, dispositivo isolato in rete
  Data di revisione: 2027-04-15
-------------------------------------------------------------

IMPEGNO DI AGGIORNAMENTO SBOM:
L'SBOM sarà aggiornato a ogni rilascio firmware e reso
disponibile ai clienti su richiesta.

Quando va aggiornato il fascicolo tecnico?

Documentazione viva

Il fascicolo tecnico non è statico:

TRIGGER DI AGGIORNAMENTO DEL FASCICOLO TECNICO

AGGIORNAMENTI OBBLIGATORI:
- Nuova versione firmware/software
- Rilascio di patch di sicurezza
- Vulnerabilità rilevata e affrontata
- Modifica progettuale che incide sulla sicurezza
- Aggiornamento delle norme (se cambiano le norme applicate)
- Modifiche all'SBOM (componenti nuovi/aggiornati)

REVISIONI PERIODICHE:
- Trimestrale: SBOM e stato delle vulnerabilità
- Annuale: revisione completa del fascicolo tecnico
- Prima della fine del periodo di supporto: congelamento finale della documentazione

CONTROLLO VERSIONI:
- Tutti i documenti sono versionati
- Storico delle modifiche mantenuto
- Versioni precedenti archiviate

Requisiti di conservazione

CONSERVAZIONE DELLA DOCUMENTAZIONE

Periodo di conservazione: almeno 10 anni dall'immissione sul mercato, oppure il periodo di supporto, se più lungo (articolo 13, paragrafo 13)

Esempio di tempistica:
- Prima immissione del prodotto sul mercato: marzo 2027
- Ultima unità immessa sul mercato: dicembre 2030
- Conservazione della documentazione fino a: dicembre 2040

Requisiti di archiviazione:
- Archiviazione sicura e accessibile
- Procedure di backup
- Protezione dell'integrità
- Disponibile entro [48 ore] dalla richiesta dell'autorità

Errori comuni

Valutazione dei rischi incompleta

Problema: Valutazione dei rischi che non copre tutte le minacce o priva di dettagli sul trattamento.

Correzione: Usare una metodologia strutturata. Mappare ogni rischio identificato a un controllo o a una decisione di accettazione.

SBOM mancante

Problema: Nessun SBOM o SBOM che non include le dipendenze transitive.

Correzione: Generare l'SBOM con strumenti adeguati. Includere l'albero completo delle dipendenze.

Documentazione obsoleta

Problema: Il fascicolo tecnico descrive la versione 1.0 ma il prodotto è alla versione 2.3.

Correzione: Aggiornare la documentazione a ogni rilascio. Tracciare le versioni in modo esplicito.

Nessuna tracciabilità dei requisiti

Problema: Si dichiara conformità senza mostrare come ogni requisito sia soddisfatto.

Correzione: Creare una mappatura esplicita da ogni requisito dell'Allegato I alle prove.

Test senza prove

Problema: Si dichiara di aver eseguito test ma non si dispone dei rapporti.

Correzione: Conservare tutti i rapporti di test. Includerli nel fascicolo tecnico o referenziarli chiaramente.

Lista di controllo del fascicolo tecnico

LISTA DI CONTROLLO COMPLETEZZA DEL FASCICOLO TECNICO

SEZIONE 1 - DESCRIZIONE GENERALE:
[ ] Identificazione del prodotto completa
[ ] Finalità prevista documentata
[ ] Classificazione CRA dichiarata con giustificazione
[ ] Informazioni di immissione sul mercato

SEZIONE 2 - PROGETTAZIONE, SVILUPPO E GESTIONE DELLE VULNERABILITÀ:
[ ] Diagrammi dell'architettura
[ ] Documentazione di progettazione di sicurezza
[ ] Descrizione del processo di sviluppo
[ ] Procedure di gestione delle modifiche
[ ] Metodi di contatto per le vulnerabilità documentati
[ ] Politica CVD pubblicata
[ ] Processo di gestione delle vulnerabilità documentato
[ ] Procedure di reporting ENISA in essere

SEZIONE 3 - VALUTAZIONE DEI RISCHI:
[ ] Metodologia documentata
[ ] Tutti i rischi identificati
[ ] Decisioni di trattamento per ciascun rischio
[ ] Valutazione del rischio residuo

SEZIONE 4 - INFORMAZIONI SUL PERIODO DI SUPPORTO:
[ ] Periodo di supporto dichiarato (date di inizio e fine)
[ ] Elementi dell'articolo 13, paragrafo 8 documentati (durata d'uso, aspettative degli utenti, normativa di settore)
[ ] Giustificazione registrata (tempistiche di supporto dei componenti, contratti clienti, EOL hardware)
[ ] Approvazione della decisione (prodotto, sicurezza, legale)

MAPPATURA ALLEGATO I (a supporto delle Sezioni 5-7):
[ ] Mappatura Allegato I parte I completa
[ ] Mappatura Allegato I parte II completa
[ ] Prove referenziate per ciascun requisito

SEZIONE 5 - NORME:
[ ] Tutte le norme applicate elencate
[ ] Prove di applicazione fornite
[ ] Deviazioni documentate e giustificate

SEZIONE 6 - RISULTATI DEI TEST:
[ ] Piano di test documentato
[ ] Rapporti di test allegati
[ ] Tutti i risultati affrontati

SEZIONE 7 - DoC:
[ ] Dichiarazione di conformità inclusa/referenziata

SEZIONE 8 - SBOM (su richiesta motivata):
[ ] SBOM in formato leggibile dalla macchina preparato (CycloneDX o SPDX)
[ ] Tutti i componenti inclusi (diretti + transitivi)
[ ] Stato delle vulnerabilità documentato
[ ] Disponibile per l'autorità di sorveglianza su richiesta

MANUTENZIONE:
[ ] Controllo versioni stabilito
[ ] Procedure di aggiornamento documentate
[ ] Piano di conservazione in essere