Due diligence fornitori CRA: questionario e segnali d'allarme

La diligenza dovuta sui componenti è un obbligo del fabbricante ai sensi dell'articolo 13, paragrafo 5 del Regolamento sulla cibersicurezza. Testo integrale:

«Ai fini dell’adempimento dell’obbligo di cui al paragrafo 1, i fabbricanti esercitano la dovuta diligenza quando integrano componenti provenienti da terzi affinché tali componenti non compromettano la cibersicurezza del prodotto con elementi digitali, anche quando integrano componenti di software liberi e open source che non sono stati messi a disposizione sul mercato nel corso di un’attività commerciale.»

Questa pagina è il complemento operativo agli obblighi del fabbricante. Il quadro normativo, i confini tra ruoli e i controlli lato importatore vivono nelle guide del cluster: fabbricante, importatore, distributore e chi deve conformarsi. Quello che segue è il questionario, i playbook per tipologia di fornitore che le pagine cluster non coprono (FOSS, cloud, hardware-only, OSS steward, firmware COTS modificato) e gli scenari operativi che colpiscono i team negli acquisti reali (fornitori che spariscono, componenti upstream condivisi, arretrati post-fusione, visibilità n-tier).

Perché la diligenza fornitori conta

Anche come fabbricante del suo prodotto, il suo output include componenti provenienti da fornitori: librerie software di terze parti, componenti hardware, moduli firmware, servizi cloud. Le vulnerabilità in quei componenti diventano le sue vulnerabilità, e la sua valutazione di conformità deve considerare i rischi della supply chain.

L'articolo 13, paragrafo 5 rende esplicita quella valutazione. Il CRA non prescrive un formato di questionario, ma un questionario scritto è il modo pratico per documentare che ha verificato la sicurezza del componente, la gestione delle vulnerabilità, la disponibilità del SBOM, gli impegni di assistenza e i percorsi di risposta del fornitore prima dell'integrazione. Senza registri datati, non ha alcuna storia da raccontare a un'autorità di vigilanza del mercato su come è stato gestito il rischio a livello di componente.

