A PhonePe, empresa indiana de pagamentos digitais, lançou em código aberto uma ferramenta de análise de código que rastreia dados não confiáveis através de múltiplos ficheiros de aplicações Java. A ferramenta, chamada Nika, realiza taint analysis cross-file para detetar vulnerabilidades que scanners file-by-file não conseguem encontrar, cobrindo onze categorias de falhas de segurança.
Pontos-chave
Nika está disponível no GitHub sob licença Apache 2.0 e foi desenhada para engenheiros de segurança que fazem revisão de código em microserviços Java. A ferramenta identifica onde input controlado por atacante entra na aplicação, localiza operações sensíveis como consultas a base de dados, e traça o caminho dos dados entre esses dois pontos. Um passo opcional de revisão por IA pode reduzir falsos positivos. A equipa mediu a ferramenta contra o benchmark OWASP Java.
O problema dos fluxos cross-file
Muitas vulnerabilidades graves em aplicações web não vivem dentro de um único ficheiro. Dados de pedido entram por um controller, viajam por objetos de transferência e camadas de serviço, e só se tornam perigosos quando chegam a uma operação sensível como uma query SQL ou uma escrita em ficheiro. Um scanner que lê um ficheiro de cada vez perde esse caminho por completo.
É exatamente esse o problema que Nika resolve. Em vez de identificar apenas sinks perigosos, a ferramenta rastreia o fluxo de dados através de ficheiros e funções para que um engenheiro de segurança consiga determinar se um caminho é realmente alcançável na prática. A diferença entre um sink perigoso e um sink explorável é o caminho que os dados percorrem até lá chegar.
Como a análise funciona
Nika lê o repositório alvo e constrói uma representação de análise que captura a estrutura do código, o fluxo de controlo e o fluxo de dados. A partir daí localiza as fontes onde input controlado por atacante entra na aplicação: parâmetros de pedido HTTP, cabeçalhos, cookies, payloads deserializados. Depois localiza os sinks onde operações sensíveis acontecem.
Um sink pode ser uma consulta a base de dados, uma operação de ficheiro, um motor de templates, uma chamada de reflexão ou um pedido de rede outbound. A análise cross-file e inter-procedural traça se o input consegue viajar de uma fonte até ao sink. O resultado é um relatório HTML ou JSON que mostra o caminho vulnerável, as localizações de código afetadas e contexto para a remediação.
Onze categorias de deteção
A ferramenta cobre onze categorias de vulnerabilidade. Incluem injeção SQL, SSRF, path traversal, injeção de comandos, injeção de código, injeção de templates, falhas de deserialização, problemas de XML external entity, falhas criptográficas e reflexão insegura. Nika verifica ainda violações de ordem de chamada em fluxos de execução sensíveis e cadeias de validação.
As equipas podem alargar a cobertura com fontes personalizadas, sinks OpenGrep e plugins de vulnerabilidade. O scanning branch-aware permite apontar a ferramenta apenas para as alterações sob revisão, o que se encaixa num fluxo de trabalho de revisão de código seguro onde se analisa o que mudou num pull request específico.
Revisão por IA opcional
Depois de a análise principal correr, Nika pode passar as descobertas a um agente de IA para uma segunda análise que reduz falsos positivos. Este passo fica desligado por defeito e ativa-se através de uma definição de configuração. A configuração de exemplo aponta a revisão para um modelo de linguagem alojado e inclui valores para custo de tokens, contagens de iteração e limites de chamadas.
Manter o passo opcional permite a uma equipa executar o motor estático sozinho e adicionar a passagem com modelo de linguagem só quando o tempo de triagem aperta. Isto dá controlo sobre custo e privacidade: quem não quer enviar código para um serviço externo pode usar apenas a análise estática sem depender de IA.
Validação contra benchmark público
A equipa por trás de Nika mediu a ferramenta contra o projeto de benchmark OWASP Java. Praveen Kanniah, um dos responsáveis pelo projeto, explicou o método: o benchmark contém ficheiros propositadamente vulneráveis e avalia ferramentas segundo parâmetros como verdadeiros positivos, falsos positivos e recall, que mede a parte das vulnerabilidades existentes que a ferramenta consegue revelar.
O benchmark OWASP fornece código com falhas plantadas, o que permite pontuar os resultados de um scanner consoante quantos problemas reais deteta e quantos alertas se confirmam. Esta validação dá uma base de comparação objetiva com outros scanners do mercado. Java é a única linguagem totalmente suportada nesta fase, com mais linguagens planeadas no roadmap.
Ferramenta que completa o ciclo
Nika surge num momento em que a análise de segurança de código ganha ferramentas que combinam técnicas clássicas com IA. Enquanto scanners como o AgentGG usam IA para confirmar falhas antes de reportar, Nika aposta na análise taint clássica cross-file e mantém a IA como camada opcional. As duas abordagens respondem a necessidades diferentes.
Para equipas que já trabalham com scanners de dependências em CI, Nika preenche o espaço que esses scanners não cobrem: vulnerabilidades no código próprio da aplicação, não nas bibliotecas de terceiros. A combinação de análise de dependências com taint analysis no código-fonte dá uma visão mais completa do risco de uma aplicação.
O que fazer agora
Equipas com microserviços Java devem testar Nika num repositório representativo. A ferramenta distribui-se como imagem Docker pré-compilada ou compilação local, pelo que a instalação não exige configuração complexa. O repositório oficial está em github.com/PhonePe/nika, com documentação detalhada e exemplos de configuração.
O ponto de partida é executar um scanning completo do repositório para estabelecer uma linha de base de descobertas. Depois integra-se o scanning branch-aware no processo de revisão de código para que cada alteração seja analisada antes de chegar a produção. Para reduzir ruído nos primeiros relatórios, ativa-se a revisão por IA apenas nas categorias com mais falsos positivos.