Il triage malware LLM di Databricks colma un punto cieco dei binari, ma il contesto decide ancora il verdetto

Databricks ha pubblicato uno studio sul triage malware con LLM che ha ridotto gli errori di rilevamento dal 50% al 4% in 70 test su modelli economici. Il miglioramento non è derivato dal riaddestramento di quei modelli né dalla loro sostituzione con alternative più costose. È arrivato dall'iniezione di conoscenze strutturate sulla sicurezza dei binari prima che ogni modello prendesse la propria decisione.

Il risultato mette in discussione un'ipotesi comune alla base della scansione dei pacchetti assistita dall'AI. Una maggiore intelligenza del modello non è sempre la risposta più diretta a valutazioni di sicurezza deboli. Un modello più piccolo può colmare gran parte del divario quando l'analisi statica gli fornisce le prove giuste e un quadro interpretativo adeguato.

La scoperta è rilevante perché i pacchetti npm malevoli non espongono sempre il proprio comportamento tramite JavaScript leggibile. Alcuni incorporano eseguibili compilati dietro file sorgente puliti, metadati credibili e script di installazione familiari. Quel contesto circostante può indurre un modello non assistito a un verdetto sicuro di sé ma rischioso.

L'esperimento completo, pubblicato il 16 ottobre 2026, ha testato direttamente questo fallimento. Databricks ha valutato nove modelli di sette provider usando payload Node.js nativi appositamente creati. Ha poi confrontato i loro giudizi con e senza profili di capacità, playbook strutturati costruiti su prove statiche.

La sfida principale non è quindi tra un modello e un altro. È tra il ragionamento LLM non assistito e il ragionamento LLM fondato su prove specifiche del dominio. Databricks ha rilevato che questa distinzione può determinare se un ladro di credenziali nascosto venga bloccato o consigliato per una allowlist.

Il triage malware LLM di Databricks cambia il contesto decisionale

Databricks non ha insegnato ai suoi modelli a decodificare i binari; ha cambiato ciò che sapevano prima di valutarli.

La pipeline dell'azienda inizia con strumenti di sicurezza deterministici. YARA analizza l'archivio del pacchetto alla ricerca di pattern noti. Semgrep esamina il codice sorgente JavaScript, mentre i metadati npm forniscono informazioni sul pacchetto e sul suo scopo dichiarato.

Un modulo separato di analisi binaria estrae prove dagli artefatti compilati. Il sistema combina questi risultati in un prompt strutturato. L'LLM restituisce quindi un verdetto e il ragionamento a supporto, con fino a tre opportunità di richiedere altri file.

Databricks ha aggiunto profili di capacità tra l'estrazione delle prove e il giudizio del modello. Ogni profilo rappresenta una tecnica malevola, come la raccolta di credenziali, la persistenza, il mascheramento binario o l'esfiltrazione di rete. Valuta condizioni osservabili rispetto a soglie sospette, malevole e critiche.

Quando un profilo raggiunge la propria soglia, il sistema aggiunge al contesto del modello un riepilogo strutturato di circa 1.800 token. Il modello mantiene il controllo sul verdetto finale e può respingere l'interpretazione del profilo. Il materiale iniettato funge da briefing esperto, non da classificazione fissa.

Questa architettura separa due compiti che i prodotti di sicurezza basati su LLM spesso confondono. Gli strumenti statici identificano importazioni, proprietà dei file, metadati e pattern di codice. Il modello linguistico valuta questi segnali nel più ampio contesto del pacchetto.

L'esperimento ha utilizzato cinque tipi di payload malevoli distribuiti come addon Node.js nativi. Rappresentavano un ladro di credenziali, un dropper, una reverse shell, uno stub per cryptomining e un meccanismo di persistenza. Il ladro di credenziali è apparso anche a sei livelli di offuscamento.