Se il suo ruolo su un dato prodotto è anche quello di importatore (porta nell'UE il prodotto di un fabbricante extra-UE), i quattro controlli pre-immissione dell'importatore sono un dovere di verifica separato. Questa guida resta focalizzata sulla diligenza dei componenti lato fabbricante.

Quadro di diligenza dovuta

Approccio per livelli

Non tutti i fornitori richiedono lo stesso livello di scrutinio:

VALUTAZIONE DEI LIVELLI FORNITORI

LIVELLO 1 (Critico):
- Componenti con funzioni di sicurezza (crittografia, autenticazione, firewall)
- Dipendenze software core
- Hardware con firmware
Valutazione: questionario completo + revisione documentazione + monitoraggio continuo

LIVELLO 2 (Significativo):
- Componenti di funzionalità principale
- Elementi connessi alla rete
- Componenti di elaborazione dati
Valutazione: questionario standard + revisione documentazione

LIVELLO 3 (Standard):
- Componenti non di sicurezza
- Librerie di utilità
- Hardware periferico
Valutazione: questionario base + verifiche a campione

LIVELLO 4 (Minimo):
- Componenti commodity
- OSS ben consolidato
- Hardware non connesso
Valutazione: verifica base + inclusione nel SBOM

Aree di valutazione

La sua diligenza dovuta dovrebbe coprire:

Il quadro è generico, ma le prove che ogni tipo di fornitore può effettivamente produrre variano. Le cinque sezioni che seguono lavorano sulle forme di fornitore più comuni e sul percorso di diligenza che si adatta a ciascuna.

Diligenza specifica per i componenti FOSS

L'articolo 13, paragrafo 5 nomina esplicitamente i componenti FOSS: componenti di software liberi e open source che non sono stati messi a disposizione sul mercato nel corso di un'attività commerciale. Il dovere giuridico si applica indipendentemente dal fatto che ci sia o meno uno scambio di denaro. Un questionario firmato con il sangue da un vendor commerciale non è il modello quando l'upstream è un progetto GitHub con tre manutentori.

Per i componenti FOSS non commerciali, l'insieme delle prove passa da documenti attestati dal fornitore a segnali osservabili dal progetto che lei stesso può raccogliere.

CHECKLIST DILIGENZA COMPONENTI FOSS

SALUTE DEL PROGETTO:
[ ] Commit attivi negli ultimi 90 giorni
[ ] Numero di contributori distinti (>1 = riduzione del bus factor)
[ ] Cadenza di rilascio dichiarata o osservabile
[ ] Issue tracker reattivo (tempo mediano alla prima risposta)

POSTURA DI SICUREZZA:
[ ] SECURITY.md presente con indirizzo di divulgazione
[ ] Politica CVD (canale di security advisory privato, non solo issue)
[ ] Storia delle CVE rivista (NVD, GitHub Security Advisories, OSV)
[ ] Gli ingredienti del SBOM sono a loro volta riconoscibili, non fork profondi

LICENZA E PROVENIENZA:
[ ] L'identificatore SPDX corrisponde a quanto dichiarato dai metadati del pacchetto
[ ] Nessuna dipendenza transitiva con licenza incompatibile
[ ] Gli artefatti rilasciati hanno una provenienza verificabile (es. SLSA, sigstore)

PIANO DI RIPIEGO:
[ ] Identificato il target di fork se l'upstream tace
[ ] Capacità interna di patch dichiarata (quale ingegnere, quale codice)
[ ] Candidati di sostituzione elencati, con stima dello sforzo di sostituzione

Due regole operative. Primo, l'articolo 13, paragrafo 6 impone che le vulnerabilità che trova in un componente FOSS siano segnalate al progetto upstream e che qualunque correzione lei produca sia restituita, in formato leggibile da un dispositivo automatico ove opportuno. La voce del questionario che sta verificando non è l'impegno dell'upstream verso di lei: è il suo stesso impegno a far fluire vulnerabilità e patch indietro. Secondo, un upstream silenzioso non estingue il suo dovere. Se il progetto diventa inattivo, il suo piano di ripiego (fork, patch interne, sostituzione) fa parte del registro di diligenza, non è un problema futuro.

Per i progetti sostenuti da una fondazione o da un soggetto giuridico che agisce come gestore di software open source, lo schema di diligenza cambia di nuovo. Quel caso è nella sezione successiva.

OSS steward vs fornitore commerciale

Una classe piccola ma importante di upstream è gestita da un gestore di software open source: un soggetto giuridico, tipicamente una fondazione, il cui scopo principale è sostenere specifici progetti open source destinati a un uso commerciale. La Linux Foundation, la Eclipse Foundation e l'Apache Software Foundation sono esempi tipici. Gli steward rientrano nell'articolo 24, non nell'articolo 13. L'insieme dei doveri è più stretto (una politica di cibersicurezza documentata, un dovere di cooperazione con la vigilanza del mercato, applicazione parziale della segnalazione di incidenti dell'articolo 14), e lo steward non è il fabbricante di alcun prodotto commerciale a valle.

Per il confine fabbricante / steward, consulti gestori open source.

La conseguenza in termini di diligenza per lei, come integratore a valle, è che la forma del questionario è diversa.

Quello che continua a fare: controlli sulla salute del progetto, ingestione del SBOM, monitoraggio CVE, il suo piano di fork-and-patch. Quello che smette di aspettarsi: SLA contrattuali di notifica delle vulnerabilità, livelli di assistenza a pagamento, clausole di audit. Il registro di diligenza per un componente sostenuto da uno steward è più leggero sulla carta del fornitore e più pesante sui suoi controlli interni rispetto a un vendor commerciale, e questa è la forma giuridicamente corretta.

Diligenza sui componenti cloud-service

Quando il «componente» dentro il suo prodotto è un'API o un servizio gestito (un SaaS di autenticazione, un message broker gestito, una funzione serverless, un database cloud), lo schema di prova è ancora diverso. Non c'è DoC, non c'è SBOM, non c'è codice sorgente che lei spedisce. C'è un contratto, un portafoglio di attestazioni di sicurezza e un modello di responsabilità condivisa.

DILIGENZA COMPONENTI CLOUD-SERVICE

ATTESTAZIONI DI SICUREZZA:
[ ] Rapporto SOC 2 Type II (corrente)
[ ] Certificato ISO/IEC 27001 (corrente, verifica dello scope)
[ ] ISO/IEC 27017 (controlli specifici per il cloud) dove pertinente
[ ] ISO/IEC 27018 (PII in cloud pubblico) dove rientrano dati personali

PROVE OPERATIVE:
[ ] Pagina di stato con storico incidenti e post-mortem
[ ] RTO/RPO pubblicati e data dell'ultimo test di DR
[ ] Elenco dei sub-processor e processo di notifica delle modifiche
[ ] Accordo sul trattamento dei dati con residenza dati UE, ove applicabile

RESPONSABILITÀ CONDIVISA:
[ ] Ambito di responsabilità del provider documentato
[ ] Ambito della sua responsabilità riconosciuto (configurazione, identità, segreti, rete)
[ ] Accesso a log e audit trail per il suo ambito di responsabilità

ADIACENTI AL CRA:
[ ] Percorso di divulgazione vulnerabilità per l'API stessa
[ ] Orologio di notifica violazioni nel contratto (ore, non «tempestivamente»)
[ ] Finestra di preavviso per la dismissione del servizio (tipicamente 12 mesi)

Il CRA non regola direttamente il provider cloud quando il provider non sta immettendo sul mercato un prodotto con elementi digitali. Il suo dovere ai sensi dell'articolo 13, paragrafo 5 è dimostrare che la dipendenza cloud non compromette la cibersicurezza del suo prodotto. Il deliverable è il portafoglio di attestazioni più una dichiarazione scritta di responsabilità condivisa, non un questionario in forma CRA.

Diligenza su fornitori hardware-only e ODM

Quando il suo contract manufacturer (ODM, EMS, assemblatore in stile OEM) spedisce schede fisiche e il firmware è il suo, il fornitore fornisce il substrato hardware ma non l'inviluppo di sicurezza. Il CRA pone l'inviluppo di sicurezza su di lei, il soggetto che flasha e firma il firmware che va sulla scheda.

Il questionario qui è più leggero sulle domande software e più pesante sulla fiducia hardware e sull'integrità della supply chain.

DILIGENZA HARDWARE-ONLY / ODM

FIDUCIA HARDWARE:
[ ] BOM con identificazione dei componenti di livello crittografico
[ ] Controlli anti-contraffazione (audit sull'approvvigionamento dei componenti)
[ ] Origine del secure element e metodo di pre-provisioning
[ ] Processo di iniezione delle chiavi in fabbrica e audit trail

INTEGRITÀ DI ASSEMBLAGGIO:
[ ] Sistema di qualità ISO 9001 in essere
[ ] Sigilli anti-manomissione applicati durante assemblaggio e spedizione
[ ] Tracciabilità per lotto/serie dalla fabbrica alla banchina di ricezione

CONSEGNA DEL FIRMWARE:
[ ] Chi firma il firmware: lei, l'ODM o entrambi
[ ] Stato di provisioning al primo avvio (default di fabbrica, trasferimento di proprietà)
[ ] Bootloader e catena di secure boot, chi possiede ciascun anello

POST-SPEDIZIONE:
[ ] Finestra di preavviso EOL per la piattaforma hardware
[ ] Impegno di last-time-buy e relativa durata
[ ] Disponibilità di parti di ricambio per il periodo di assistenza che si impegna

Un errore operativo comune: firmare un periodo di assistenza pluriennale con un ODM la cui finestra EOL hardware è di 18 mesi. L'orologio del periodo di assistenza CRA parte quando lei immette il prodotto sul mercato UE; se il silicio sottostante va in EOL dentro quella finestra, l'obbligo di assistenza non si trasferisce alla tolleranza del suo cliente.

Firmware COTS che lei modifica

Se prende un prodotto commerciale off-the-shelf, ne modifica il firmware e immette il risultato sul mercato UE, l'articolo 22 la considera fabbricante del prodotto modificato per la parte interessata dalla modifica sostanziale, o per l'intero prodotto se la modifica tocca l'inviluppo di cibersicurezza.

«Una persona fisica o giuridica, diversa dal fabbricante, dall’importatore o dal distributore, che apporta una modifica sostanziale a un prodotto con elementi digitali e mette tale prodotto a disposizione sul mercato è considerata un fabbricante ai fini del presente regolamento.»

La conseguenza in termini di diligenza è ampia: la DoC e la valutazione della conformità del fabbricante originario non coprono più il prodotto come lei lo immette sul mercato. Eredita l'insieme dei doveri del fabbricante per la parte interessata o per l'intero prodotto. Il fornitore originario diventa irrilevante per il fascicolo CRA; il suo team di ingegneria diventa il soggetto chiamato a rispondere.

Il passo di diligenza qui non è quindi un questionario al vendor originario. È una valutazione interna di impatto della modifica. Documenti l'ambito della modifica, decida se è sostanziale e tratti il tutto come lavoro in ambito fabbricante se la modifica tocca autenticazione, cifratura, superficie di rete o meccanismo di aggiornamento. Un registro pulito di quale modifica è stata applicata a quale lotto di unità è l'artefatto che un'autorità di vigilanza del mercato chiederà per prima.

Il questionario

Usi questo questionario come punto di partenza per vendor software e hardware commerciali. Le sezioni precedenti coprono le varianti per FOSS, OSS steward, API cloud, ODM hardware-only e firmware COTS modificato.

Sezione 1: informazioni aziendali

QUESTIONARIO DI DUE DILIGENCE FORNITORE
Sezione 1: informazioni aziendali

1.1 Dettagli azienda
    Nome azienda: _________________________________
    Indirizzo legale: ________________________________
    Paese di costituzione: _____________________
    Contatto principale: _____________________________
    Contatto sicurezza: ____________________________

1.2 Informazioni commerciali
    Anni di attività: ___________________________
    Numero di dipendenti: _________________________
    Fatturato annuo (intervallo): ______________________

1.3 Rappresentanza UE (se extra-UE)
    Nome + indirizzo del mandatario autorizzato UE: __
    (Per il dettaglio completo sulla cascata del
    mandatario e sul routing dell'importatore quando
    non esiste stabilimento UE, consulti la guida del
    cluster importatore:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certificazioni (allegare copie)
    [ ] ISO 9001 (gestione qualità)
    [ ] ISO 27001 (sicurezza delle informazioni)
    [ ] ISO 27701 (privacy)
    [ ] SOC 2
    [ ] Altro: _________________________________

Sezione 2: conformità del prodotto

Sezione 2: conformità del prodotto

2.1 Identificazione prodotto
    Nome/modello prodotto: __________________________
    Versione/revisione: ___________________________
    Categoria prodotto: ___________________________

2.2 Classificazione CRA
    [ ] Default
    [ ] Important Classe I (allegato III, parte I)
    [ ] Important Classe II (allegato III, parte II)
    [ ] Critical (allegato IV)
    [ ] Non ancora classificato

2.3 Valutazione della conformità
    [ ] Modulo A (autovalutazione)
    [ ] Modulo B+C (esame UE del tipo)
    [ ] Modulo H (garanzia qualità totale)
    [ ] Non ancora completata

    Se Modulo B, C o H:
    Nome organismo notificato: __________________________
    Numero certificato: __________________________
    Data certificato: ____________________________

2.4 Dichiarazione UE di conformità
    [ ] DoC disponibile (allegare copia)
    [ ] DoC non ancora emessa
    Data della DoC: ________________________________

2.5 Marcatura CE
    [ ] Marcatura CE apposta
    [ ] Marcatura CE non ancora apposta
    Se apposta, dove sul prodotto: _________________

2.6 Documentazione tecnica
    [ ] Fascicolo tecnico disponibile su richiesta
    [ ] SBOM disponibile (formato: ________________)
    [ ] Documentazione della valutazione dei rischi disponibile
    [ ] Istruzioni utente/sicurezza disponibili

Sezione 3: pratiche di sicurezza

Sezione 3: pratiche di sicurezza

3.1 Sviluppo sicuro
    Seguite un ciclo di sviluppo sicuro?
    [ ] Sì, descrivere: __________________________
    [ ] No

    Conducete test di sicurezza?
    [ ] Analisi statica (SAST)
    [ ] Analisi dinamica (DAST)
    [ ] Test di penetrazione
    [ ] Fuzz testing
    [ ] Altro: _________________________________

    Avete uno standard di codifica sicura?
    [ ] Sì, quale: ____________________________
    [ ] No

3.2 Gestione componenti
    Come tracciate i componenti di terze parti?
    [ ] SBOM mantenuto
    [ ] Strumento di tracking delle dipendenze (nome: _________)
    [ ] Tracking manuale
    [ ] Non tracciato sistematicamente

    Come monitorate le vulnerabilità nelle dipendenze?
    [ ] Scansione automatizzata (strumento: _______________)
    [ ] Monitoraggio CVE manuale
    [ ] Affidamento sulle notifiche del vendor
    [ ] Nessun monitoraggio sistematico

3.3 Architettura di sicurezza
    Descrivere le principali caratteristiche di sicurezza del prodotto:
    _____________________________________________

    Quali standard crittografici sono usati?
    _____________________________________________

    Come è implementata l'autenticazione?
    _____________________________________________

    Come sono protetti i dati a riposo e in transito?
    _____________________________________________

Sezione 4: gestione delle vulnerabilità

Sezione 4: gestione delle vulnerabilità

4.1 Divulgazione vulnerabilità
    Avete una politica di divulgazione coordinata delle vulnerabilità?
    [ ] Sì, URL: ______________________________
    [ ] No

    Avete un file security.txt?
    [ ] Sì, URL: ______________________________
    [ ] No

    Qual è il metodo di contatto sicurezza?
    [ ] Email: __________________________________
    [ ] Modulo web: _______________________________
    [ ] Piattaforma bug bounty: ____________________
    [ ] Altro: _________________________________

4.2 Impegni di risposta
    Qual è il tempo di acknowledgment?
    [ ] Entro 24 ore
    [ ] Entro 72 ore
    [ ] Entro 7 giorni
    [ ] Nessun impegno

    Qual è la tipica timeline di patch per:
    Vulnerabilità critiche: ___________________
    Vulnerabilità alte: _______________________
    Vulnerabilità medie: _____________________

4.3 Segnalazione a ENISA
    Siete preparati per la segnalazione a ENISA (settembre 2026)?
    [ ] Sì, processo stabilito
    [ ] In corso
    [ ] No
    [ ] Non applicabile (non fabbricante)

4.4 Vulnerabilità storiche
    Quante vulnerabilità di sicurezza sono state segnalate
    in questo prodotto negli ultimi 24 mesi? ______

    Come sono state risolte?
    [ ] Tutte patchate entro le timeline dichiarate
    [ ] Alcuni ritardi (spiegare): __________________
    [ ] Alcune restano senza patch (spiegare): ________

Sezione 5: aggiornamenti e assistenza

Sezione 5: aggiornamenti e assistenza

5.1 Periodo di assistenza
    Qual è il periodo di assistenza impegnato dall'immissione
    sul mercato?
    [ ] 5 anni (minimo CRA)
    [ ] 7 anni
    [ ] 10 anni
    [ ] Altro: _________________________________
    [ ] Non definito

    Quando questo prodotto è stato immesso per la prima volta sul mercato UE?
    Data: ______________________________________

    Quando termina il periodo di assistenza?
    Data: ______________________________________

5.2 Meccanismo di aggiornamento
    Come vengono consegnati gli aggiornamenti di sicurezza?
    [ ] Aggiornamenti automatici (OTA)
    [ ] Download manuale da portale
    [ ] Supporto fisico
    [ ] Altro: _________________________________

    Gli aggiornamenti di sicurezza sono separati da quelli funzionali?
    [ ] Sì
    [ ] No, raggruppati insieme

    Gli utilizzatori possono rimandare o saltare gli aggiornamenti?
    [ ] Sì
    [ ] No, obbligatori
    [ ] Configurabile

5.3 Verifica aggiornamenti
    Gli aggiornamenti sono firmati?
    [ ] Sì, metodo: __________________________
    [ ] No

    Gli utilizzatori possono verificare l'autenticità degli aggiornamenti?
    [ ] Sì, come: _____________________________
    [ ] No

5.4 Pianificazione fine assistenza
    Avete un processo EOL documentato?
    [ ] Sì
    [ ] No

    Come saranno notificati i clienti dell'EOL?
    _____________________________________________

    Cosa succede dopo la fine del periodo di assistenza?
    [ ] Il prodotto continua a funzionare
    [ ] Il prodotto perde funzionalità
    [ ] Il prodotto richiede migrazione

Sezione 6: requisiti di documentazione

Sezione 6: requisiti di documentazione

6.1 Documentazione disponibile
    Marcare tutta la documentazione che potete fornire:

    [ ] Dichiarazione UE di conformità
    [ ] Fascicolo tecnico (o estratti pertinenti)
    [ ] Software Bill of Materials (SBOM)
        Formato: [ ] CycloneDX [ ] SPDX [ ] Altro
    [ ] Sintesi della valutazione dei rischi
    [ ] Documento di architettura di sicurezza
    [ ] Istruzioni utente (rilevanti per la sicurezza)
    [ ] Politica di divulgazione vulnerabilità
    [ ] Termini di assistenza/manutenzione

6.2 Consegna della documentazione
    Come sarà fornita la documentazione?
    [ ] Su richiesta (tempo di risposta: ____________)
    [ ] Tramite portale sicuro
    [ ] Inclusa con il prodotto
    [ ] Altro: _________________________________

6.3 Dettagli del SBOM (se disponibile)
    Il SBOM copre:
    [ ] Solo dipendenze dirette
    [ ] Dipendenze transitive incluse
    [ ] Componenti hardware (se applicabile)

    Frequenza di aggiornamento del SBOM:
    [ ] Per release
    [ ] Su richiesta
    [ ] Non aggiornato sistematicamente

Sezione 7: impegni contrattuali

Sezione 7: impegni contrattuali

7.1 Garanzia di conformità
    Garantirete la conformità CRA nel contratto?
    [ ] Sì
    [ ] No
    [ ] Negoziabile

7.2 Conservazione documentazione
    Conserverete la documentazione tecnica per 10 anni?
    [ ] Sì
    [ ] No
    [ ] Periodo più breve: ________________________

7.3 Obblighi di notifica
    Ci notificherete:
    [ ] Vulnerabilità di sicurezza nel prodotto
    [ ] Cambiamenti nello stato di conformità
    [ ] Decisioni di fine assistenza
    [ ] Cambiamenti materiali all'architettura di sicurezza

7.4 Diritti di audit
    Permetterete audit di conformità?
    [ ] Sì, senza restrizioni
    [ ] Sì, con preavviso
    [ ] No

7.5 Indennizzo
    Indennizzerete per non conformità CRA?
    [ ] Sì
    [ ] No
    [ ] Negoziabile

Sezione 8: attestazione

Sezione 8: attestazione

Attesto che le informazioni fornite in questo questionario
sono accurate e complete al meglio delle mie conoscenze.

Comprendo che [La Vostra Azienda] si affida a queste informazioni
ai fini della conformità CRA e che false dichiarazioni materiali
possono comportare la risoluzione del contratto.

Compilato da: _____________________________________
Titolo: ___________________________________________
Data: _____________________________________________
Firma: ____________________________________________

Segnali d'allarme (segnali pre-contratto)

Questi segnali d'allarme vanno colti durante la revisione del questionario e la negoziazione contrattuale, prima che venga firmato qualsiasi ordine di acquisto. Per lo specchio lato importatore, applicato al momento dell'immissione sul mercato UE del prodotto di un fabbricante extra-UE, consulti cosa rifiutare e perché sulla pagina cluster dell'importatore.

Segnali d'allarme critici (squalificano la relazione)

Segnali d'allarme seri (richiedono mitigazione negoziata)

Segnali gialli (monitorare lungo la relazione)

Processo di verifica e monitoraggio

Verifica iniziale

1. Raccolta documenti

   • Richiedere copia della DoC
   • Richiedere il SBOM (o conferma di disponibilità)
   • Richiedere le informazioni di contatto sicurezza
   • Richiedere l'impegno sul periodo di assistenza

2. Revisione documenti

   • Verificare che la DoC sia firmata e completa
   • Verificare che l'identificazione del prodotto corrisponda
   • Verificare le dichiarazioni di marcatura CE
   • Rivedere formato e completezza del SBOM

3. Verifiche a campione di conformità

   • Verificare che security.txt esista (se accessibile via web)
   • Verificare che la politica CVD sia pubblicata
   • Testare che il contatto sicurezza risponda
   • Verificare le dichiarazioni sul periodo di assistenza nella documentazione

Monitoraggio continuo

CALENDARIO DI MONITORAGGIO FORNITORI

Mensile:
[ ] Verificare gli avvisi di sicurezza pubblicati
[ ] Verificare che il contatto sicurezza sia ancora attivo
[ ] Rivedere eventuali divulgazioni di vulnerabilità

Trimestrale:
[ ] Richiedere il SBOM aggiornato (in caso di release significative)
[ ] Verificare che la politica CVD sia ancora accessibile
[ ] Verificare nuove certificazioni o scadenze

Annuale:
[ ] Refresh completo del questionario
[ ] Rivedere lo stato del periodo di assistenza
[ ] Verificare che la documentazione sia ancora disponibile
[ ] Revisione di stabilità aziendale

Su trigger:
[ ] Incidente di sicurezza grave -> revisione immediata
[ ] Cambio di proprietà -> rivalutazione completa
[ ] Dismissione del prodotto -> pianificazione EOL
[ ] Rinnovo contratto -> riverifica della conformità

Quando un fornitore non risponde

Il singolo fallimento operativo più comune nella diligenza fornitori non è una risposta al questionario insoddisfacente: è l'assenza di qualsiasi risposta. Il fornitore sparisce, prende tempo per mesi o invia una risposta di una riga del tipo «siamo conformi a tutte le normative applicabili». Non esiste sanzione statutaria contro il fornitore (non ha alcun dovere CRA di rispondere al suo questionario), quindi il flusso di escalation deve essere commerciale e procedurale.

ESCALATION FORNITORE NON RISPONDENTE

SETTIMANA 1: questionario iniziale inviato
             Finestra di risposta ragionevole: 15 giorni lavorativi
             per il Livello 1, 30 per il Livello 2, 45 per i Livelli 3-4.

SETTIMANA 3: primo sollecito al contatto sicurezza nominato e al
             contatto commerciale primario. In copia il responsabile acquisti.

SETTIMANA 5: escalation all'account executive del fornitore e al
             suo direttore acquisti. Fissare una data perentoria.

SETTIMANA 7: se ancora nessuna risposta sostanziale:
             a) Documentare il mancato riscontro nel fascicolo fornitore
             b) Marcare il componente come «conformità non verificata»
             c) Avviare la valutazione di un fornitore sostitutivo
             d) Avvisare i product owner che dipendono dal componente

