Criteri per la divulgazione delle vulnerabilità

In breve

Questa pagina descrive i criteri di divulgazione coordinata delle vulnerabilità di NextPDF. Spiega a chi effettua una segnalazione come contattare privatamente i manutentori, quali tempi di risposta aspettarsi e come funziona l’embargo.

Ambito. I criteri di divulgazione sono un impegno di processo, non una garanzia su tempi o esito. Gli obiettivi riportati di seguito sono gli impegni assunti in buona fede dai manutentori nei confronti di chi effettua una segnalazione; descrivono il processo seguito dal progetto, non una promessa contrattuale che una determinata segnalazione sia confermata, sottoposta a triage, corretta o divulgata entro una data precisa. I tempi della divulgazione coordinata sono concordati, non garantiti unilateralmente.

Installazione

Non applicabile. Segnalare una vulnerabilità non richiede l’installazione di alcun componente. Il punto di contatto leggibile da sistemi automatici è pubblicato in /.well-known/security.txt (RFC 9116). I criteri di riferimento destinati agli utenti sono contenuti nel file SECURITY.md del repository.

Panoramica concettuale

Questi criteri adottano la divulgazione coordinata delle vulnerabilità come definita da ISO/IEC 29147 e il processo di gestione di ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): ricezione privata, triage e valutazione della gravità, correzione sotto embargo e rilascio pubblico congiunto. Quando una vulnerabilità interessa più fornitori, i tempi dell’avviso vengono concordati fra le parti coinvolte anziché stabiliti unilateralmente (iso_iec_29147#x3.x110.p13).

Il processo è inoltre allineato agli obblighi di gestione delle vulnerabilità del produttore previsti dall’EU Cyber Resilience Act (eu_cra#x1.p191) e alla pratica «respond to vulnerabilities» del NIST Secure Software Development Framework (nist_sp_800_218#x15). Entrambi inquadrano tali attività come doveri di processo ripetibili, non come garanzia di un esito specifico.

Superficie API

Non applicabile. La divulgazione è un processo, non un’API. Il punto di individuazione leggibile da sistemi automatici è il file security.txt di RFC 9116; gli strumenti ne analizzano i campi Contact: ed Expires:. Questa pagina non duplica il contenuto di tale file, salvo i canali riportati di seguito.

Esempio di codice — Avvio rapido

Non applicabile. Non è necessario eseguire alcun codice per segnalare una vulnerabilità. Utilizzare un canale privato:

GitHub Security Advisories (consigliato — con cifratura a riposo e log di controllo): aprire una bozza di avviso nella scheda GitHub Security del progetto.
Email: [email protected] con [SECURITY] nell’oggetto. Se è necessaria la cifratura end-to-end e in security.txt non è ancora presente una chiave OpenPGP pubblicata, utilizzare invece il canale GitHub Security Advisory.

Si raccomanda di non effettuare segnalazioni tramite issue pubbliche, mailing list pubbliche, social media o chat. La divulgazione pubblica prima di una correzione mette a rischio gli utenti che usano versioni non aggiornate.

Esempio di codice — Produzione

Non applicabile.

Casi limite e insidie

Gli obiettivi sono impegni, non SLA. I tempi riportati di seguito indicano gli obiettivi del progetto. Un problema complesso che coinvolge più componenti, o che richiede un coordinamento a monte, può richiedere più tempo; chi ha effettuato la segnalazione viene tenuto informato.
La durata dell’embargo è negoziabile, con un limite massimo. L’embargo predefinito va dal triage al rilascio della correzione. Chi effettua la segnalazione e necessita di più tempo deve richiederlo esplicitamente al momento dell’apertura dell’avviso. Superato il limite massimo, il progetto pubblicherà l’avviso indipendentemente dalla disponibilità di una correzione, in linea con le prassi del settore sulla divulgazione coordinata: questo protegge gli utenti da un avviso trattenuto a tempo indeterminato.
La gravità determina la tempistica. Un problema critico, attivamente sfruttato, viene gestito con tempi ridotti; un suggerimento di hardening a bassa gravità non lo è. La gravità viene valutata in fase di triage e può essere rivista.
L’assegnazione del CVE fa parte del triage. Il manutentore richiede un CVE tramite l’iscrizione CNA del progetto a GitHub Security Advisory durante la fase di triage; chi effettua la segnalazione non deve richiederlo separatamente.

Prestazioni

Non applicabile.

Note sulla sicurezza

Gli obiettivi temporali di risposta sono impegni nei confronti di chi effettua una segnalazione e costituiscono il riferimento operativo del progetto per la gestione delle vulnerabilità. Sono obiettivi, non garanzie:

Fase	Obiettivo
Conferma di ricezione	entro 1–2 giorni lavorativi
Triage iniziale + valutazione della gravità	entro ~5 giorni lavorativi / 7 giorni di calendario
Sviluppo della patch + revisione privata	in genere 14 giorni lavorativi; 30–90 giorni per CVE complessi confermati a seconda della gravità
Assegnazione del CVE (se accettato)	in concomitanza con la patch, tramite il canale CNA di GitHub
Divulgazione pubblica coordinata	al rilascio della patch, in una data stabilita congiuntamente con chi ha effettuato la segnalazione
Embargo (dal triage al rilascio)	in genere ~90 giorni, ridotto in caso di sfruttamento attivo, prorogabile su richiesta esplicita fino a un limite massimo fisso

Regole di processo verificabili da un revisore:

Priorità ai canali privati. Nessun canale pubblico è accettato come punto di ricezione. Gli unici canali ammessi sono GitHub Security Advisory e l’email di sicurezza.
Coordinata, non unilaterale. I tempi della divulgazione vengono concordati con chi ha effettuato la segnalazione e con eventuali altri fornitori coinvolti (iso_iec_29147#x3.x110.p13).
Embargo limitato. L’embargo ha un valore predefinito e un limite massimo rigido; un avviso non viene trattenuto a tempo indeterminato.
Riconoscimento su richiesta. I ricercatori ricevono riconoscimento una volta revocato l’embargo, salvo che richiedano l’anonimato.

Queste dichiarazioni descrivono il processo che il progetto si impegna a seguire. Non garantiscono che una determinata segnalazione si traduca in una correzione, in un CVE o in una divulgazione entro una data specifica.

Conformità

Questa pagina non è un profilo di conformità. I criteri sono allineati a ISO/IEC 29147 e ISO/IEC 30111 e ai doveri di processo CRA/SSDF citati sopra; «allineati a» è una formulazione deliberata: il progetto non dichiara alcuna certificazione rispetto a tali schemi. Le fonti citate definiscono come si presenta un processo solido; questa pagina documenta l’impegno del progetto a gestirne uno.

Vedere anche

Trust center
Modello delle minacce del motore
Modello di sicurezza di firma e cifratura
File del repository SECURITY.md e /.well-known/security.txt (RFC 9116)