Coordinated vulnerability disclosure e PSIRT sotto il CRA — il playbook di setup

Questo playbook scatta per ogni fabbricante che immette sul mercato UE un prodotto con elementi digitali — il soggetto che porta gli obblighi dell'Articolo 13 del Cyber Resilience Act (Reg. (UE) 2024/2847). Scatta in continuo, non su un incidente: il trigger è il momento in cui un terzo *può* raggiungerti con un vulnerability report, e il momento in cui uno dei tuoi prodotti spediti ha un difetto sfruttato in the wild.

Cosa non è in scope qui: la meccanica di sottomissione del report Art. 14 vero e proprio — quello è il playbook di reporting Art. 14 CRA — e l'intero percorso di valutazione di conformità e marcatura CE, coperto dalla scheda definizione CRA. Questa è la macchina di disclosure e PSIRT che produce i report, non la sottomissione del report.

Clock 1 — la timeline di disclosure del ricercatore. Qualcuno all'esterno ha trovato il bug e intende pubblicare. Hai una finestra di coordinamento misurata in giorni, e parte nell'istante in cui ti raggiunge — cosa che funziona solo se c'è un posto dove raggiungerti.

Clock 2 — il clock di reporting dell'Art. 14. Dalla awareness: 24 ore per l'early warning, 72 ore per la notifica, 14 giorni per il report finale una volta disponibile una misura correttiva per una vulnerabilità sfruttata attivamente (un mese per un incidente grave). Il clock parte dalla awareness e nulla lo ferma (pagina reporting CRA della Commissione). La notifica passa una sola volta attraverso la Single Reporting Platform di ENISA verso il CSIRT dello stabilimento principale, con ENISA notificata in parallelo.

La trappola è il calendario. Gli obblighi di policy CVD e single point of contact dell'Art. 13 vincolano formalmente dall'11 dicembre 2027, ma l'obbligo di reporting Art. 14 che consuma l'output del tuo intake è attivo dall'11 settembre 2026 — quindici mesi prima. Se costruisci l'intake sulla data 2027, la awareness del tuo primo difetto sfruttato attivamente arriverà come un tweet pubblico, con il clock di 24 ore già partito.

Obiettivo: rendere impossibile che un report non abbia dove atterrare. Checklist:

• Pubblica una policy di coordinated vulnerability disclosure a un URL stabile (Allegato I Parte II). Dichiara scope, una safe-harbour statement, i tempi attesi di acknowledgement e fix, e un contatto sicuro (chiave PGP o equivalente). Il materiale ENISA sulla coordinated vulnerability disclosure è il riferimento neutro per la struttura.
• Fornisci un single point of contact per i vulnerability report (Allegato I Parte II) — una casella security@ monitorata più un file security.txt (RFC 9116) in /.well-known/security.txt.
• Crea adesso gli account EU Login per il filer primario e almeno un deputy. La registrazione alla Single Reporting Platform passa da EU Login e l'account può essere creato in anticipo — non scoprire il flusso di sign-up all'ora 20 di un incidente live.
• Identifica il CSIRT ricevente dello stabilimento principale (o della sede del rappresentante autorizzato ex Art. 18) e mettilo nel runbook.
• Classifica ogni prodotto — default, importante o critico ai sensi del Regolamento di esecuzione (UE) 2025/2392 — prima di un incidente, non durante; la classe decide il percorso di notifica.
• Prepara i template skeleton 24h / 72h / finale e conservali dove l'engineer di on-call può raggiungerli alle 02:00.

Quando arriva un report, il PSIRT esegue una sequenza fissa, e i primi due step sono quelli che interessano ad auditor e regolatori:

• Acknowledge e timestamp. Manda ricevuta al ricercatore e apri un caso tracciato con un timestamp. Questo timestamp è il tuo anchor di awareness per l'Art. 14 e deve sopravvivere all'audit senza edit.
• Valuta sfruttata vs sfruttabile. È una vulnerabilità reale in un prodotto che hai immesso sul mercato, ed è sfruttata attivamente? Lo sfruttamento attivo — in the wild, non semplicemente sfruttabile — è il trigger dell'Art. 14 per l'early warning a 24 ore. Sbagliare questa classificazione in una delle due direzioni è l'errore costoso: sovra-notifichi e inondi il CSIRT; sotto-notifichi e manchi una deadline statutaria.
• Fai scoping con l'SBOM. Un difetto in un componente condiviso — una libreria di logging, uno stack TLS — può toccare più tuoi prodotti. L'SBOM machine-readable aggiornato (Allegato I Parte II) è ciò che trasforma un report nella lista corretta di prodotti affetti in minuti invece che in giorni.
• Assegna una CVE tramite la tua CNA, o richiedila; CVE.org documenta il processo CNA. L'id CVE è la maniglia condivisa tra ricercatore, notifica SRP e advisory pubblico.
• Decidi e registra. Supera la soglia dell'Art. 14? Se sì, il clock di 24 ore sta già correndo dal timestamp di acknowledge — passa al playbook di reporting Art. 14 e fila.