Ogni pacchetto includeva metadati dall'aspetto professionale, un README plausibile, binding JavaScript e una configurazione di build standard. Questi elementi creavano l'apparenza di un normale modulo nativo. Il comportamento malevolo restava all'interno di un file .node compilato.

I ricercatori hanno eseguito dieci payload contro ciascun modello due volte. Un'esecuzione includeva i profili di capacità, l'altra no. Prompt, prove binarie, impostazioni di inferenza e byte dei payload sono rimasti altrimenti invariati.

Sette modelli formavano la fascia economica: Claude Haiku 4.5, Gemini 3.5 Flash, Gemma 3 12B, GPT-5.4-nano, Qwen3-Next 80B, GLM 5.3 Flash e Llama 3.1 8B. Claude Sonnet 4.6 e Kimi K3 hanno fornito baseline comportamentali con capacità superiori.

Senza profili di capacità, il gruppo economico non ha raggiunto la soglia di rilevamento dello studio in 35 test su 70. Venti di quei risultati hanno etichettato come benigni payload noti come malevoli. Alla soglia più rigorosa di comportamento malevolo, 51 test su 70 non hanno raggiunto il risultato richiesto.

Dopo l'iniezione dei profili, 32 di quei 35 fallimenti sono diventati rilevamenti. Nessun modello testato ha restituito un verdetto benigno per alcun payload creato. Solo tre risultati di GPT-5.4-nano sono rimasti sotto la soglia di escalation, tutti e tre etichettati come sospetti.

Questo è il cambiamento centrale dietro il triage malware LLM di Databricks. I modelli non hanno ricevuto nuovi pesi, un addestramento più ampio o una lezione generale sulla sicurezza. Hanno ricevuto interpretazioni concise collegate a prove già estratte dal pacchetto.

Perché pacchetti npm puliti possono nascondere binari pericolosi

Il punto cieco dei binari emerge quando un contesto di pacchetto apparentemente innocuo prevale su prove che il modello non riesce a interpretare con sicurezza.

Databricks ha iniziato a raccogliere campioni di malware npm nel novembre 2025. Il corpus di ricerca includeva 11.413 versioni di pacchetti corroborate tramite gli avvisi OSV sui malware npm. La maggior parte conteneva codice sorgente malevolo oppure recuperava un payload da un server esterno.

Solo 432 versioni di pacchetti corroborate, pari al 3,8%, includevano un binario. Questa piccola quota ha creato un problema di triage sproporzionato. I pacchetti contenenti binari non ricevevano verdetti malevoli decisivi più del doppio delle volte rispetto ai pacchetti con solo sorgente.

I tassi riportati erano del 14,4% per i pacchetti contenenti binari e del 6,2% per quelli con solo sorgente. La differenza conta perché i file compilati rimuovono molti segnali disponibili nel sorgente leggibile. I binari stripped omettono inoltre i nomi dei simboli che aiutano gli analisti a interpretare funzioni e dati.

Un pacchetto npm può legittimamente includere codice nativo. Librerie per le prestazioni, binding per database, strumenti per immagini, terminali e utility di sistema usano regolarmente componenti compilati. Uno script di installazione che invoca node-gyp-build non è quindi automaticamente sospetto.

Gli attaccanti possono sfruttare questa normalità. Possono collocare comportamenti nativi malevoli dietro binding JavaScript puliti e una descrizione credibile del pacchetto. Un modello che si concentra sulla coerenza a livello di pacchetto può considerare questi segnali benigni prove più forti delle ambigue importazioni binarie.

Databricks ha osservato questo comportamento in ciascuno dei 35 fallimenti iniziali di rilevamento. Ogni fallimento si basava su almeno due segnali contestuali benigni. Ventiquattro ne citavano insieme quattro.

Tutti e 35 consideravano standard lo script di installazione. Tutti e 35 trattavano inoltre il packaging di addon nativi come ordinario. Trentadue ritenevano i metadati coerenti con lo scopo dichiarato, mentre 21 si affidavano a JavaScript pulito.

