Il ciclo di vita della gestione delle vulnerabilità per i vendor di software

Che cos'è il ciclo di vita della gestione delle vulnerabilità?

Il ciclo di vita della gestione delle vulnerabilità è il processo ripetibile che un vendor di prodotti segue per gestire una vulnerabilità nel software che distribuisce: riceverla o individuarla, verificarla, stabilire che cosa è interessato, correggerla, rilasciare la correzione e informare i clienti. In un'organizzazione vendor è gestito di solito da un product security incident response team (PSIRT), mentre i team di engineering realizzano le correzioni.

Questa pagina tratta il lato del vendor. La gestione delle vulnerabilità IT, cioè la scansione e l'applicazione di patch ai server e ai laptop di un'organizzazione, condivide il vocabolario ma non le parti difficili. Un vendor deve rispondere di ogni release supportata in mano ai clienti, e deve pubblicare ciò che ha trovato.

Le fasi del ciclo di vita

1. Ricevere o scoprire. Le vulnerabilità arrivano da ricercatori esterni tramite il Suo programma di divulgazione, dai clienti, da coordinatori come i CSIRT nazionali e dal Suo monitoraggio: una nuova CVE in una dipendenza open source, un risultato di uno scanner o un test interno. Registri ciascuna con un ID di tracciamento e dia riscontro ai segnalatori esterni.
2. Verificare ed eseguire il triage. Riproduca il problema o confermi la corrispondenza con la dipendenza, decida se si tratta di una vulnerabilità del Suo prodotto e valuti quanto è grave e quanto è urgente. Chiuda ciò che non è pertinente, con una motivazione che potrà mostrare in seguito. Segnali di prioritizzazione come EPSS e il catalogo CISA KEV aiutano a classificare ciò che resta.
3. Valutare i prodotti e le versioni interessati. Individui ogni prodotto, release e branch supportato che contiene il codice o il componente vulnerabile, e ogni deployment dei clienti che ne esegue uno. Questa fase decide l'ambito della correzione e dell'advisory.
4. Correggere. Il team responsabile sviluppa e testa una correzione: una dipendenza aggiornata, una modifica al codice o una mitigazione, come una modifica di configurazione, quando una correzione non è ancora possibile.
5. Rilasciare la correzione. Distribuisca versioni aggiornate per ogni branch supportato interessato, tramite un canale di cui i clienti possano fidarsi.
6. Informare e divulgare. Pubblichi un advisory che indichi che cosa è interessato, quanto è grave e che cosa fare, assegni o citi un ID CVE e riconosca il merito al segnalatore. I formati leggibili da una macchina come CSAF e VEX consentono ai clienti di elaborare gli advisory in modo automatico.
7. Monitorare e imparare. Tenga d'occhio lo sfruttamento e le nuove informazioni, aggiorni l'advisory e riporti la causa principale nello sviluppo, così la stessa classe di difetti non viene distribuita di nuovo.

ISO/IEC 30111 e ISO/IEC 29147

Due standard internazionali descrivono questo ciclo di vita per i vendor. Lo dividono al confine dell'organizzazione:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titolo	Vulnerability handling processes	Vulnerability disclosure
Copre	Ciò che avviene all'interno: verifica, indagine, prioritizzazione e correzione	Le interfacce: ricezione delle segnalazioni e pubblicazione degli advisory
Contenuti principali	Policy e organizzazione, responsabilità del PSIRT, fasi di gestione, considerazioni sulla supply chain	Ruoli degli stakeholder, gestione delle segnalazioni, contenuto degli advisory, coordinamento, policy di divulgazione
Destinatari	Vendor che gestiscono vulnerabilità segnalate	Vendor che ricevono segnalazioni e divulgano vulnerabilità

Gli standard sono pensati per essere usati insieme. ISO/IEC 30111 indica sei fasi di gestione: preparazione, ricezione, verifica, sviluppo della correzione, rilascio e post-rilascio. Chiede inoltre il monitoraggio del processo, la riservatezza delle informazioni sulle vulnerabilità e l'attenzione alla supply chain, dato che molte vulnerabilità si trovano in componenti che Lei non ha scritto. Entrambi gli standard sono edizioni in vigore, confermate alle ultime revisioni ISO, e sono contrassegnati per la revisione.

