Operational Runtime Behavior Mining for Open-Source Supply Chain Security

Resumo Técnico: Mineração de Comportamento de Tempo de Execução Operacional para Segurança da Cadeia de Suprimentos de Código Aberto

Declaração do Problema
Os ataques à cadeia de suprimentos de software de código aberto (OSS) dependem cada vez mais de lógica maliciosa executada durante as fases de instalação, importação ou pós-instalação, as quais a análise estática frequentemente perde devido à ofuscação ou geração dinâmica. Os defensores dependem de telemetria de tempo de execução, mas esses dados são heterogêneos: algumas fontes preservam artefatos concretos (domínios, IPs, comandos), enquanto outras expõem apenas resumos comportamentais agregados (contagens de chamadas de sistema, buckets de acesso a arquivos). Isso cria uma incompatibilidade entre avaliações centradas no modelo (que tratam a detecção como uma classificação binária em nível de pacote) e as necessidades voltadas ao analista (que exigem pivôs de tempo de execução específicos e acionáveis). Além disso, os explicadores de grafos existentes identificam recursos que preservam as previsões do modelo, mas que não correspondem necessariamente a pistas de investigação acionáveis, pois arestas de alta importância podem refletir comportamentos benignos comuns ou ruído ambiental. O desafio central é a caça limitada pela observabilidade: a especificidade das evidências de investigação é estritamente limitada pelo que a fonte de telemetria registra.

Metodologia: Framework HetHunt
Os autores apresentam o HetHunt, um framework de caça em grafos de tempo de execução consciente da observabilidade, projetado para conectar a previsão de risco em nível de pacote e a investigação voltada ao analista. O framework opera em três etapas:

1. Grafos Canônicos de Evidência de Tempo de Execução:

   • O HetHunt mapeia telemetria de tempo de execução heterogênea de diferentes fontes (rastreamentos em nível de evento e resumos agregados) para um esquema de grafo heterogêneo tipado e compartilhado.
   • A ontologia inclui seis tipos de nós: PKG (identidade do pacote), PROC (instância de processo), FILE, NET (ponto de extremidade de rede), SYSCALL e CMD (string de comando).
   • Onze tipos de arestas codificam interações (por exemplo, LOAD, DEPEND, EXEC, READ, CONNECT). Uma característica chave de design é a camada intermediária PROC, criando caminhos de múltiplos saltos (por exemplo, PKG → PROC → FILE) para distinguir comportamentos como gravações no momento da instalação de conexões de rede no momento da importação.

2. Codificador de Grafo Relacional (Previsão de Risco):

   • O framework utiliza uma Rede de Convolução de Grafo Relacional (R-GCN) para aprender o risco em nível de pacote a partir da estrutura do grafo.
   • Embora outros codificadores (GAT, HAN, HGT) tenham sido avaliados, o R-GCN foi selecionado para o pipeline final devido ao seu equilíbrio entre desempenho competitivo de classificação, menor latência de inferência e uma interface de aresta tipada direta adequada para mapear pontuações de volta para pivôs de tempo de execução.

3. Da Importância à Suspeitosidade (A Camada de Caça):

   • Aprendizado de Importância de Arestas: Um módulo de máscara de aresta aprendível (inspirado no PGExplainer) identifica interações de tempo de execução mais influentes para a previsão do modelo.
   • Filtragem Ambiental: Filtros baseados em regras suprimem ruído de fundo de alta frequência (por exemplo, registros comuns, caminhos do sistema, comandos de sondagem rotineiros) para evitar que comportamentos benignos compartilhados dominem a classificação.
   • Calibração de Raridade Benigna: Para converter a importância de arestas voltada ao modelo em suspeitosidade voltada ao analista, o framework calibra as pontuações contra uma população de referência benigna. A pontuação de suspeitosidade de uma aresta é calculada como:
     $$s(e) = \text{importância}(e) \times (1 + \alpha \cdot \text{raridade}(e))$$
     onde a raridade é derivada da frequência de documentos da aresta de destino em pacotes benignos. Isso garante que arestas influentes também sejam incomuns em relação ao comportamento normal.
   • Pontuação em Nível de Grafo: Os pacotes são classificados pela média de suspeitosidade de suas top-$K$ arestas retidas, priorizando grafos com evidências concentradas de alta suspeitosidade.