In 14 casi, i modelli hanno reinterpretato le importazioni del binario come normali chiamate di sistema. Funzioni come fopen, connect e gethostname possono supportare software legittimo. La loro combinazione e il comportamento circostante determinano se indichino furto di credenziali o networking ordinario.

L'offuscamento ha peggiorato questa valutazione. Databricks ha rilevato che alcuni modelli assegnavano una gravità minore man mano che il payload per il furto di credenziali diventava più difficile da ispezionare. Il wrapper pulito restava leggibile mentre le prove binarie incriminanti diventavano meno accessibili.

Questo schema coincide con uno studio più ampio sull'offuscamento che ha coinvolto ChatGPT-4o, Gemini Flash 2.5 e Claude Sonnet 4. Le trasformazioni del compilatore hanno causato ripetuti fallimenti di classificazione, anche se il comportamento del programma sottostante è rimasto invariato.

La ricerca sul contesto dei binari stripped descrive una sfida correlata. La rimozione dei simboli elimina segnali contestuali usati per individuare e convalidare comportamenti non sicuri. Un ragionamento più fluido non può ricostruire prove che la pipeline di analisi non ha mai esposto.

I registri dei pacchetti amplificano le conseguenze perché le dipendenze software passano direttamente negli ambienti di sviluppo e produzione. MITRE definisce il compromesso della catena di fornitura come la manipolazione di software, prodotti o meccanismi di consegna prima che il destinatario li riceva.

Un pacchetto malevolo può quindi ereditare fiducia dal registro, dal grafo delle dipendenze o da un account del manutentore compromesso. Una volta installato, il suo binario può essere eseguito con le autorizzazioni dell'applicazione. La presentazione pulita diventa parte della superficie d'attacco.

I profili di capacità trasformano indizi statici in contesto di sicurezza

I profili di capacità funzionano perché trasformano indizi tecnici frammentati in un'affermazione esplicita che un modello può valutare.

Un elenco grezzo di importazioni non spiega l'intento. connect indica networking, mentre fopen indica accesso ai file. Nessuna delle due funzioni, da sola, comunica a un modello che un addon nativo legge credenziali e le invia altrove.

Un profilo di capacità combina queste osservazioni in un pattern specifico per tecnica. Può tenere conto del tipo di pacchetto, del formato binario, delle importazioni, dell'entropia, delle stringhe, dei metadati e del comportamento del sorgente. Soglie ponderate esprimono quindi quanto fortemente le prove combinate supportino un'ipotesi di sicurezza.

Il processo assomiglia al ragionamento potenziato dal recupero, ma il materiale recuperato viene generato dal pacchetto in esame. Non è un estratto generico da un report sulle minacce. Ogni riepilogo collega una definizione della tecnica a prove trovate in quella scansione.

Per il payload che rubava credenziali, i profili coprivano il mascheramento binario, la raccolta di credenziali, l'esfiltrazione di rete e la ricognizione dell'ambiente. La reverse shell attivava profili per il mascheramento binario e il comportamento da reverse shell. Il dropper attivava quattro profili critici.

Questa specificità cambia il compito del modello. Senza profili, il modello deve dedurre sia il significato di ogni artefatto binario sia il verdetto a livello di pacchetto. Con i profili, la logica statica gestisce il primo passaggio interpretativo.

Il modello chiede quindi se le prove assemblate sostengano la conclusione del profilo. Può considerare controprove, valutare il wrapper del pacchetto e selezionare un'azione. Questa divisione limita la quantità di conoscenza specializzata richiesta ai pesi del modello.

Il risultato relativo al ladro di credenziali di Qwen3-Next illustra l'effetto. Senza profili, il modello ha etichettato come benigno un campione offuscato con confidenza pari a 0,98. Ha inoltre consigliato di inserire il pacchetto in allowlist.

