Sintesi Tecnica: Sfruttare il Code Slicing per il Rilevamento di Pacchetti NPM Maliziosi basato su LLM

Definizione del Problema

L'ecosistema npm è sempre più preso di mira da attacchi sofisticati alla supply chain del software che utilizzano l'offuscamento e una logica complessa per eludere il rilevamento. Sebbene i Large Language Models (LLM) offrano una comprensione semantica superiore per l'analisi del codice rispetto ai metodi tradizionali basati su regole o machine learning, essi affrontano significativi vincoli pratici. Nello specifico, le finestre di contesto degli LLM standard (tipicamente 4K–16K token) sono spesso insufficienti per analizzare interi pacchetti npm, che possono contenere milioni di token. Gli approcci ingenui, come la suddivisione del codice in chunk di dimensione fissa, frammentano il contesto semantico e degradano l'accuratezza del rilevamento. Inoltre, l'analisi dell'intero pacchetto comporta costi di inferenza e latenza proibitivi, rendendo impossibile il monitoraggio in tempo reale del registro.

Metodologia

Il documento propone un framework basato su LLM che integra tecniche di code-slicing per isolare i flussi di dati rilevanti dal punto di vista della sicurezza dal codice boilerplate benigno prima di fornire il codice a un LLM. La metodologia consiste in tre fasi primarie:

1. Estrazione del Codice Sensibile (Slicing):
   Gli autori adattano il concetto di slicing basato su taint per l'ecosistema npm utilizzando il framework Joern per generare Code Property Graphs (CPG). Introducono un inventario curato, specifico per JavaScript, di API sensibili categorizzate in tre ruoli:

   • Sources (Sorgenti): Input di dati non attendibili (es. process.env, os.userInfo).
   • Sinks (Destinazioni): Punti di esecuzione critici (es. child_process.exec, eval, Buffer.from(..., 'base64')).
   • Dual (Doppie): API che fungono sia da sorgenti che da destinazioni (es. operazioni sui file, comunicazione di rete).

   Vengono implementate e confrontate due strategie di slicing:

   • Static Slicing (Slicing Statico): Utilizza la raggiungibilità backward del Control Flow Graph (CFG) per catturare ampie dipendenze di controllo.
   • Taint-based Slicing (Slicing basato su Taint): Traccia i percorsi di data-flow dalle sorgenti non attendibili verso le destinazioni critiche utilizzando i Data Dependence Graphs (DDG) e i CPG. Questo approccio mira specificamente ai flussi rilevanti per la sicurezza, filtrando le chiamate API incidentali.

   Per ogni pacchetto viene imposto un timeout rigoroso di tre minuti per garantire la scalabilità. I pacchetti che producono slice vuote (spesso a causa di generazione di codice dinamico o offuscamento) vengono esclusi dalla pipeline di analisi statica.

2. Scoring basato su LLM:
   Le slice estratte vengono fornite a DeepSeek-Coder-6.7B, selezionato per la sua forte comprensione del codice, la finestra di contesto di 16K token e la capacità di produrre output JSON strettamente analizzabili. Il modello viene istruito con una persona di analisi statica per valutare ogni slice rispetto all'intento malizioso, restituendo un oggetto JSON con un punteggio di confidenza, un flag di offuscamento e un punteggio di rischio di sicurezza ($S \in [0, 1]$).

3. Aggregazione:
   Per determinare la classificazione finale a livello di pacchetto, viene impiegata una strategia di aggregazione conservativa. Il punteggio massimo di maliziosità tra tutte le slice di un pacchetto viene utilizzato come indicatore. Un pacchetto è classificato come malizioso se il suo punteggio supera una soglia $\tau = 0.8$.

Contributi Chiave

Il documento apporta tre contributi specifici:

1. Adattamento delle Strategie di Slicing: Gli autori adattano e valutano due strategie di code-slicing (basata su CFG statico e basata su taint) specificamente per l'ecosistema npm, utilizzando Joern e una tassonomia personalizzata delle API specifiche per JavaScript.
2. Quantificazione della Riduzione del Contesto: Lo studio quantifica la riduzione della dimensione del contesto e la preservazione delle informazioni rilevanti per la sicurezza. Il slicing basato su taint riduce il conteggio medio dei token di input del 99,75% e la mediana del 93,7%, preservando al contempo i comportamenti maliziosi critici.
3. Valutazione delle Prestazioni: Il framework è valutato su un dataset di oltre 7.000 pacchetti (filtrati a 2.537 amabili all'analisi statica). I risultati dimostrano che le rappresentazioni di input semanticamente mirate migliorano significativamente le prestazioni di rilevamento basate su LLM rispetto alla suddivisione ingenua dei token e allo slicing basato solo su CFG statico.

Risultati

Valutato su un sottoinsieme di 2.537 pacchetti utilizzando DeepSeek-Coder-6.7B, l'approccio di Taint-based Slicing ha ottenuto le seguenti metriche di prestazione:

• Accuratezza: 87,04%
• Precisione: 96,23%
• Recall (Richiamo): 72,90%
• F1 Score: 83,32%

Questi risultati hanno superato sia la baseline di Naive Token Splitting (accuratezza 75,41%, F1 67,80%) sia l'approccio di Static CFG-only Slicing (accuratezza 75,65%, F1 74,21%).

In termini di preservazione delle informazioni, il Taint-based slicing ha mantenuto il 73,7% delle feature API sensibili nei pacchetti maliziosi, filtrando circa il 90% dei segmenti di codice benigni. Al contrario, lo slicing statico ha mantenuto il 73,4% delle feature maliziosi ma ha trattenuto significativamente più rumore benigno (15,9% delle feature sensibili nei pacchetti benigni rispetto al 9,4% del taint-based).

Significato e Limitazioni

Il documento sostiene che questo approccio fornisce una difesa efficace e computazionalmente pratica contro le evolventi minacce alla supply chain, consentendo agli LLM di concentrarsi su segnali semantici ad alta densità invece di elaborare enormi quantità di codice irrilevante. La significativa riduzione del conteggio dei token (da una media di ~162k a ~403) rende l'analisi in tempo reale o quasi in tempo reale fattibile su hardware standard (due GPU RTX 3080).

Tuttavia, gli autori riconoscono esplicitamente diverse limitazioni:

• Bias di Sopravvivenza: L'accuratezza riportata si applica solo ai pacchetti che hanno prodotto slice non vuote. Circa il 44% dei pacchetti maliziosi nel dataset ha prodotto slice vuote, principalmente a causa di generazione di codice dinamico (es. eval, Function()) o offuscamento che interrompe l'analisi del data-flow statico.
• Dipendenza da API Predefinite: Il framework si basa su una lista curata di API sensibili. Potrebbe fallire nel rilevare nuovi vettori di attacco che sfruttano primitive Node.js precedentemente non viste o catene di chiamate indirette non presenti nell'inventario.
• Offuscamento: L'attuale approccio statico non può gestire pacchetti pesantemente offuscati senza un passaggio di pre-processing di de-offuscamento.

Gli autori concludono che, sebbene il metodo migliori significativamente le prestazioni di rilevamento rispetto alle baseline, il lavoro futuro deve affrontare la de-offuscazione, l'integrazione dell'analisi dinamica e l'espansione dell'inventario delle API per gestire tecniche di evasione più sofisticate.