SETTIMANA 9: punto di decisione.
             Risposta sostanziale ricevuta -> procedere alla revisione.
             Nessuna risposta -> passare al fornitore sostitutivo e
             documentare il cambio come decisione guidata dal CRA.

Il mancato riscontro è esso stesso prova di diligenza. Un'autorità di vigilanza del mercato che chiede perché ha interrotto un fornitore accetterà molto più volentieri una traccia di escalation datata e una decisione di switch piuttosto che un vago «era difficile lavorarci». L'artefatto da conservare è il log di escalation datato e il memo di decisione.

Componenti upstream condivisi e vetting coordinato

Quando più fabbricanti integrano lo stesso componente upstream (una libreria crittografica largamente usata, un SDK comune di elaborazione immagini, un OS embedded popolare), ciascun fabbricante a valle porta il proprio dovere ai sensi dell'articolo 13, paragrafo 5. Il dovere non si trasferisce al peer più diligente, e «lo usano tutti gli altri» non è una difesa.

Esistono due schemi di coordinamento che riducono il lavoro duplicato senza scaricare il dovere:

Il registro di diligenza dovrebbe nominare esplicitamente la fonte del vetting condiviso: «rapporto di revisione dal [gruppo di lavoro], datato [X], rivisto e accettato il [Y], gap tracciati in [sistema]». Un copia-incolla dal fascicolo di diligenza di un peer non sostituisce il suo proprio registro di decisione.

