SBOM-Based Container Deployment Risk Assessment under Incomplete Runtime Observations
Questo articolo propone un metodo adattivo basato su SBOM per valutare i rischi di distribuzione dei container in condizioni di osservazioni di runtime incomplete, integrando molteplici fonti di evidenza per classificare l'applicabilità delle vulnerabilità e dare priorità ai costi di ispezione, ottenendo tassi di completamento delle decisioni migliorati e tempi di attesa ridotti rispetto agli approcci di base.
Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Nel moderno mondo digitale, il software viene raramente costruito da zero. Invece, gli sviluppatori assemblano le applicazioni come uno chef esperto che assembla un piatto complesso partendo da ingredienti pre-confezionati: librerie, framework e strumenti creati da altri. Per tenere traccia di questi ingredienti, un nuovo standard chiamato Software Bill of Materials, o SBOM, funge da elenco dettagliato dell'inventario. Questo elenco è cruciale per la sicurezza perché, se viene scoperto un difetto noto in uno degli ingredienti, l'SBOM aiuta a identificare quali applicazioni lo contengono. Tuttavia, sapere che un ingrediente è presente è solo metà della battaglia. Un difetto in una libreria diventa un pericolo solo se il software utilizza effettivamente quella specifica parte del codice mentre è in esecuzione. Se il codice rimane inattivo, mai chiamato dal programma, il difetto è innocuo. La sfida per i team di sicurezza è che non sempre possono osservare il software in esecuzione in modo perfetto; a volte gli strumenti di monitoraggio perdono eventi, o gli scenari di test non coprono ogni possibile modo in cui il software potrebbe essere utilizzato. Ciò lascia un vuoto in cui un team potrebbe non sapere se un difetto sia pericoloso o innocuo, costringendolo a bloccare un aggiornamento necessario o a rischiare una violazione.
I ricercatori Byeongchan Park e Sun-Jip Kim hanno affrontato questa incertezza creando un nuovo metodo per decidere se distribuire un contenitore software, ovvero un pacchetto autosufficiente di un'applicazione e dei suoi ingredienti. Il loro approccio tratta la mancanza di informazioni perfette non come un motivo per indovinare, ma come un motivo per fermarsi e raccogliere prove più specifiche. Hanno costruito un sistema che combina l'elenco dell'inventario con l'analisi statica, che esamina la struttura del codice, e le osservazioni in tempo di esecuzione, che osservano il software in azione. Fondamentalmente, il sistema riconosce che il fatto che una funzione pericolosa non sia stata vista durante un test non significa che la funzione sia sicura da ignorare. Invece di forzare una risposta "sì" o "no" quando le prove sono scarse, il sistema classifica il rischio come confermato pericoloso, confermato sicuro entro un ambito specifico o irrisolto. Quando un rischio è irrisolto, il sistema non si limita ad approvare la distribuzione; mette la richiesta in attesa.
Il cuore della loro innovazione è una strategia per impiegare una quantità limitata di tempo e potenza di calcolo per risolvere queste incertezze. Immaginate un team di sicurezza con una scadenza rigorosa per decidere su un aggiornamento software. Hanno un elenco di potenziali difetti, ma controllare meticolosamente ognuno di essi richiede troppo tempo. Il metodo dei ricercatori agisce come una guida intelligente, decidendo quali controlli eseguire per primi in base a quanto sia probabile che aiutino a raggiungere una decisione finale, piuttosto che eseguire i controlli in un ordine casuale o basandosi solo sulla gravità. Esso dà priorità alle azioni che hanno maggiori probabilità di trasformare un rischio "irrisolto" in un verdetto chiaro di "sicuro" o "pericoloso", invece di eseguire semplicemente i controlli in modo casuale o per gravità. Il sistema rivaluta continuamente le proprie scelte man mano che arrivano nuovi dati, assicurando che ogni secondo del budget di ispezione sia dedicato al controllo più importante per la decisione finale.
Per testare questo approccio, i ricercatori hanno costruito una simulazione realistica utilizzando cento diversi scenari di distribuzione del software derivati da quaranta casi specifici di vulnerabilità in progetti Java. Hanno creato una verità di base per novanta di questi casi, il che significa che sapevano esattamente quali distribuzioni fossero sicure e quali pericolose, indipendentemente dal loro nuovo sistema. Hanno poi sottoposto il sistema a varie forme di informazione incompleta, come parti mancanti del carico di lavoro di test, finestre di osservazione accorciate ed eventi di perdita dati. Hanno confrontato il loro metodo adattivo con diverse altre strategie, tra cui un semplice controllo basato su un elenco e un metodo che dà priorità alle ispezioni in base al costo per risolverle. I risultati hanno mostrato che il loro metodo è stato più efficace nel raggiungere una decisione finale corretta entro il limite di tempo. Sotto un budget di centoventi secondi, il nuovo metodo ha raggiunto un tasso di decisione corretta bilanciato del settantotto virgola quattro per cento, rispetto al settantasei virgola tre per cento del secondo miglior metodo.
Forse ancora più importante, il nuovo metodo ha ridotto il numero di casi che rimanevano bloccati in uno stato di "attesa" irrisolto. Mentre altri metodi lasciavano il ventidue per cento delle decisioni non decise, il metodo proposto ha ridotto questa percentuale al venti per cento. Ciò significa che più aggiornamenti software possono procedere in sicurezza senza ritardi non necessari, pur mantenendo un tasso di errore molto basso. Il sistema ha approvato erroneamente distribuzioni pericolose solo l'uno virgola due per cento delle volte e ha bloccato erroneamente distribuzioni sicure solo il due per cento delle volte. Questi numeri suggeriscono che, ordinando attentamente quali controlli eseguire e rifiutando di prendere una decisione quando le prove sono insufficienti, i team di sicurezza possono navigare nella nebbia dei dati incompleti in modo più efficace. Lo studio conferma che un approccio strutturato e basato sulle prove può distinguere tra un difetto che è realmente innocuo e uno che è semplicemente non osservato, permettendo alle organizzazioni di procedere con fiducia anche quando non possono vedere ogni singolo dettaglio del comportamento del proprio software.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.