PSIRT in una PMI: chi lo fa e come partire in due
Il PSIRT (Product Security Incident Response Team) è il gruppo che, in un'azienda, riceve le segnalazioni di vulnerabilità sui prodotti, le valuta, decide che cosa fare e tiene i rapporti con chi segnala, con i clienti e con le autorità. Nelle grandi aziende è una squadra dedicata. Il Cyber Resilience Act (CRA) ne richiede nei fatti le funzioni a ogni fabbricante, anche a chi ha trenta dipendenti e nessun informatico di prodotto. Qui spieghiamo che cosa deve fare, chi può farlo in una PMI e come partire in quattro settimane.
In sintesi
Il regolamento non usa la parola PSIRT e non impone una struttura. Chiede però che ogni fabbricante gestisca le vulnerabilità dei suoi prodotti per tutto il periodo di assistenza (articolo 13, paragrafo 8) e ne descrive le attività nell'Allegato I, Parte II, dalla ricezione delle segnalazioni agli aggiornamenti di sicurezza gratuiti. A queste si aggiunge la segnalazione entro 24 ore delle vulnerabilità attivamente sfruttate (articolo 14). Un PSIRT è il nome che l'industria dà a chi fa queste cose con continuità. In una PMI può essere composto da due persone, purché abbiano un processo, un registro e un sostituto.
Le funzioni richieste
| Funzione | Che cosa significa | Riferimento |
|---|---|---|
| Ricevere | Un contatto pubblico per le segnalazioni e una politica che dice come vengono trattate | All. I, Parte II, p. 5 e 6 |
| Conoscere | Sapere quali componenti contiene ogni prodotto, con la SBOM, e seguire gli avvisi dei fornitori | All. I, Parte II, p. 1; art. 13, par. 5 |
| Valutare | Decidere se una vulnerabilità tocca il prodotto, con quale gravità e in quali versioni | All. I, Parte II, p. 1 e 2 |
| Correggere | Preparare e distribuire l'aggiornamento di sicurezza, senza ritardo e gratuitamente | All. I, Parte II, p. 2, 7 e 8 |
| Comunicare | Pubblicare le informazioni sulle vulnerabilità corrette; informare i clienti; segnalare alle autorità le vulnerabilità sfruttate | All. I, Parte II, p. 4; art. 14 |
| Documentare | Conservare decisioni, tempi ed evidenze per dieci anni o per il periodo di assistenza | Art. 13, par. 13 |
Gli standard tecnici di riferimento sono ISO/IEC 30111 per il trattamento delle vulnerabilità, ISO/IEC 29147 per la divulgazione e il quadro dei servizi PSIRT pubblicato da FIRST. Nessuno dei tre è obbligatorio, ma leggerli evita di inventare da zero.
Chi può farlo in una PMI
Servono due ruoli, non due assunzioni.
- Il responsabile del PSIRT: di solito il responsabile tecnico o chi guida lo sviluppo del firmware. Riceve le segnalazioni, valuta se riguardano i prodotti, coordina la correzione. Deve conoscere i prodotti e poter leggere una SBOM.
- Il coordinatore: spesso il responsabile qualità, perché il lavoro assomiglia alla gestione delle non conformità. Tiene il registro dei casi, controlla le scadenze, prepara le comunicazioni, conserva le evidenze. È anche il sostituto del responsabile.
Sopra i due sta chi risponde del prodotto, titolare o direzione: decide se un evento va segnalato all'autorità e firma le comunicazioni ai clienti. Non partecipa al lavoro quotidiano, ma deve essere raggiungibile entro poche ore, perché i termini del regolamento corrono anche nel fine settimana.
Come partire in quattro settimane
| Settimana | Che cosa fare | Risultato |
|---|---|---|
| 1 | Aprire un indirizzo dedicato alle segnalazioni, pubblicare il file security.txt e una politica di divulgazione coordinata; nominare per iscritto i due ruoli e il sostituto | Chi trova una vulnerabilità sa a chi scrivere e che cosa aspettarsi |
| 2 | Fare l'elenco dei prodotti in assistenza, con versioni e componenti principali; chiedere la SBOM ai fornitori; aprire il registro dei casi, anche in un foglio di calcolo, con campi fissi: data, fonte, prodotto, versione, componente, gravità, decisione, responsabile, scadenza, evidenze | Un perimetro scritto e un posto dove annotare ogni caso |
| 3 | Scrivere la procedura in una pagina: ricezione, valutazione entro un termine interno, correzione, comunicazione, chiusura; collegarla alla procedura di segnalazione in 24, 72 ore e 14 giorni; fissare chi decide la gravità e chi decide la notifica | Un percorso che non dipende dalla memoria delle persone |
| 4 | Provare tutto con un caso simulato: una vulnerabilità pubblica in un componente che i prodotti contengono effettivamente, seguita dalla ricezione alla chiusura, con i tempi cronometrati | Le prime evidenze e l'elenco di ciò che non ha funzionato |
Il testo modello della politica di divulgazione e il file security.txt sono nell'articolo dedicato; i tre termini di segnalazione sono nella guida alla segnalazione.
Un caso concreto
Un'azienda di 40 persone produce gateway per il telecontrollo di impianti. I dati sono di fantasia. Il responsabile tecnico è il responsabile del PSIRT, la responsabile qualità coordina. Un martedì mattina esce un avviso su una libreria di cifratura usata dal firmware del gateway.
- Martedì, ore 9. Il responsabile legge l'avviso e cerca la libreria nella SBOM: è presente nelle versioni 2.x del firmware, nella versione vulnerabile. Apre il caso nel registro.
- Martedì, ore 11. Valuta: la funzione vulnerabile è usata solo quando l'assistenza remota è attiva. Gravità alta per i clienti che la usano, bassa per gli altri. Nessuna prova di sfruttamento: non scatta la segnalazione all'autorità. La decisione è scritta nel registro, con il motivo.
- Giovedì. La correzione è pronta nella versione 2.6.1. La coordinatrice prepara l'avviso ai clienti e la nota pubblica sulla vulnerabilità corretta.
- Lunedì successivo. Aggiornamento distribuito, avviso inviato, caso chiuso. Nel registro restano date, decisioni, versioni e il testo dell'avviso: sono le evidenze che l'autorità o un cliente potranno chiedere.
Senza la SBOM, il martedì mattina sarebbe passato a chiedere agli sviluppatori «ma noi la usiamo?». Senza il registro, a distanza di un anno nessuno saprebbe più dire perché non si è segnalato.
Che cosa si può affidare all'esterno
Una PMI non deve fare tutto da sola, ma alcune cose non può delegarle.
| Si può affidare a un servizio | Resta in azienda |
|---|---|
| Il controllo quotidiano delle fonti di vulnerabilità e degli avvisi dei fornitori | La responsabilità del prodotto come fabbricante |
| La prima valutazione dei casi e la proposta di priorità | La decisione se una vulnerabilità tocca il prodotto e se va segnalata |
| La tenuta del registro, delle scadenze e delle evidenze | La correzione del prodotto e il rilascio dell'aggiornamento |
| La preparazione delle bozze di segnalazione e degli avvisi | La comunicazione ai clienti e la firma delle notifiche, salvo delega formale |
Il regolamento consente di affidare a un terzo l'invio delle notifiche, ma la responsabilità resta del fabbricante. Il criterio è semplice: chi decide e chi firma sta in azienda; chi guarda, prepara e conserva può stare fuori.
Gli errori più comuni
- Affidare tutto all'informatica aziendale. Chi gestisce la rete e i computer dell'azienda non conosce il firmware dei prodotti. Il PSIRT sta vicino allo sviluppo e alla qualità, non all'assistenza informatica interna.
- Nessun sostituto. Una vulnerabilità sfruttata nel giorno in cui il responsabile è in ferie fa scadere le 24 ore da sola.
- Aspettare la SBOM perfetta. Un elenco dei componenti principali, anche incompleto, permette di cominciare; si migliora a ogni rilascio.
Domande frequenti
Con un solo prodotto serve un PSIRT?
Servono le funzioni, non il nome: un contatto, una persona che valuta, un sostituto, un registro. Con un solo prodotto il lavoro è poco, ma le scadenze del regolamento sono le stesse di chi ne ha cento.
Il PSIRT coincide con il CSIRT?
No. Il CSIRT (Computer Security Incident Response Team) risponde agli incidenti sui sistemi di un'organizzazione, per esempio un attacco alla rete aziendale; in Italia il CSIRT nazionale è presso l'ACN. Il PSIRT risponde alle vulnerabilità dei prodotti che l'azienda vende. Un fabbricante soggetto anche a NIS2 può avere bisogno di entrambi.
Quanto tempo richiede ogni settimana?
Dipende dal numero di prodotti e di componenti, e dalla qualità delle SBOM. Nei primi mesi la parte più pesante è raccogliere le fonti e costruire il perimetro; a regime il lavoro quotidiano è leggere gli avvisi e valutare i pochi che toccano i prodotti. È la parte che un servizio esterno può alleggerire di più.
Da dove cominciare
Il Presidio Continuo di Assiduo fa la parte del lavoro che si può affidare all'esterno: controlla ogni giorno le fonti, valuta i casi con persone, tiene registro, scadenze ed evidenze, prepara le bozze per le segnalazioni. I due ruoli in azienda restano, con molto meno da fare. Il configuratore ti dice in pochi minuti se il tuo perimetro rientra nel servizio.
Fonti: regolamento (UE) 2024/2847, articolo 13 paragrafi 5, 8 e 13, articolo 14, Allegato I Parte II; ISO/IEC 30111:2019; ISO/IEC 29147:2018; FIRST, «PSIRT Services Framework», versione 1.1. Consultate il 14 ottobre 2026. Leggi anche: la guida alle vulnerabilità di prodotto.