Post-fusione: relazioni fornitori ereditate

Quando la sua azienda acquisisce un'altra azienda, ne acquisisce anche l'elenco fornitori. Una realtà post-fusione comune è di decine o centinaia di relazioni fornitori senza alcun registro di diligenza in forma CRA. Il lavoro non può essere fatto da un giorno all'altro, ma una triage è realizzabile entro un singolo trimestre.

TRIAGE FORNITORI POST-FUSIONE (90 GIORNI)

GIORNO 1-15: inventario
[ ] Estrarre l'elenco fornitori dall'ERP / sistema acquisti dell'entità acquisita
[ ] Incrociare con le BOM dei prodotti correnti
[ ] Identificare quali fornitori alimentano prodotti in ambito CRA
[ ] Escludere dalla triage attiva i fornitori fuori ambito

GIORNO 15-30: classificazione per livello
[ ] Applicare il modello a livelli all'elenco ereditato
[ ] Etichettare i fornitori senza registro di diligenza esistente
[ ] Segnalare i fornitori i cui prodotti rientrano in Important Classe II o Critical

GIORNO 30-60: questionari di Livello 1
[ ] Inviare il questionario a ogni fornitore di Livello 1 senza registro
[ ] Reinviare a ogni fornitore di Livello 1 il cui registro è più vecchio di 24 mesi
[ ] Raccogliere le risposte in modo centralizzato