Con quattro profili iniettati, lo stesso modello ha etichettato il campione byte per byte identico come malevolo con confidenza pari a 0,98. Ha consigliato di bloccare il pacchetto. Non è cambiato nulla, tranne il contesto strutturato del dominio.

Questa inversione è più importante di un miglioramento medio nei benchmark. Una raccomandazione di allowlist ad alta confidenza può sopprimere una revisione successiva. Trasforma un rilevatore incerto in una fonte operativa di fiducia mal riposta.

L'esperimento ha inoltre identificato quattro modalità di fallimento ricorrenti: razionalizzazione, liquidazione, esitazione e confabulazione. Queste categorie spiegano perché raccogliere semplicemente più opinioni dei modelli non risolva il problema in modo affidabile.

La razionalizzazione si è verificata in circa il 37% delle 90 scansioni condotte sui nove modelli principali. I modelli hanno usato dettagli ordinari del packaging per spiegare via prove sospette. La liquidazione è comparsa nel 22% dei casi e spesso ignorava del tutto le importazioni binarie.

L’esitazione ha interessato il 16% delle analisi. Questi modelli hanno rilevato un pericolo, ma si sono fermati a un verdetto sospetto, potenzialmente al di sotto della soglia di blocco automatizzato. Le confabulazioni sono comparse in circa il 23% dei casi, incluse risposte di modelli più capaci.

La confabulazione ha creato un diverso rischio operativo. Un modello poteva raggiungere il verdetto corretto inventando però indirizzi, funzioni o routine di cifratura. Questi dettagli falsi potevano contaminare i registri di audit e sviare gli investigatori umani.

Gemini 3.5 Flash ha rilevato tutti e dieci i payload senza profili di capacità. Tuttavia, Databricks ha segnalato dettagli tecnici inventati in diverse spiegazioni. Una classificazione corretta non garantiva un ragionamento forense affidabile.

Il risultato sostiene una progettazione basata innanzitutto sulle evidenze. Una pipeline di sicurezza dovrebbe preservare la fonte di ogni affermazione e distinguere le osservazioni estratte dall’interpretazione del modello. Gli analisti devono poter ricondurre un verdetto a importazioni, sezioni, stringhe o comportamenti del codice reali.

Una base di conoscenza tecnica curata può inoltre supportare l’aspetto umano di questo processo. I team hanno bisogno di registri accessibili relativi alla logica dei profili, alle eccezioni, alle decisioni di revisione e alle tecniche degli attaccanti in evoluzione.

I modelli più economici riducono il divario, ma le metriche hanno dei limiti

La tesi sui costi è credibile nell’ambito dell’esperimento, ma i risultati in produzione non dimostrano un rilevamento binario perfetto.

Claude Sonnet 4.6 e Kimi K3 hanno rilevato ogni payload creato ad hoc senza profili. Databricks ha stimato che questi modelli di base costassero circa tre volte di più per analisi rispetto al gruppo economico. L’iniezione dei profili ha consentito alla maggior parte dei modelli più economici di eguagliare il loro tasso di rilevamento.

Le evidenze aggiunte non erano gratuite. Dopo l’iniezione dei profili, i modelli economici hanno ricevuto dal 9% al 34% di token di input in più. Nella maggior parte dei casi è aumentato anche il loro utilizzo di token di output.

I modelli più capaci hanno talvolta usato meno risorse perché i profili riducevano l’esplorazione. Claude Opus 4.6 ha registrato in media circa 10.551 token di input senza profili e 7.214 con essi. Kimi K3 ha prodotto il 13% di token di output in meno dopo aver ricevuto le evidenze del profilo.

Questi dati suggeriscono che un contesto migliore possa sostituire richieste ripetute di file o ragionamenti prolungati. Il beneficio dipende dalla qualità della fase statica. Evidenze deboli trasformate in una prosa curata renderebbero solo più facile accettare una conclusione errata.

