Cos'è il file security.txt e a cosa serve?

security.txt è un file di testo che un'organizzazione pubblica sul proprio sito all'indirizzo /.well-known/security.txt per dire, in una forma che anche un programma sa leggere, a chi vanno segnalate le vulnerabilità trovate nei suoi sistemi. Lo descrive la RFC 9116, pubblicata nell'aprile 2022 da Edwin Foudil e Yakov Shafranovich. Il suo statuto formale è però limitato: è un documento di categoria Informational, che dichiara di non essere una specifica dell'Internet Standards Track, quindi non è una norma tecnica vincolante, ma è passato per il consenso della comunità IETF e per l'approvazione dello IESG, ed è oggi lo standard di fatto. Il contenuto minimo è di due righe. Il campo Contact dice dove scrivere, un indirizzo email, un modulo o un numero di telefono. Il campo Expires dice entro quando quell'informazione è ancora affidabile, e la RFC prescrive che sia sempre presente.

Leggi anche: Cyber Resilience Act (CRA) · Regolamento UE che impone requisiti di cybersicurezza obbligatori ai prodotti con elementi digitali: SBOM, notifica vulnerabilità, marcatura CE.

Cosa contiene, e perché scade

Gli altri sei campi sono facoltativi: Policy, la pagina con le regole della divulgazione coordinata; Encryption, la chiave pubblica per cifrare la segnalazione; Acknowledgments, dove si ringraziano i ricercatori; Preferred-Languages; Canonical; e Hiring. La regola meno intuitiva è la scadenza: la RFC raccomanda un Expires a meno di un anno e al paragrafo 5.3 avverte che non avere un file security.txt può essere preferibile ad averne uno con informazioni stantie. Un recapito che rimbalza fa perdere tempo a chi stava provando ad aiutare, e quella persona non ci riprova. È un problema misurato: l'analisi di Hilbig, Geras, Kupris e Schreck pubblicata su ACM Digital Threats: Research and Practice nell'ottobre 2023 trova il file sull'1,0% del primo milione di domini a gennaio 2023, contro lo 0,7% di fine 2021, su circa il 3,1% dei primi centomila, e con un file su dieci già scaduto.

Un esempio enterprise

Un'azienda che vende macchinari connessi riceve la segnalazione di un ricercatore: il portale di telemetria mostra a un cliente autenticato i dati di impianti che non sono suoi. Senza un recapito dichiarato la segnalazione parte verso l'indirizzo commerciale del sito, viene letta come spam tecnico e resta ferma per settimane, mentre chi lo ha trovato comincia a chiedersi se pubblicarlo. Con quattro righe in /.well-known/security.txt lo stesso messaggio arriva alla casella giusta, con accanto la pagina di policy che dice cosa succede dopo. Il file non rende il prodotto più sicuro: accorcia il tempo fra quando un esterno scopre un problema e quando la persona giusta lo legge.

Perché conta per chi decide

Il Cyber Resilience Act chiede ai fabbricanti di prodotti con elementi digitali una politica di divulgazione coordinata e un indirizzo di contatto per le segnalazioni (Allegato I, Parte II, punti 5 e 6), e un punto di contatto unico facilmente identificabile (articolo 13, paragrafo 17) che però deve lasciare all'utilizzatore la scelta del mezzo: un file da solo non basta mai. Il regolamento non prescrive alcun formato e non nomina mai security.txt; l'unico appiglio è il considerando 76, non vincolante, che invita a valutare la pubblicazione delle politiche di sicurezza in forma leggibile da un dispositivo automatico. Nella NIS2 non c'è nessun obbligo di pubblicare un recapito: la gestione e la divulgazione delle vulnerabilità compare fra le misure minime dell'articolo 21, paragrafo 2, lettera e), ripreso dall'articolo 24 del D.Lgs. 138/2024, senza indicarne la forma, e il collegamento con security.txt è una lettura ragionevole, non una prescrizione. La decisione non è di conformità ma di costo: quattro righe e un promemoria annuale per rendere trovabile un canale che oggi esiste solo nella testa di chi lo gestisce. Un test di sicurezza si compra una volta l'anno; le segnalazioni dall'esterno arrivano quando capita, e solo se sanno dove.

Questa voce è informativa e non costituisce consulenza legale: per stabilire quali obblighi si applicano al tuo prodotto coinvolgi il tuo legale.