GIORNO 60-90: punto di decisione
[ ] Fornitori di Livello 1 con risposte soddisfacenti -> integrati
[ ] Fornitori di Livello 1 con segnali d'allarme -> piano di mitigazione o sostituzione
[ ] Fornitori di Livello 2/3 -> inseriti nel ciclo annuale standard

CONTINUO:
[ ] Inserire i fornitori ereditati nel normale calendario di monitoraggio
[ ] Etichettare l'origine «acquisito via fusione» nel record fornitore per audit

Il CRA non concede un periodo di grazia per le fusioni; l'entità acquirente eredita l'obbligo di fabbricante alla data di chiusura dell'acquisizione, sui componenti attualmente nei prodotti spediti. La triage sopra è il compromesso pratico: dimostrare che un programma di diligenza difendibile è in corso, anche se il registro completo è in fase di ricostruzione.

Visibilità del subappalto n-tier

Il suo fornitore di Livello 1 può a sua volta subappaltare a un fornitore di Livello 2, che integra componenti da un upstream di Livello 3. Il dovere CRA è suo indipendentemente da dove nella catena origina la vulnerabilità. La visibilità pratica, però, si esaurisce rapidamente oltre il Livello 1.

Tre controlli concreti che comprano vera visibilità n-tier:

• Clausola di SBOM transitivo. Il contratto richiede che il SBOM del fornitore includa le dipendenze transitive, non solo quelle dirette. Un SBOM solo diretto nasconde quasi tutta la superficie di rischio effettiva.
• Elenco sub-processor / subappaltatori. Il contratto richiede che il fornitore divulghi e aggiorni l'elenco dei subappaltatori nominati che toccano parti rilevanti per la sicurezza del componente. La clausola non le dà un veto, ma le dà visibilità.
• Pass-through delle vulnerabilità. Il contratto richiede che il fornitore faccia fluire le vulnerabilità scoperte nei componenti integrati in modo transitivo verso di lei nella stessa tempistica delle vulnerabilità nel codice sviluppato direttamente.

