security.txt (RFC 9116): campi obbligatori ed esempio

Con il CRA, i fabbricanti devono avere un canale pubblicamente raggiungibile attraverso cui ricercatori e clienti possano segnalare vulnerabilità. Lo standard è RFC 9116: un file di testo semplice chiamato security.txt, ospitato a /.well-known/security.txt. Due campi obbligatori, qualche campo raccomandato e circa 10 minuti di lavoro.

Questa guida tratta i campi, l'hosting, gli errori più comuni e cosa occorre referenziare nel fascicolo tecnico.

Cos'è security.txt?

security.txt è uno standard RFC (RFC 9116) che fornisce un modo leggibile da macchina e da umano per pubblicare informazioni di contatto sulla sicurezza.

Il CRA richiede ai fabbricanti di pubblicare un contatto per la segnalazione delle vulnerabilità. security.txt è il metodo standard del settore per farlo. Strumenti di scansione automatizzata e ricercatori di sicurezza lo verificano per impostazione predefinita, e averlo in essere fornisce ai regolatori un segnale concreto che si sono predisposti canali di divulgazione appropriati.

Il security.txt Minimo Necessario

Ecco il file conforme più semplice:

Contact: mailto:security@yourcompany.com
Expires: 2027-12-31T23:59:59.000Z

Tutto qui. Due righe. Si è tecnicamente conformi.

Ma facciamo meglio.

Il security.txt Raccomandato

Un security.txt completo:

# Security Contact Information for [Your Company]
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Preferred-Languages: en, de, fr
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/disclosure-policy
Hiring: https://yourcompany.com/careers/security
Acknowledgments: https://yourcompany.com/security/thanks

Spiegazione Campo per Campo

Contact (Obbligatorio)

Come i ricercatori possono contattarLa.

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report

Si utilizzi un alias di team, non un indirizzo personale. Si includano sia l'email sia un modulo web, se disponibile. Sono ammesse più righe Contact, e il modulo web consente una raccolta strutturata delle segnalazioni.

Expires (Obbligatorio)

Expires: 2027-01-01T00:00:00.000Z

Si imposti una data a 6-12 mesi nel futuro, in formato ISO 8601 con fuso orario. Si aggiunga un promemoria nel calendario prima della scadenza. Un file scaduto segnala ai ricercatori che non lo si sta manutenendo.

Encryption (Raccomandato)

Encryption: https://yourcompany.com/.well-known/pgp-key.txt

Si utilizzi una chiave di team anziché individuale, e si conservi la chiave privata in un HSM se possibile. Si includa l'impronta digitale nei commenti, così i ricercatori possono verificarla in modo indipendente.

Preferred-Languages (Raccomandato)

Preferred-Languages: en, de, fr

Si elenchino solo le lingue in cui il team di sicurezza può effettivamente rispondere. Si ordini per preferenza. Se si indica il tedesco e nessuno nel team lo legge, si riceveranno segnalazioni che non si riuscirà a gestire.

Canonical (Raccomandato)

Canonical: https://yourcompany.com/.well-known/security.txt

Previene lo spoofing e chiarisce se il file è replicato altrove. I ricercatori possono verificare l'URL canonico rispetto a quello recuperato per confermarne l'autenticità.

Policy (Raccomandato)

Policy: https://yourcompany.com/security/disclosure-policy

Ci si assicuri che la pagina esista e sia caricabile senza autenticazione. Un link Policy non funzionante durante una revisione di sicurezza è controproducente.

Acknowledgments (Opzionale)

Acknowledgments: https://yourcompany.com/security/thanks

I ricercatori che trovano bug sono spesso ottimi candidati per il team di sicurezza. Il riconoscimento pubblico incoraggia ulteriori segnalazioni. La maggior parte dei ricercatori dà priorità alle organizzazioni che riconoscono il loro lavoro.

Hiring (Opzionale)

Hiring: https://yourcompany.com/careers/security

Vale la pena includerlo se ci sono posizioni aperte nel settore sicurezza. I ricercatori in cerca di lavoro consultano questi link.

Configurazione Passo per Passo

Passo 1: Creare il File

cat > security.txt << 'EOF'
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy
EOF

Passo 2: Scegliere la Posizione di Hosting

Per i siti web:

https://yourcompany.com/.well-known/security.txt

Per prodotti con interfacce web:

https://192.168.1.1/.well-known/security.txt

Passo 3: Configurare il Web Server

Nginx:

location /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
}

Apache:

Alias /.well-known/security.txt /var/www/security.txt
<Files "security.txt">
    ForceType text/plain
</Files>

Express.js:

app.get('/.well-known/security.txt', (req, res) => {
    res.type('text/plain');
    res.sendFile(__dirname + '/security.txt');
});

Hosting statico (S3, GitHub Pages, ecc.): Si posizioni il file nella directory .well-known.

Passo 4: Verificare