Anche il benchmark controllato rimane limitato. Ha utilizzato dieci payload creati ad hoc, tratti da cinque tipi di comportamento. Ogni modello ha ricevuto un passaggio controllato in ciascuna condizione, con temperatura zero e prompt coerenti.

Il comportamento dei modelli ospitati può cambiare mentre i provider aggiornano i loro endpoint. Databricks ha riconosciuto che i verdetti assoluti rappresentano un unico periodo di erogazione. L’evidenza più solida è la differenza, nello stesso periodo, tra input identici.

La convalida in produzione offre una visione più ampia e disordinata. Databricks ha identificato 470 versioni di pacchetti npm dannosi confermati da OSV, contenenti 604 binari nativi. Il set includeva 273 file PE, 215 file ELF, 113 file Mach-O e tre formati non identificati.

Ogni binario ELF era stato privato dei simboli. Il quaranta per cento dei binari era compilato con Go o Rust, mentre 50 file ELF erano compressi con UPX. Questi dettagli mostrano perché un’unica regola universale per il codice nativo produrrebbe risultati deboli.

La valutazione in produzione ha coperto 425 versioni di pacchetti dannosi con verdetti dello scanner. Ha inoltre utilizzato 2.449 versioni di pacchetti provenienti da 287 pacchetti apparentemente benigni. I candidati benigni superavano un milione di download mensili e non erano mai comparsi in OSV.

Alla soglia di escalation, lo scanner ha riportato una precisione di 0,77, un richiamo di 0,81 e un punteggio F1 di 0,79. Ha recuperato 345 delle 425 versioni di pacchetti dannosi. Ottanta sono rimaste sotto la soglia.

Il set benigno ha prodotto 104 escalation, pari al 4,25% delle sue versioni di pacchetto. Questi avvisi erano concentrati in sei pacchetti, ovvero circa il 2% del set distinto di pacchetti benigni.

Un tasso di revisione del 4,25% può essere gestibile in una coda di triage filtrata. Diventerebbe costoso se applicato indiscriminatamente a ogni versione di pacchetto in un grande ecosistema di dipendenze. Il volume operativo conta quanto l’accuratezza del benchmark.

Anche le etichette introducono incertezza. Gli avvisi OSV contrassegnano una versione di pacchetto come dannosa senza identificare sempre quale artefatto contiene il payload. Alcuni pacchetti possono contenere un binario di terze parti innocuo, mentre JavaScript dannoso esegue l’attacco effettivo.

Databricks ha rilevato che circa la metà dei 20 pacchetti di produzione classificati come benigni conteneva strumenti di terze parti riconoscibili. Gli esempi includevano ripgrep, node-pty e plugin di installazione NSIS. L’avviso poteva comunque essere corretto a livello di pacchetto.

Il richiamo riportato non è quindi una misura pulita della classificazione binaria. Misura le decisioni rispetto alle etichette OSV a livello di pacchetto. Databricks dichiara esplicitamente che le reali prestazioni sui binari potrebbero essere superiori o inferiori.

Il database dei pacchetti dannosi di OpenSSF rimane prezioso perché fornisce report aperti in formato OSV. Tuttavia, le etichette su scala di registry non possono sostituire la verifica a livello di artefatto nella valutazione di un rilevatore binario.

Il ragionamento del modello senza supporto è ora la strategia sotto pressione

La ricerca mette sotto pressione i prodotti di sicurezza che trattano un LLM come analista principale anziché come livello finale di ragionamento.

Le progettazioni incentrate sul modello sono allettanti perché riducono il lavoro di integrazione. Un team può inserire il contenuto di un pacchetto in un prompt, chiedere un verdetto e mostrare una spiegazione in linguaggio naturale. Questa semplicità nasconde la dipendenza del modello dalle evidenze visibili.

I payload compilati espongono la debolezza. Un modello linguistico può interpretare disassemblaggio o caratteristiche estratte quando sono disponibili. Non può dedurre in modo affidabile comportamenti nascosti partendo soltanto da JavaScript pulito e metadati professionali.