Senza un SBOM transitivo non può eseguire scansioni del dependency tree contro il componente e non può dimostrare a un'autorità di vigilanza del mercato che il rischio n-tier è stato valutato. Senza un elenco dei sub-processor, un cambio upstream di subappaltatore (con la sua propria provenienza, i suoi controlli e il suo bus factor) è invisibile a lei. Senza il pass-through delle vulnerabilità, il silenzio del fornitore di Livello 1 su un problema di Livello 2 diventa il suo silenzio su un incidente di sicurezza.

Clausole dell'accordo fornitore

Includa queste disposizioni nei contratti con i fornitori. Ogni clausola è l'aggancio contrattuale di uno dei risultati di diligenza sopra.

Dichiarazione di conformità:

Il Fornitore dichiara e garantisce che il/i Prodotto/i
sono conformi al Regolamento (UE) 2024/2847 (Regolamento
sulla cibersicurezza) e che il Fornitore ha completato
la valutazione della conformità richiesta.

Fornitura di documentazione:

Il Fornitore fornirà su richiesta:
(a) Copia della Dichiarazione UE di Conformità
(b) Software Bill of Materials in formato [CycloneDX/SPDX],
    comprese le dipendenze transitive
(c) Documentazione tecnica rilevante per gli obblighi
    di conformità dell'Acquirente
