Trovare è diventato economico. Il resto del ciclo di vita no. Un ciclo di vita della gestione delle vulnerabilità ha le stesse fasi da qualunque quadro di riferimento lo si tragga: identificare i candidati, giudicare quali siano reali e con quale gravità, decidere cosa fare di ciascuno, correggere, verificare la correzione, segnalare a chi è dovuta una segnalazione, e conservare il fascicolo. Nella nostra lettura la fase costosa era un tempo la prima. Oggi uno scanner, un fuzzer, una piattaforma di revisione o un assistente produce candidati più in fretta di quanto un team riesca a giudicarli, e il ciclo di vita si rompe nelle fasi successive, dove un candidato ben formulato deve diventare una decisione che qualcuno dovrà poi giustificare.
Questa nota percorre le fasi, dice cosa richiede in ciascuna il Cyber Resilience Act europeo, il regolamento (UE) 2024/2847, e dice dove si colloca una revisione adversariale indipendente. Il suo peso sta nelle fasi successive alla prima.
Identificare: dove non vendiamo
I candidati arrivano da ogni parte: analisi statica, strumenti per le dipendenze e la distinta base del software, fuzzer, piattaforme di revisione, assistenti, i vostri stessi ingegneri e segnalanti esterni. Anche una revisione adversariale produce candidati (le nostre hanno compreso difetti poi corretti a monte), ma trovare è ciò che un incarico rende per strada, non ciò su cui è tariffato. Una pratica collocata qui competerebbe con il vostro scanner sui volumi.
Cosa richiede il CRA qui. Il fabbricante deve identificare e documentare le vulnerabilità e i componenti contenuti nel prodotto, redigendo anche una distinta base del software (allegato I, parte II, punto 1), e deve indicare un recapito per la segnalazione e facilitare la condivisione di informazioni sulle potenziali vulnerabilità (allegato I, parte II, punto 6). Sono obblighi del fabbricante; i rilievi di un revisore esterno li alimentano e non li assolvono.
Giudicare: dall’opinione ben formulata al gradino di prova
Qui il ciclo di vita si rompe per la prima volta, perché tutti gli strumenti di cui sopra emettono opinioni sul codice con la stessa scorrevolezza, che il percorso sia raggiungibile o no. Il giudizio è la fase in cui quelle opinioni vengono o risolte o graduate. La nostra regola è: prima l’oracolo. Un’affermazione decidibile (questo percorso viene eseguito, la specifica ammette questo valore) va a ciò che può rispondere, un’esecuzione, un compilatore o la specifica, prima che a chiunque sia chiesto un parere. Ciò che sopravvive è graduato secondo il gradino di prova effettivamente raggiunto (traccia nel codice sorgente, prova in compilazione, test, riproduzione in esercizio, e per ogni affermazione probabilistica un tasso con intervallo e i registri delle singole prove), oppure è marcato come solo plausibile. La gravità segue allora la prova, non la sicurezza di un modello. Un rilievo non è un verdetto ne è la trattazione estesa.
Cosa richiede il CRA qui. Effettuare prove e riesami efficaci e periodici della sicurezza del prodotto (allegato I, parte II, punto 3), e, nella documentazione tecnica, le relazioni delle prove effettuate per verificare la conformità del prodotto e dei processi di gestione delle vulnerabilità (allegato VII, punto 6). Una relazione di prove effettuate è una relazione su cosa è stato esaminato, come, e cosa è stato accertato, che è ciò che un fascicolo graduato per prova è e un elenco ordinato per gravità non è. E per un po’ quelle relazioni saranno scritte prima che sia citabile la norma armonizzata che definisce «efficaci e periodici»; dovranno quindi reggersi sui propri meriti: Le norme possono slittare, la data di notifica no.
Decidere: quando lo strumento e la squadra divergono
La seconda rottura. Uno strumento segnala una vulnerabilità critica; l’ingegneria dice che il framework la attenua; il team di sicurezza non ha né il tempo di dimostrarlo né la posizione per scavalcare una scadenza, e il ticket si chiude per sfinimento. Le nostre regole di chiusura sono quelle della pagina revisione del codice adversariale: un conteggio non accerta mai nulla; dove i revisori divergono su cosa fa il codice, decide il sorgente; dove un rigetto poggia su «incerto», l’affermazione passa a una coda conservata con un responsabile, una scadenza e un criterio di riapertura, ed è riesposta a una discendenza fresca. Quella coda esiste perché incerto non possa essere silenziosamente convertito in rischio accettato. Cosa risolve un rilievo tratta la prima di quelle regole, compreso il caso in cui l’oggetto della revisione era il nostro stesso strumento.
Cosa richiede il CRA qui. Il fabbricante deve affrontare e correggere tempestivamente le vulnerabilità, anche fornendo aggiornamenti di sicurezza (allegato I, parte II, punto 2), e deve mettere in atto e applicare una politica di divulgazione coordinata delle vulnerabilità (allegato I, parte II, punto 5). Una decisione di non correggere è una decisione che il fascicolo tecnico dovrà spiegare; una voce nella coda conservata, con responsabile e criterio di riapertura, è quella spiegazione, scritta al momento.
Correggere e verificare
Qui il nostro ruolo è sostenere, non possedere: possiamo restare lungo le patch e verificare ogni correzione contro il rilievo cui mira, alla revisione che lo ha chiuso, registrata come risultato a sé. Una correzione verificata rileggendo non è una correzione verificata rieseguendo; il fascicolo nomina il gradino che la verifica stessa ha raggiunto.
Cosa richiede il CRA qui. Distribuzione sicura degli aggiornamenti, e patch di sicurezza diffuse tempestivamente e gratuitamente, con le informazioni di avviso (allegato I, parte II, punti 7 e 8); divulgazione pubblica delle vulnerabilità risolte una volta disponibile un aggiornamento (allegato I, parte II, punto 4).
Segnalare: dove il terzo si guadagna l’onorario
La terza rottura, e quella per cui gli acquirenti di solito vengono. Un’esecuzione interna (con quanti modelli si voglia, per quanto isolati) produce la vostra parola sul vostro codice. Per nostra esperienza, tre delle quattro parti che leggeranno il vostro fascicolo non l’accettano: i legali di un acquirente in due diligence, l’underwriter di un assicuratore cyber, il team di sicurezza di un cliente enterprise. Ciò che comprano è indipendenza organizzativa: un fascicolo giudicato e firmato da una persona con nome e cognome esterna alla vostra organizzazione, che può essere citata e che ritira per iscritto se un rilievo non regge. È la proprietà che nessuna squadra può fornire sul proprio lavoro, ed è tutto ciò che vendiamo.
La quarta parte, il regolatore, è l’eccezione, e taglia nel senso opposto: spesso accetterà la vostra autovalutazione, e poi vi terrà a ogni documento che la sorregge.
Cosa richiede il CRA qui. Due binari di segnalazione, entrambi attraverso la piattaforma unica di segnalazione ed entrambi in vigore dall'11 settembre 2026 (articolo 14). Per una vulnerabilità sfruttata attivamente: un allerta precoce entro 24 ore da quando se ne viene a conoscenza, una notifica entro 72 ore, e una relazione finale entro 14 giorni da quando è disponibile una misura correttiva o di attenuazione. Per un incidente grave: gli stessi passaggi a 24 e 72 ore, e una relazione finale entro un mese dalla notifica. Una revisione esterna non è una notifica e non si sostituisce a essa; ciò che può fare è trasformare il «cosa sapevamo, quando, e come lo abbiamo accertato» dietro una notifica in un documento anziché in una ricostruzione. A parte questo, i prodotti classificati come importanti (allegato III) o critici (allegato IV) sono soggetti a procedure di valutazione della conformità ai sensi dell’articolo 32 che possono coinvolgere un organismo notificato, che non siamo, e a cui nulla in questa pagina si sostituisce.
Conservare
La documentazione tecnica e la dichiarazione di conformità UE sono tenute a disposizione per almeno dieci anni dall’immissione sul mercato del prodotto, o per il periodo di assistenza se quest’ultimo è superiore (articolo 13, paragrafo 13). Un fascicolo conservato per un decennio sarà letto da qualcuno che non era nella stanza, con più tempo e meno benevolenza di chiunque lo abbia scritto. Ogni affermazione nel nostro nomina il gradino di prova raggiunto, ogni superficie esaminata e trovata solida nomina il metodo e il controllo, ogni ritiro è scritto, perché è quel lettore quello per cui è costruito.
Una frase
Gli strumenti generano candidati. Ciò che generiamo noi è il fascicolo firmato e graduato per prova che dice al vostro acquirente, al vostro assicuratore e al vostro regolatore cosa è stato accertato sul vostro codice, a quale gradino, cosa resta incerto e chi risponde di averlo detto. Non ciò che è vero (nessun revisore può prometterlo) ma ciò che è stato mostrato, e come.
I limiti che appartengono a questa pagina: non abbiamo dimostrato che un panel trovi più difetti reali di un solo buon revisore e non lo sosteniamo; l’indipendenza delle nostre istanze è delimitata dalla procedura e non misurata; il nostro banco di revisione è di due persone; facciamo parte di un gruppo che costruisce infrastrutture di pagamento e custodia, e lo dichiariamo per iscritto prima di ogni incarico; non siamo un organismo notificato e nulla qui è consulenza legale. I rimandi al regolamento si riferiscono al regolamento (UE) 2024/2847, verificati sul testo italiano ufficiale prima della pubblicazione di questa nota; la lettura del ciclo di vita e l’affermazione su quale fase fosse un tempo quella costosa sono nostre. Se un rimando è errato, lo correggiamo qui, per iscritto.