curl https://yourcompany.com/.well-known/security.txt

Si utilizzi un validatore online: https://securitytxt.org/

Passo 5: Firmare (Opzionale ma Raccomandato)

gpg --clearsign security.txt
mv security.txt.asc security.txt

Per Prodotti Senza Interfacce Web

Dispositivi Embedded

Opzione 1: Si ospiti security.txt a http://device-ip/.well-known/security.txt Opzione 2: Se non c'è interfaccia web: si includa l'URL nella documentazione del prodotto, con riferimento al security.txt aziendale.

Software Desktop

• Si includa il contatto di sicurezza in Aiuto > Informazioni
• Si aggiunga al README/documentazione

App Mobile

• Si includa in Impostazioni > Informazioni > Sicurezza
• Si aggiunga alla descrizione nell'app store

Riferimento nella Documentazione

## Segnalazione di Vulnerabilità di Sicurezza
- Email: security@yourcompany.com
- Web: https://yourcompany.com/security/report
- Policy: https://yourcompany.com/security/policy
Il nostro file security.txt: https://yourcompany.com/.well-known/security.txt

Errori Comuni

File Scaduto

Expires: 2024-01-01T00:00:00.000Z  # SCADUTO!

Correzione: Si imposti una data futura. Si aggiunga un promemoria nel calendario.

Posizione Sbagliata

/security.txt           # Sbagliato
/.well-known/security.txt  # Corretto

Formato Non Valido

Correzione: Si usino date ISO 8601, URI mailto: o https:.

Link Non Funzionanti

Correzione: Si verifichi che tutti i link funzionino. Si controlli dopo ogni deploy.

Email Personale

Contact: mailto:john.smith@yourcompany.com  # Sbagliato

Correzione: Si utilizzi un alias di team che sopravviva ai cambi di personale.

Nessun HTTPS

Correzione: Si usi sempre HTTPS per URL relativi alla sicurezza.

Checklist di Validazione

CHECKLIST DI VALIDAZIONE SECURITY.TXT

CAMPI OBBLIGATORI:
[ ] Campo Contact presente (mailto: o https:)
[ ] Campo Expires presente (data futura, ISO 8601)

CAMPI RACCOMANDATI:
[ ] Preferred-Languages incluso
[ ] URL Canonical corrisponde alla posizione effettiva
[ ] Link Policy funziona e punta alla policy CVD

HOSTING:
[ ] File a /.well-known/security.txt
[ ] Accessibile via HTTPS
[ ] Content-Type: text/plain
[ ] Nessuna autenticazione richiesta

VERIFICA:
[ ] Test curl riuscito
[ ] Validatore online superato
[ ] Tutti i link risolvono (nessun 404)

MANUTENZIONE:
[ ] Promemoria calendario impostato prima della data Expires
[ ] Processo di aggiornamento documentato

Calendario di Manutenzione

Cosa Inserire nel Fascicolo Tecnico

Il CRA richiede ai fabbricanti di mantenere un fascicolo tecnico (Annex VII) che documenti il processo di gestione delle vulnerabilità. Il file security.txt e la policy CVD a cui rimanda sono input diretti a quella documentazione.

In particolare, il fascicolo tecnico dovrebbe referenziare:

• L'URL del security.txt e i metodi di contatto che espone
• L'URL della policy di divulgazione a cui rimanda
• Gli SLA di risposta a cui ci si è impegnati in quella policy

I regolatori che esaminano il fascicolo tecnico cercano evidenza che esista un processo funzionante di ricezione delle vulnerabilità. Un security.txt attivo, non scaduto, con un link Policy funzionante è un segnale concreto. Un file scaduto o link non funzionanti lavorano contro di Lei.

Si aggiunga questo blocco alla documentazione sulla gestione delle vulnerabilità:

Punti di Contatto per la Segnalazione di Vulnerabilità:
- security.txt: https://company.com/.well-known/security.txt
- Email: security@company.com
- Modulo Web: https://company.com/security/report
- Policy: https://company.com/security/policy

Esempio Completo

# SECURITY.TXT for AcmeTech Products
Contact: https://acmetech.eu/security/report
Contact: mailto:security@acmetech.eu
Expires: 2027-06-01T00:00:00.000Z
Preferred-Languages: en, de, es
Canonical: https://acmetech.eu/.well-known/security.txt
Policy: https://acmetech.eu/security/disclosure-policy
Acknowledgments: https://acmetech.eu/security/hall-of-fame
Hiring: https://acmetech.eu/careers#security

Come CRA Evidence Aiuta

security.txt è un tassello del quadro complessivo di gestione delle vulnerabilità. La parte più complessa è il processo che sta dietro: la policy, gli SLA di triage, la segnalazione all'ENISA e la documentazione nel fascicolo tecnico. A questo serve CRA Evidence.

Si inizi da craevidence.com.

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