SBOM e VEX: componenti e impatto delle vulnerabilità
Sytance · Aggiornato
La SBOM identifica i componenti software di un prodotto. Vulnerability Exploitability eXchange (VEX) comunica se una specifica vulnerabilità incida su tale prodotto. La valutazione dipende dalla versione del prodotto, dalla configurazione e dal modo in cui utilizza il componente.
Inventario dei componenti, corrispondenze e impatto
L’inventario registra se un componente è presente. Una corrispondenza di vulnerabilità indica che un avviso identifica il componente o la relativa versione. L’analisi dell’impatto verifica quindi se il codice vulnerabile sia presente e sfruttabile nella build e nell’uso effettivi del prodotto.
CycloneDX usa VEX per comunicare la valutazione di uno specifico prodotto. Ad esempio, un componente può essere presente mentre una funzionalità vulnerabile opzionale è stata esclusa durante la build. Per stabilire questa distinzione servono informazioni e analisi della build.
I quattro stati OpenVEX
OpenVEX definisce quattro stati. Ciascuno si applica alla versione del prodotto e alla vulnerabilità identificate nella dichiarazione.
| Stato OpenVEX | Significato |
|---|---|
| under_investigation | L’impatto è ancora in fase di valutazione |
| affected | Il prodotto identificato è interessato |
| fixed | La versione identificata include una correzione |
| not_affected | Il prodotto identificato non è interessato |
Un decodificatore opzionale in un gateway
Si consideri un gateway fittizio che contiene una libreria parser con un decodificatore opzionale. Si supponga che una vulnerabilità interessi quel decodificatore. La valutazione parte dall’accertare quale build della libreria sia presente nell’immagine distribuita e se il decodificatore sia stato compilato al suo interno.
Se le impostazioni di build e l’analisi del binario confermano l’assenza del decodificatore vulnerabile, possono supportare una dichiarazione not_affected con motivazione vulnerable_code_not_present. La dichiarazione si applica a quella build.
Se il codice è presente ma l’esecuzione non è chiara, mantenere la valutazione under investigation mentre si verificano i punti di ingresso e i percorsi di esecuzione. Se il prodotto è interessato e una release successiva include la correzione, la release precedente resta interessata; la release successiva riceve una propria dichiarazione.
Motivazioni per lo stato not_affected
OpenVEX richiede che una dichiarazione not_affected includa una giustificazione o una dichiarazione d’impatto. Le motivazioni leggibili da una macchina distinguono tra componenti mancanti, codice vulnerabile assente, codice esterno al percorso di esecuzione, limiti al controllo dell’attaccante e mitigazioni integrate.
Ogni motivazione prevede condizioni diverse. Una restrizione di rete non rimuove il codice vulnerabile. Per la motivazione relativa a una mitigazione integrata, OpenVEX specifica una protezione che impedisce lo sfruttamento e che l’utente non può disattivare o riconfigurare.
Per concludere che il codice è fuori dal percorso di esecuzione, identificare la funzione interessata, i percorsi verificati e i limiti di configurazione. Rivedere la valutazione se tali condizioni cambiano. Se la conclusione dipende da un’impostazione controllata dal cliente, comunicare chiaramente questa dipendenza.
Uso della dichiarazione VEX di un fornitore
La dichiarazione VEX di un fornitore può aiutare a filtrare gli avvisi o a modificarne la priorità. Prima di usarla, verificare che la fonte sia attendibile e che la versione del prodotto corrisponda. Controllare data di pubblicazione, revisioni, configurazione applicabile e azioni raccomandate.
Se un fornitore attendibile e la propria analisi non concordano, conservare entrambi i record e risolvere la differenza. Una dichiarazione generica per una famiglia di prodotti potrebbe non coprire una build personalizzata con componenti o opzioni diversi.
La SBOM resta utile dopo la pubblicazione di una dichiarazione VEX. Nuovi avvisi possono modificare ciò che occorre indagare e una versione rivista del prodotto può invalidare una conclusione precedente. Mantenere collegati gli aggiornamenti dell’inventario e le valutazioni d’impatto, conservandone però la cronologia separata.