• Concorda un embargo e una data di disclosure coordinata con il ricercatore, allineata alla disponibilità del tuo security update. La guida di coordinamento vulnerabilità di FIRST è il riferimento neutro per l'etichetta quando un ricercatore e un vendor devono sincronizzarsi.
• Indirizza la vulnerabilità senza ritardo tramite un security update (Allegato I Parte II). L'update deve essere gratuito e restare disponibile per il periodo di supporto dichiarato.
• Pubblica un advisory una volta disponibile il fix o il workaround (Allegato I Parte II). Non confondere 'abbiamo spedito una patch' con 'abbiamo fatto disclosure' — l'advisory pubblico è un artefatto separato e obbligatorio, e spedire il fix in sordina non lo soddisfa.
• Alimenta l'evidenza di chiusura nel report finale Art. 14, dovuto non oltre 14 giorni dopo che una misura correttiva è disponibile per una vulnerabilità sfruttata attivamente.

Ordinata per quale gate la consuma per prima:

• URL della policy CVD pubblicata + security.txt — la prima cosa che un assessor di sorveglianza del mercato verifica; prova che l'intake esiste.
• Log dei casi di intake con timestamp di acknowledge e chain-of-custody — prova *quando* è iniziata la awareness per ogni report, l'anchor di ogni clock Art. 14.
• Registro di classificazione prodotti (default / importante / critico) legato al percorso di notifica SRP.
• SBOM machine-readable aggiornato (CycloneDX o SPDX) per prodotto spedito, mantenuto build-on-build — lo strumento di scoping.
• Record CVE e registro advisory — le disclosure di vulnerabilità risolte.
• Record di disponibilità e firma degli update — la prova degli update-gratuiti-per-il-periodo-di-supporto.
• Designazione del CSIRT ricevente + registrazione EU Login — prova che puoi effettivamente filare.

Un intake CVD è reattivo per costruzione: aspetta l'email di un ricercatore o che la rete si accenda con una CVE sfruttata in the wild, momento in cui il clock di 24 ore sta già correndo. La metà proattiva è trovare i tuoi difetti per primo e filarli nella stessa coda di triage. È qui che un AI generative pentest guadagna il suo posto — lo swarm a 10 agenti di Zero Hunt scrive exploit per-target contro la tua superficie di prodotto, e le campagne change-triggered ri-testano a ogni build, così un difetto atterra nella coda PSIRT come finding interno con evidenza firmata ECDSA e chain-of-custody (un export Trust Center) prima che un esterno lo veda — esattamente il record documentato di scoperta interna che l'Allegato I Parte II si aspetta.

Osservati nei team prodotto che camminano verso la deadline di settembre 2026:

• Nessun intake, così la prima cosa che senti di un bug è il tweet pubblico del ricercatore — il clock di 24 ore Art. 14 è già consumato e stai filando in ritardo dal giorno uno.
• Trattare l'Art. 13 come un problema del dicembre 2027 mentre l'obbligo di reporting Art. 14 che alimenta è live dall'11 settembre 2026.
• Nessun SBOM aggiornato, così una vulnerabilità in un componente condiviso diventa un esercizio di scoping di più giorni invece che una query — e la notifica a 72 ore elenca i prodotti affetti sbagliati.
• Nessuna relazione CNA e nessuna etichetta di embargo pre-concordata, così il coordinamento collassa in una gara col ricercatore e la disclosure avviene sui suoi tempi, non sui tuoi.
• Confondere 'abbiamo fixato' con 'abbiamo fatto disclosure' — l'advisory pubblico (Allegato I Parte II) è un artefatto distinto e obbligatorio; una patch silenziosa non chiude l'obbligo.
• Nessun on-call di weekend o festivi — un report di sfruttamento attivo il venerdì sera brucia la finestra di 24 ore prima che qualcuno guardi la casella.

L'intake CRA non sta da solo. Quando lo stesso prodotto è operato da un'entità essenziale o importante, un difetto sfruttato attivamente può essere anche un incidente significativo sotto NIS2 Title 13 (24h/72h/1-mese) e, per gli operatori del settore finanziario, sotto DORA — stessa base evidenze sottostante, notifiche diverse, quindi costruisci il record una volta ed esporta per regime.

L'etichetta di disclosure stessa mappa in modo pulito su ISO/IEC 29147 (vulnerability disclosure) e ISO/IEC 30111 (vulnerability handling): se il tuo PSIRT gira già su quegli standard, gli obblighi CRA sono in gran parte un overlay di documentazione e single reporting platform più che un processo nuovo. L'unico elemento davvero nuovo per la maggior parte dei team è il clock statutario: 29147 e 30111 descrivono buone pratiche, ma l'Art. 14 mette una deadline a 24 ore wall-clock davanti — ed è per questo che il timestamp di acknowledge della Fase B è l'artefatto più auditato dell'intera macchina.