Altri framework seguono la stessa struttura. Il FIRST PSIRT Services Framework raggruppa il lavoro in scoperta delle vulnerabilità, triage e analisi, correzione e divulgazione, e IEC 62443-4-1 include la gestione degli aggiornamenti di sicurezza e dei difetti nel suo ciclo di vita di sviluppo sicuro per i prodotti industriali.

Ruoli

• PSIRT o team di product security: è responsabile del processo, riceve le segnalazioni, esegue il triage, coordina le correzioni e pubblica gli advisory. Veda CRACI per i team PSIRT e in che cosa un PSIRT si differenzia da un CSIRT.
• Team di prodotto e di engineering: sono responsabili del codice, sviluppano e testano le correzioni e distribuiscono le release.
• Release management: decide quali branch supportati ricevono una correzione e quando.
• Assistenza clienti e comunicazione: gestiscono le domande dei clienti e il pubblico dell'advisory.
• Ufficio legale: fornisce consulenza su divulgazione, contratti e notifiche alle autorità di regolamentazione.
• Parti esterne: segnalatori, coordinatori come CERT/CC o un CSIRT nazionale, maintainer upstream dei componenti interessati e clienti che devono distribuire la correzione.

Tempistiche e SLA

Non esiste un'unica tempistica obbligatoria. La maggior parte dei vendor fissa obiettivi interni in base alla gravità e pubblica quelli esterni nella propria policy di divulgazione. Una struttura tipica:

• Riscontro a una segnalazione esterna entro pochi giorni lavorativi.
• Triage entro pochi giorni, così il segnalatore e il team responsabile sanno a che punto si è.
• Correzione con tempi stabiliti da gravità e sfruttamento, più brevi per i risultati critici e per tutto ciò che è noto come sfruttato.
• Divulgazione quando la correzione è disponibile, oppure a una scadenza concordata se la correzione slitta.

Le pressioni esterne fissano il limite massimo. I ricercatori stabiliscono spesso una scadenza di divulgazione (Google Project Zero concede ai vendor 90 giorni) e la normativa aggiunge le proprie: il Cyber Resilience Act dell'UE impone ai fabbricanti di correggere le vulnerabilità "senza ritardo" e fissa scadenze di segnalazione per quelle attivamente sfruttate (veda che cosa richiede il CRA). Quando una vulnerabilità è già sfruttata, come nel caso di una zero-day, ogni fase segue i tempi più stretti.

Dove il ciclo di vita si inceppa

La maggior parte dei ritardi non sta nello scrivere la correzione. Nasce dal non sapere che cosa si è distribuito.

• Non sapere quali release contengono un componente. Arriva una nuova CVE in una libreria. Quali release dell'anno scorso la includono, e quali clienti le usano? Senza un registro per release, i team ricompilano vecchi tag o cercano a mano nei repository, e l'elenco delle versioni interessate nell'advisory è una supposizione.
• Dipendenze transitive. Molti pacchetti vulnerabili non sono stati scelti da Lei. Arrivano come dipendenze transitive diversi livelli più in basso, quindi una ricerca nei manifest non li trova.
• Rumore delle dipendenze di sviluppo. Gli scanner che leggono i lockfile segnalano framework di test e strumenti di build che non vengono mai distribuiti. Ognuno costa tempo di triage e seppellisce i risultati che contano.
• Componenti esterni al package manager. I binari scaricati dagli script di build, le immagini base e i componenti dei fornitori non compaiono affatto in un lockfile.
• Responsabilità non chiare. Un risultato che non appartiene a nessun team resta in attesa. Il triage è finito solo quando la correzione ha un responsabile.
• Correzioni che non durano. Una versione vulnerabile ritorna tramite un'altra dipendenza o un vecchio branch, perché nulla le impedisce di entrare nella build successiva.

Metriche

Metrica	Che cosa mostra
Tempo di riscontro	Se i segnalatori ricevono una risposta quando la Sua policy lo prevede
Tempo di triage	Quanto attende un risultato prima che qualcuno sappia se conta
Tempo di correzione, per gravità	Quanto velocemente vengono distribuite le correzioni, dalla ricezione a una release disponibile
Tempo fino all'advisory	Quanto attendono i clienti per ricevere informazioni dopo la correzione
Quota entro l'obiettivo	Se gli SLA interni reggono, soprattutto per i risultati critici e sfruttati
Backlog per anzianità	I risultati bloccati, e dove
Quota di risultati non pertinenti	Quanto impegno di triage va a risultati non pertinenti