Acquistare un modello più grande può migliorare il rilevamento di base. Databricks ha osservato che Sonnet e Kimi hanno rilevato tutti i payload creati ad hoc senza profili. Eppure, entrambe le basi più capaci hanno comunque prodotto ragionamenti confabulati in alcune analisi.

Questo crea due requisiti distinti. Un rilevatore deve raggiungere la decisione di escalation corretta. Deve inoltre fornire evidenze che un analista possa verificare.

I profili di capacità affrontano il primo requisito guidando l’attenzione verso combinazioni significative. Risultati statici strutturati supportano il secondo, ancorando le spiegazioni ad artefatti osservabili. L’LLM resta utile per sintesi, risoluzione dei conflitti e definizione delle priorità.

Il voto di maggioranza non offre la stessa protezione. Su un campione offuscato di ladro di credenziali, i nove modelli si sono divisi tra benigno, sospetto, altamente sospetto e dannoso. La maggioranza è rimasta sotto la soglia di rilevamento.

Questi errori erano correlati perché diversi modelli si fidavano dello stesso contesto benigno. Aggiungere altri giudici confusi in modo simile non ha introdotto evidenze indipendenti. Il voto ha semplicemente ripetuto il punto cieco.

L’implicazione strategica va oltre npm. I team di sicurezza chiedono sempre più agli LLM di interpretare avvisi, codice sorgente, log, configurazioni cloud ed eventi di identità. Ogni attività contiene presupposti di dominio che un modello generale potrebbe non applicare in modo coerente.

L’architettura più difendibile separa estrazione, interpretazione e decisione. Gli strumenti deterministici estraggono i fatti. I profili versionati interpretano le combinazioni rilevanti. Il modello risolve il contesto e produce una valutazione rivolta all’analista.

Questo non rende neutrali i profili. I loro autori scelgono soglie, pesi, definizioni ed eccezioni. Gli attaccanti possono anche studiare regole comuni e adattare i propri binari per evitare di attivarle.

I profili possono diventare obsoleti con il cambiamento dei sistemi di build e delle tecniche malware. Una combinazione di importazioni sospetta oggi potrebbe comparire domani in un framework legittimo e diffuso. Al contrario, un nuovo metodo di esfiltrazione può sfuggire a profili scritti attorno a chiamate di sistema meno recenti.

L’approccio sposta quindi parte del rischio dalla selezione del modello alla manutenzione della conoscenza. I team di sicurezza hanno bisogno di responsabili della qualità dei profili, dei test di regressione e della revisione dei falsi positivi. Hanno inoltre bisogno di evidenze versionate che spieghino perché esiste ogni regola.

Le difese del registry rimangono un livello separato. La guida alla provenienza di npm spiega come gli utenti possano verificare dove e come sono stati pubblicati i pacchetti supportati. La provenienza può collegare un artefatto al commit sorgente e al workflow di build.

Questa verifica aiuta a identificare rilasci non autorizzati o manomessi. Non dimostra che il codice sorgente autorizzato o il comportamento compilato siano sicuri. Triage del malware, provenienza, sicurezza dei manutentori e controlli in fase di esecuzione affrontano parti diverse dello stesso problema della supply chain.

Per gli acquirenti, la domanda chiave non è più quale modello primeggi in un benchmark di sicurezza generico. Dovrebbero chiedersi quali evidenze raggiungano il modello, come le affermazioni restino tracciabili e come il sistema gestisca i binari incerti.

Dovrebbero inoltre esaminare la policy di escalation. Un verdetto sospetto ha poco valore protettivo se i workflow automatizzati bloccano solo le classificazioni dannose. Databricks ha mostrato che diversi modelli riconoscevano il rischio, ma non riuscivano a superare la soglia operativa.

Tre segnali metteranno alla prova la generalizzabilità dell’approccio