Tempo di risposta: [5 giorni lavorativi]

Notifica di vulnerabilità:

Il Fornitore notificherà l'Acquirente entro [24/48] ore
dal venire a conoscenza di qualsiasi vulnerabilità di
sicurezza nel/i Prodotto/i o in qualsiasi componente
integrato in modo transitivo che:
(a) È attivamente sfruttata, o
(b) Ha un punteggio CVSS di 7.0 o superiore, o
(c) È soggetta a divulgazione pubblica

Impegno periodo di assistenza:

Il Fornitore si impegna a fornire aggiornamenti di sicurezza
per il/i Prodotto/i per un periodo minimo di [5/7/10] anni
dalla data di prima immissione sul mercato nell'UE.

Aggiornamenti SBOM:

Il Fornitore fornirà un SBOM aggiornato entro [10]
giorni lavorativi da ogni release del prodotto che includa
modifiche a componenti di terze parti diretti o transitivi.

Diritti di audit:

L'Acquirente può auditare la conformità del Fornitore con
il presente Accordo e con i requisiti CRA applicabili previo
preavviso scritto di [30 giorni], non più di una volta l'anno
salvo che sia attivato da un problema di conformità.

Divulgazione subappaltatori:

Il Fornitore manterrà e fornirà su richiesta un elenco dei
subappaltatori che contribuiscono o hanno accesso a componenti
rilevanti per la sicurezza del/i Prodotto/i. Il Fornitore
notificherà all'Acquirente qualsiasi cambiamento materiale
di tale elenco entro [30] giorni.

