Resumo Técnico: Utilizando Slicing de Código para Detecção de Pacotes Maliciosos NPM baseada em LLMs

Declaração do Problema

O ecossistema npm é alvo crescente de ataques sofisticados à cadeia de suprimentos de software que utilizam ofuscação e lógica complexa para evitar a detecção. Embora os Grandes Modelos de Linguagem (LLMs) ofereçam uma compreensão semântica superior para análise de código em comparação com métodos tradicionais baseados em regras ou aprendizado de máquina, eles enfrentam restrições práticas significativas. Especificamente, as janelas de contexto dos LLMs padrão (tipicamente 4K–16K tokens) são frequentemente insuficientes para analisar pacotes npm inteiros, que podem conter milhões de tokens. Abordagens ingênuas, como a divisão do código em fragmentos de tamanho fixo, fragmentam o contexto semântico e degradam a precisão da detecção. Além disso, a análise de pacotes completos acarreta custos de inferência e latência proibitivos, tornando o monitoramento em tempo real do registro inviável.

Metodologia

O artigo propõe um framework baseado em LLM que integra técnicas de code-slicing (fatiamento de código) para isolar fluxos de dados relevantes para a segurança do código boilerplate benigno antes de fornecer o código ao LLM. A metodologia consiste em três estágios primários:

1. Extração de Código Sensível (Slicing):
   Os autores adaptam o taint-based slicing (fatiamento baseado em contaminação) para o ecossistema npm usando o framework Joern para gerar Grafos de Propriedade de Código (CPGs). Eles introduzem um inventário curado, específico para JavaScript, de APIs sensíveis categorizadas em três papéis:

   • Sources (Fontes): Entradas de dados não confiáveis (ex: process.env, os.userInfo).
   • Sinks (Destinos): Pontos críticos de execução (ex: child_process.exec, eval, Buffer.from(..., 'base64')).
   • Dual (Duais): APIs que atuam tanto como fontes quanto como destinos (ex: operações de arquivo, comunicação de rede).

   Duas estratégias de slicing são implementadas e comparadas:

   • Static Slicing (Slicing Estático): Utiliza o alcance retroativo do Grafo de Fluxo de Controle (CFG) para capturar dependências de controle amplas.
   • Taint-based Slicing (Slicing Baseado em Contaminação): Rastreia caminhos de fluxo de dados de fontes não confiáveis para destinos críticos usando Grafos de Dependência de Dados (DDGs) e CPGs. Esta abordagem visa especificamente fluxos relevantes para a segurança, filtrando chamadas de API incidentais.

   Um tempo limite estrito de três minutos é aplicado por pacote para garantir a escalabilidade. Pacotes que resultam em fatias vazias (frequentemente devido à geração de código dinâmico ou ofuscação) são excluídos do pipeline de análise estática.

2. Pontuação Baseada em LLM:
   As fatias extraídas são enviadas para o DeepSeek-Coder-6.7B, selecionado por sua forte compreensão de código, janela de contexto de 16K tokens e capacidade de produzir saídas JSON estritamente analisáveis. O modelo é instruído com uma persona de análise estática para avaliar cada fatia quanto à intenção maliciosa, retornando um objeto JSON com uma pontuação de confiança, uma flag de ofuscação e uma pontuação de risco de segurança ($S \in [0, 1]$).

3. Agregação:
   Para determinar a classificação final do pacote, é empregada uma estratégia de agregação conservadora. A pontuação máxima de maliciosidade entre todas as fatias de um pacote é usada como o indicador. Um pacote é classificado como malicioso se sua pontuação exceder um limiar $\tau = 0,8$.

Principais Contribuições

O artigo apresenta três contribuições específicas:

1. Adaptação de Estratégias de Slicing: Os autores adaptam e avaliam duas estratégias de code-slicing (baseada em CFG estático e baseada em contaminação) especificamente para o ecossistema npm, utilizando Joern e uma taxonomia de API personalizada para JavaScript.
2. Quantificação da Redução de Contexto: O estudo quantifica a redução no tamanho do contexto e a preservação de informações relevantes para a segurança. O taint-based slicing reduz a contagem média de tokens de entrada em 99,75% e a mediana em 93,7%, enquanto preserva comportamentos maliciosos críticos.
3. Avaliação de Desempenho: O framework é avaliado em um conjunto de dados de mais de 7.000 pacotes (filtrados para 2.537 passíveis de análise estática). Os resultados demonstram que representações de entrada semanticamente direcionadas melhoram significativamente o desempenho de detecção baseada em LLM em comparação com a divisão de tokens ingênua e o slicing apenas de CFG estático.

Resultados

Avaliado em um subconjunto de 2.537 pacotes usando DeepSeek-Coder-6.7B, a abordagem de Taint-based Slicing alcançou as seguintes métricas de desempenho:

• Acurácia: 87,04%
• Precisão: 96,23%
• Recall (Revocação): 72,90%
• F1 Score: 83,32%

Estes resultados superaram tanto a linha de base de Naive Token Splitting (75,41% de acurácia, 67,80% de F1) quanto a abordagem de Static CFG-only Slicing (75,65% de acurácia, 74,21% de F1).

Em termos de preservação de informação, o Taint-based slicing reteve 73,7% das características de API sensíveis em pacotes maliciosos, enquanto filtrou aproximadamente 90% dos segmentos de código benignos. Em contraste, o slicing estático reteve apenas 73,4% das características maliciosas, mas manteve significativamente mais ruído benigno (15,9% das características sensíveis em pacotes benignos vs. 9,4% para o taint-based).

Significância e Limitações

O artigo afirma que esta abordagem fornece uma defesa eficaz e computacionalmente prática contra ameaças evolutivas à cadeia de suprimentos, permitindo que os LLMs foquem em sinais semânticos de alta densidade em vez de processar quantidades massivas de código irrelevante. A redução significativa na contagem de tokens (de uma média de ~162k para ~403) torna a análise em tempo real ou quase real viável em hardware padrão (duas GPUs RTX 3080).

No entanto, os autores reconhecem explicitamente várias limitações:

• Viés de Sobrevivência: A acurácia relatada aplica-se apenas aos pacotes que produziram fatias não vazias. Aproximadamente 44% dos pacotes maliciosos no conjunto de dados produziram fatias vazias, principalmente devido à geração de código dinâmico (ex: eval, Function()) ou ofuscação que quebra a análise de fluxo de dados estática.
• Dependência de APIs Predefinidas: O framework depende de uma lista curada de APIs sensíveis. Pode falhar em detectar novos vetores de ataque que explorem primitivas do Node.js anteriormente não vistas ou cadeias de chamadas indiretas não presentes no inventário.
• Ofuscação: O atual método estático não consegue lidar com pacotes fortemente ofuscados sem uma etapa de pré-processamento de desofuscação.

Os autores concluem que, embora o método melhore significamente o desempenho de detecção em relação às linhas de base, trabalhos futuros devem abordar a desofuscação, a integração de análise dinâmica e a expansão do inventário de APIs para lidar com técnicas de evasão mais sofisticadas.