Il prossimo test è capire se l’iniezione di conoscenza di dominio resista a malware sconosciuti, alla scala del registry e all’adattamento avversario.

Il primo segnale è una riproduzione indipendente su malware reali etichettati a livello di artefatto. I ricercatori hanno bisogno di dataset che identifichino se il componente dannoso sia JavaScript, metadati, uno script di installazione o un binario incluso.

Tali etichette renderebbero più precise le stime di precisione e richiamo. Rivelerebbero inoltre se i profili rilevino il payload effettivo o si limitino a correlare con un’etichetta di pacchetto dannoso. Risultati più solidi a livello di artefatto rafforzerebbero l’affermazione centrale di Databricks.

Il secondo segnale è la prestazione contro comportamenti e toolchain non osservati. Databricks ha testato cinque pattern di attacco creati ad hoc e ha convalidato il suo scanner completo su un set più ampio derivato da OSV. I test futuri dovrebbero escludere intere famiglie di comportamento durante lo sviluppo dei profili.

Il successo su famiglie escluse mostrerebbe che il metodo cattura concetti di sicurezza trasferibili. Un forte calo suggerirebbe che i profili funzionano soprattutto come regole curate per pattern noti.

La diversità di compilatori e piattaforme sarà importante. I file PE, ELF e Mach-O espongono metadati e convenzioni diverse. Anche i binari Go e Rust differiscono dagli artefatti C o C++ in modi che influenzano l’analisi statica.

Gli attaccanti reagiranno se i sistemi basati su profili di capacità diventeranno comuni. Possono sostituire importazioni evidenti, ritardare l’esecuzione, caricare funzionalità dinamicamente o spostare il comportamento dannoso in un altro livello del pacchetto. Ogni adattamento può indebolire un riepilogo delle evidenze statiche.

Il terzo segnale è il costo della revisione operativa. Databricks ha riportato 104 escalation tra 2.449 versioni di pacchetti benigni, concentrate in sei pacchetti. I dati di implementazione dovrebbero mostrare quante ore di analista consumano questi cluster.

Un sistema sostenibile deve raggruppare gli avvisi correlati, preservare le evidenze e apprendere dalle eccezioni esaminate. In caso contrario, un modesto tasso di falsi positivi a livello di pacchetto può creare lavoro ripetitivo tra versioni e ambienti.

I team dovrebbero inoltre monitorare i mancati rilevamenti gravi, non soltanto il richiamo aggregato. Lo scanner di produzione di Databricks ha classificato come benigne 20 versioni di pacchetti dannosi etichettate da OSV. Alcune probabilmente trasportavano il payload al di fuori del binario incluso, ma l’incertezza rimane importante.

La qualità delle evidenze dovrebbe diventare una metrica riportata. Un rilevatore che classifica correttamente inventando però dettagli forensi non è pienamente affidabile. Le valutazioni future dovrebbero misurare il radicamento fattuale separatamente dall’accuratezza del verdetto.

Il triage del malware con LLM di Databricks offre una solida argomentazione a favore di competenze strutturate al momento dell’inferenza. Mostra che modelli più economici possono prendere decisioni molto migliori quando la pipeline di sicurezza interpreta evidenze opache prima di richiedere un giudizio.

Questo non dimostra che la conoscenza al momento del prompt elimini il problema dei binari. I profili dipendono da visibilità statica, regole mantenute e soglie che gli aggressori possono sondare. Le etichette di produzione lasciano inoltre irrisolte le questioni su quale artefatto fosse dannoso.

I team di sicurezza dovrebbero ora verificare una proposta pratica: i loro modelli esistenti possono migliorare se ricevono prove migliori, prima di pagare per un modello più grande? Costruite un set di valutazione a partire da pacchetti revisionati, preservate le etichette a livello di artefatto e confrontate scansioni identiche con e senza contesto di dominio. Il risultato utile non è una spiegazione persuasiva. È un verdetto tracciabile che regge quando il pacchetto appare pulito e il binario no.