Misuri ogni fase separatamente. Un lungo tempo di correzione si rivela spesso un lungo tempo per trovare le release interessate.

Gestisca il ciclo di vita a partire da un registro di ciò che ha distribuito

Ogni fase dopo il triage dipende dal sapere che cosa c'è in ogni release. CRACI esegue le Sue build GitHub Actions sui propri runner e registra i pacchetti effettivamente scaricati da ciascun job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache CI e le dipendenze che nessun lockfile elenca. Ogni SBOM riporta uno stato di completezza e si esporta in CycloneDX o SPDX.

CRACI rivaluta di continuo le SBOM monitorate e le aggrega tra build e repository, e si possono aggiungere le SBOM dei fornitori, così i componenti acquistati vengono monitorati insieme ai Suoi. Quando compare una nuova CVE, la cronologia delle build mostra quali build passate contenevano la dipendenza vulnerabile, diretta o transitiva, così Lei conosce il periodo in cui è stato colpito, e la vista dell'inventario mostra quali versioni del software sono distribuite su quali prodotti. I team di sicurezza eseguono il triage dei risultati in CRACI e li inviano ai team responsabili della correzione, CRACI supporta VEX e i policy gate possono bloccare le build che contengono una specifica CVE, così una vulnerabilità corretta resta fuori. Veda il monitoraggio delle vulnerabilità.

Ciclo di vita della gestione delle vulnerabilità: domande frequenti

Quali sono le fasi del ciclo di vita della gestione delle vulnerabilità?

Per un vendor di prodotti: ricevere o scoprire la vulnerabilità, verificarla ed eseguirne il triage, individuare i prodotti e le versioni interessati, sviluppare la correzione, rilasciarla, pubblicare l'advisory, quindi monitorare e imparare. ISO/IEC 30111 indica le fasi di preparazione, ricezione, verifica, sviluppo della correzione, rilascio e post-rilascio.

Che cos'è ISO/IEC 30111?

ISO/IEC 30111:2019 è lo standard internazionale per i processi di gestione delle vulnerabilità. Fornisce ai vendor requisiti e raccomandazioni per elaborare e correggere le vulnerabilità segnalate nei loro prodotti e servizi, dalla policy e dal ruolo del PSIRT alle fasi di gestione e alle considerazioni sulla supply chain.

Qual è la differenza tra ISO/IEC 30111 e ISO/IEC 29147?

ISO/IEC 29147 copre la parte rivolta all'esterno: ricevere segnalazioni e pubblicare advisory. ISO/IEC 30111 copre la gestione interna che sta nel mezzo: verifica, indagine, prioritizzazione e correzione. I due standard sono pensati per essere usati insieme. Veda la divulgazione coordinata delle vulnerabilità per il lato 29147.

Che cos'è il triage delle vulnerabilità?

Il triage è la fase in cui un team di sicurezza conferma che una vulnerabilità segnalata o scoperta è reale, valuta quanto è grave e urgente per il Suo prodotto e la invia al team responsabile della correzione. Un buon triage chiude anche i risultati non pertinenti, registrandone la motivazione.

In che cosa la gestione delle vulnerabilità di prodotto differisce da quella IT?

La gestione delle vulnerabilità IT applica patch ai sistemi usati da un'organizzazione. La gestione delle vulnerabilità di prodotto si occupa dei difetti nel software che l'organizzazione sviluppa e distribuisce ad altri, quindi aggiunge passaggi che i team IT non hanno: stabilire quali versioni rilasciate sono interessate, distribuire una correzione ai clienti e informarli con un advisory.

Quali metriche dovrebbe monitorare un processo di gestione delle vulnerabilità?

Il tempo di riscontro a una segnalazione, il tempo di triage, il tempo di correzione e il tempo fino all'advisory, ciascuno per gravità, più la quota di risultati che rispettano gli obiettivi interni, il backlog aperto per anzianità e il numero di risultati chiusi come non pertinenti.