SBOM, VEX e PSIRT: il controllo delle vulnerabilità di prodotto
Come collegare componenti, release, valutazioni di sfruttabilità e attività di remediation nel ciclo di vita di software e dispositivi.
Per un produttore, una nuova CVE pone una domanda precisa: quali prodotti e quali release sono interessati? La risposta richiede una SBOM aggiornata, una valutazione tecnica della sfruttabilità e una funzione che coordini correzione e comunicazione. Il PSIRT collega queste attività.
La SBOM deve seguire la release
Una Software Bill of Materials descrive i componenti di un prodotto in una determinata versione. Per essere utilizzata nel vulnerability handling deve essere collegata alla pipeline di rilascio e conservata con la storia delle versioni. Una SBOM relativa al ramo principale non descrive necessariamente il firmware o il pacchetto distribuito mesi prima.
CycloneDX e SPDX forniscono formati standard per rappresentare i componenti. Identificativi come purl e CPE aiutano a normalizzare i nomi, ma non risolvono da soli componenti rinominati, copiati nel codice o caricati dinamicamente. La copertura ottenibile e le esclusioni devono essere documentate.
- Associare ogni SBOM a prodotto, versione e build.
- Registrare dipendenze dirette e transitive con il relativo percorso.
- Confrontare le SBOM con ciò che risulta installato o in esecuzione.
- Misurare la quota di componenti con identificativi univoci e SBOM aggiornate.
Presenza e sfruttabilità sono valutazioni distinte
La presenza di una libreria vulnerabile non implica che il prodotto sia sfruttabile. Il codice interessato potrebbe non essere raggiungibile, la funzione vulnerabile potrebbe essere disabilitata oppure un controllo potrebbe impedire il percorso di attacco. Al contrario, una dipendenza indiretta può essere raggiungibile attraverso più chiamate e risultare prioritaria anche quando non compare nell’elenco dei pacchetti principali.
Il Vulnerability Exploitability eXchange, o VEX, documenta l’esito di questa analisi per singolo prodotto e vulnerabilità. Un file VEX non sostituisce la motivazione tecnica: versioni, configurazioni, condizioni di raggiungibilità e riferimenti alle verifiche devono restare collegati alla decisione.
Il PSIRT coordina il caso dalla segnalazione alla chiusura
Il Product Security Incident Response Team riceve segnalazioni da ricercatori, clienti, fornitori e strumenti automatici. Dopo il triage assegna il caso ai team competenti, verifica le release coinvolte e tiene traccia di mitigazioni, correzioni e comunicazioni. Lo stesso processo gestisce la coordinated vulnerability disclosure con il ricercatore e, quando necessario, con gli utilizzatori del prodotto.
Il Vulnerability Disclosure Report documenta come una vulnerabilità è stata gestita. La chiusura operativa richiede una prova sulla release corretta o sulla configurazione distribuita; il completamento di un ticket non è sufficiente. Se la patch del fornitore non è disponibile, mitigazione e correzione definitiva devono rimanere stati separati.
- Registrare data di ricezione, owner, prodotti e release coinvolte.
- Collegare la valutazione VEX alle prove tecniche disponibili.
- Tracciare advisory, mitigazioni, versioni correttive e destinatari della comunicazione.
- Verificare la chiusura sulla build o sul dispositivo interessato prima dell’aggiornamento del VDR.
Il collegamento con il Cyber Resilience Act
Il Cyber Resilience Act richiede processi di gestione delle vulnerabilità durante il ciclo di vita dei prodotti con elementi digitali. SBOM, VEX, VDR e registri PSIRT forniscono una base tecnica per le attività richieste, ma devono essere adattati al prodotto, al ruolo dell’operatore economico e agli obblighi applicabili.
Gli obblighi di segnalazione si applicano dall’11 settembre 2026, mentre gli obblighi principali si applicano dall’11 dicembre 2027 secondo il calendario pubblicato dalla Commissione europea. Il Digital Product Passport appartiene a quadri distinti, come ESPR e Regolamento batterie: non è un requisito automatico del CRA.
Mycelium nel processo PSIRT
Mycelium collega SBOM, grafo delle dipendenze, CVE, advisory, attività di remediation e prove di chiusura. La ricerca inversa parte dal componente e individua i percorsi che lo introducono nelle release coperte. Gli analisti aggiungono il contesto necessario alla valutazione VEX e il workflow mantiene la storia delle decisioni.
Mycelium è usato nei servizi EMF e non sostituisce gli strumenti di build, gli scanner o i sistemi di ticketing. Le integrazioni servono a evitare copie non sincronizzate degli stessi dati.