Principais Contribuições

1. Formulação de Caça Limitada pela Observabilidade: O artigo formula a caça à cadeia de suprimentos de tempo de execução como um problema de grafo onde as saídas são explicitamente limitadas pela granularidade da telemetria, distinguindo entre evidências em nível de IOC, nível de TTP, contextuais e lacunas de telemetria.
2. Grafos Canônicos de Evidência de Tempo de Execução: Um esquema de grafo tipado e compacto que unifica telemetria heterogênea de execução de pacotes (de fontes em nível de evento e agregadas) em uma representação compartilhada.
3. Framework de Suspeitosidade HetHunt: Um pipeline de ponta a ponta que desacopla o risco do pacote, a importância de arestas voltada ao modelo e a suspeitosidade voltada ao analista, utilizando filtragem ambiental e calibração de raridade benigna consciente de relações.
4. Avaliação Orientada à Caça: Um protocolo de avaliação novel que avalia não apenas a precisão da classificação de pacotes, mas a qualidade das classificações derivadas de arestas e a especificidade dos pivôs superficiais em diferentes granularidades de telemetria.

Avaliação e Resultados
O framework foi avaliado em dois conjuntos de dados:

• QUT-DV25: 14.271 pacotes Python com telemetria de análise dinâmica agregada e estável.
• OSPTrack: 9.758 execuções de sandbox entre ecossistemas com telemetria em nível de evento (domínios, IPs, comandos).

Principais Descobertas:

• QUT-DV25 (Telemetria Agregada): O HetHunt calibrado por raridade alcançou forte desempenho de classificação (0,876 AUROC, 0,880 AUPRC e Precisão@100 perfeita). No entanto, os pivôs superficiais eram principalmente em nível de TTP ou contextuais (por exemplo, "conexão de rede no momento da instalação") em vez de IOCs concretos, refletindo a natureza agregada dos dados.
• OSPTrack (Telemetria em Nível de Evento): Embora este conjunto de dados preservasse artefatos concretos (IOCs), o alto volume de ruído ambiental (atividade de gerenciador de pacotes, acesso a registros) limitou o alerta confiável com baixa FPR. A calibração de raridade melhorou a classificação quando restrita a relações de rede, mas a precisão no topo da lista permaneceu fraca.
• Utilidade para o Analista: A anotação dos principais pivôs confirmou que alta qualidade de classificação não garante alta especificidade de pivô. O QUT-DV25 produziu evidências abstratas, enquanto o OSPTrack produziu candidatos concretos, mas frequentemente locais ao pacote ou impulsionados pelo ambiente.
• Volume de Telemetria vs. Observabilidade: Maior volume de telemetria não correlacionou com melhor utilidade de caça; no OSPTrack, os rastreamentos de maior volume eram dominados por atividade benigna, enquanto rastreamentos mais limpos e de menor volume produziram melhor qualidade de classificação.

Significado e Alegações
O artigo alega que explicações de grafos de tempo de execução devem ser calibradas à observabilidade da telemetria antes de poderem apoiar a caça operacional. O HetHunt demonstra que grafos de tempo de execução heterogêneos podem efetivamente preencher a lacuna entre a previsão de risco em nível de pacote e a investigação do analista, desde que:

1. As explicações sejam tratadas como pivôs de investigação limitados pela telemetria e não como Indicadores de Comprometimento (IOCs) confirmados.
2. A calibração de raridade benigna seja aplicada para distinguir arestas influentes para o modelo do ruído de fundo comum.
3. A especificidade da saída (IOC vs. TTP vs. Contextual) seja entendida como uma função da fonte de telemetria subjacente, e não apenas da capacidade do modelo.

Os autores enfatizam que o HetHunt não substitui classificadores em nível de pacote, mas fornece os "pivôs de tempo de execução" necessários para orientar a inspeção do analista, reconhecendo que a falta de indicadores concretos pode refletir lacunas de telemetria ou comportamentos não acionados, e não falhas de explicação.