Errori comuni

Affidarsi all'auto-attestazione

Problema: accettare le rassicurazioni verbali del fornitore senza documentazione.

Correzione: ottenere sempre prove scritte. Nessuna copia DoC, nessun acquisto. Un questionario firmato è il pavimento, non il soffitto.

Valutazione una tantum

Problema: diligenza dovuta solo alla firma del contratto.

Correzione: implementare il calendario di monitoraggio sopra. Lo stato di conformità cambia; i questionari scadono.

Ignorare i fornitori di Livello 3-4

Problema: valutare solo i fornitori «principali» ignorando quelli più piccoli.

Correzione: anche i componenti minori introducono vulnerabilità (la lezione log4j). Scali la valutazione, non salti il livello.

Nessun supporto contrattuale

Problema: affidarsi alla buona volontà del fornitore senza termini contrattuali.

Correzione: mettere gli obblighi di conformità per iscritto. Le clausole sopra sono il pavimento.

Aspettare fino a dicembre 2027

Problema: avviare le valutazioni dei fornitori proprio prima della data di applicazione del CRA.

Correzione: iniziare ora. Le risposte dei vendor ritardano. I fornitori non conformi hanno bisogno di mesi per rimediare o essere sostituiti.

Checklist di diligenza fornitore

CHECKLIST DI DILIGENZA FORNITORE

PRE-IMPEGNO:
[ ] Livello fornitore determinato (1/2/3/4)
[ ] Tipo fornitore determinato (commerciale, FOSS, OSS steward,
    cloud, hardware-only, COTS modificato)
[ ] Variante appropriata del questionario selezionata
[ ] Revisore interno assegnato

VALUTAZIONE INIZIALE:
[ ] Questionario inviato
[ ] Questionario ricevuto e revisionato
[ ] Segnali d'allarme identificati e affrontati
[ ] Documentazione raccolta:
    [ ] Dichiarazione UE di conformità (o motivo di N/A)
    [ ] SBOM con dipendenze transitive (o disponibilità confermata)
    [ ] Politica CVD
    [ ] Impegno periodo di assistenza
[ ] Verifiche a campione completate:
    [ ] security.txt verificato
    [ ] Contatto sicurezza testato
    [ ] Marcatura CE verificata

NEGOZIAZIONE CONTRATTO:
[ ] Clausole di conformità incluse
[ ] Disposizioni di documentazione concordate
[ ] Termini di notifica vulnerabilità fissati (ore, non «tempestivamente»)
[ ] Impegno periodo di assistenza assicurato
[ ] Diritti di audit inclusi
[ ] Calendario di aggiornamento SBOM concordato
[ ] Clausola di divulgazione subappaltatori inclusa

POST-CONTRATTO:
[ ] Calendario di monitoraggio stabilito
[ ] Prima consegna documentazione confermata
[ ] Contatti registrati nel sistema di gestione fornitori
[ ] Date di revisione calendarizzate

CONTINUO:
[ ] Verifiche mensili completate
[ ] Revisioni trimestrali completate
[ ] Rivalutazione annuale completata
[ ] Eventi trigger gestiti (incidente, cambio proprietà, EOL)

Guide correlate

• Come generare un SBOM conforme al CRA: strumenti, formati e integrazione CI/CD
• La guida del fabbricante CRA
• Checklist del distributore CRA

Questo articolo è solo a scopo informativo e non costituisce consulenza legale. Per indicazioni specifiche sulla conformità, consulti un consulente legale qualificato.