Valutazioni VEX
Una distinta base dice che il tuo prodotto contiene OpenSSL 3.0.11; una fonte dice che quella versione ha una vulnerabilità pubblicata. Da lì non segue che il prodotto sia vulnerabile: il componente può non essere raggiungibile, la funzione difettosa può non essere usata, una mitigazione può essere già in posto. VEX è il documento con cui dici quale delle due cose è vera, e te ne assumi l’affermazione. CRAnotify ti porta la corrispondenza; la valutazione resta tua.
Dove si trova
Scheda Vulnerabilità della pagina di un prodotto (/prodotto?id=…&tab=vulnerabilita). Ogni riga è una corrispondenza osservata: la vulnerabilità, il componente agganciato, la fonte che l’ha vista, e accanto la valutazione umana — o la sua assenza, dichiarata a parole.
Quattro passaggi, e restano quattro
- Una fonte osserva una corrispondenza fra un componente della distinta base e una vulnerabilità pubblicata.
- Una persona valuta: sceglie uno status e ne dà la ragione. Ne nasce una bozza.
- Una persona approva la bozza. È un gesto distinto, con il proprio nome e la propria data.
- Da quel momento la dichiarazione è ciò che l’azienda dice di sapere sul proprio prodotto, e solo allora finisce nei documenti che escono.
I passaggi sono quattro apposta. Comprimerli in un pulsante solo significherebbe che l’aggiornamento di una fonte, di notte, cambia ciò che dichiari di sapere sul tuo prodotto. Chi valuta e chi approva possono essere due persone, e in un’organizzazione che tiene alla propria difendibilità lo sono.
Una corrispondenza non è una valutazione
La riga aperta mostra due strati affiancati e distinti: a sinistra i dati di origine (fonte, componente, PURL, release, riferimento, quando è stata registrata), a destra la valutazione umana. Lo strato di origine porta scritto che CRAnotify non ha stabilito nessuna applicabilità normativa: è un segnale.
Se nessuno ha ancora valutato, la colonna umana non mostra un trattino ma dice «Non valutata — richiede revisione umana». Un trattino, o una casella vuota, si legge come «niente da segnalare», che è il contrario di ciò che è vero.
I quattro status dello standard
Sono quelli di CSAF/OpenVEX. Non ne aggiungiamo e non ne rinominiamo: chi consuma un VEX si aspetta questi, e una semantica inventata renderebbe il documento illeggibile proprio a chi dovrebbe leggerlo.
| Status | Che cosa afferma |
|---|---|
under_investigation · In valutazione | Stai ancora guardando: nessuna affermazione sul prodotto. |
not_affected · Non interessato | Dice a chi legge di non preoccuparsi. La giustificazione è obbligatoria. |
affected · Interessato | Il prodotto ne è interessato. |
fixed · Corretto | Una versione correttiva è disponibile. Dire quale, nella giustificazione, è ciò che la rende utile. |
«Interessato» non fa partire nessun termine. È la condizione da cui, insieme allo sfruttamento attivo, può discendere l’obbligo dell’Art. 14 — ma se ci sia un obbligo lo stabilisce il motore, su un case, dopo una consapevolezza confermata nel triage. Registrare uno status VEX non apre una scadenza e non emette un verdetto.
Registrare una valutazione
Dal riquadro della riga: scegli lo status e scrivi la giustificazione. La vulnerabilità e il componente sono quelli della corrispondenza e non si digitano — così la dichiarazione resta agganciata a ciò che è stato osservato. L’identità di chi valuta viene dalla sessione: non c’è un campo del modulo da cui possa arrivare, ed è la ragione per cui nessun percorso automatico può produrre una bozza.
Approvare è il secondo gesto
Sotto una bozza compare Approva questa valutazione, con l’avviso che la valutazione è registrata ma non approvata. L’approvazione registra chi l’ha data e quando, e vale solo per una dichiarazione di quel prodotto: l’applicazione lo verifica sul server, così un modulo costruito a mano non può approvare, dalla pagina di un prodotto, la dichiarazione di un altro.
Approvare due volte non è un errore: la seconda volta non cambia niente.
Dove finiscono le dichiarazioni approvate
Solo le dichiarazioni approvate vengono citate nel fascicolo di documentazione tecnica e sono ciò che si può mostrare a un terzo. Una bozza è un’opinione in corso, e pubblicarla equivarrebbe a dichiarare qualcosa che nessuno ha firmato.
Ogni valutazione e ogni approvazione lascia una riga nel registro delle attività, con la vulnerabilità, lo status, il componente, chi ha valutato e chi ha approvato.
Se non c’è nessuna corrispondenza
La scheda lo dice a parole: nessuna fonte ha agganciato una vulnerabilità pubblicata a un componente di questo prodotto. Non è un’affermazione sul prodotto: dipende da quali distinte base sono arrivate e da quali fonti sono collegate. Un prodotto senza distinta base non produce corrispondenze, e il silenzio non è una buona notizia.
Il lavoro di revisione ancora da fare compare anche nella coda delle azioni, filtrabile per prodotto.