Faz um ano desde que um grupo de fornecedores de segurança: Aikido Security, Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, fez um fork do Semgrep para criar o Opengrep. O objetivo principal era simples: manter as capacidades de análise estática disponíveis em código aberto e criar o motor mais avançado.
O projeto focou em quatro áreas de trabalho que eram difíceis ou impossíveis dentro do Semgrep CE na época: migração para OCaml 5 com paralelismo de memória compartilhada, introdução de análise de taint cross-function intra-arquivo, expansão do suporte a linguagens (incluindo Visual Basic, Apex e Elixir) e habilitação de suporte nativo para Windows. Desde então, o Semgrep seguiu com sua própria migração para OCaml 5 e suporte para Windows, refletindo prioridades técnicas semelhantes.
Um ano depois, essas mudanças estão começando a mostrar resultados mensuráveis, enquanto permanecem totalmente compatíveis com as regras e configurações existentes:
- Scans 25–74% mais rápidos ao executar conjuntos completos de regras em grandes repositórios
- Análise de taint até 2x mais rápida, permitindo verificações de segurança de fluxo de dados mais profundas
- 1,74 milhão de downloads de binários de releases do GitHub
- Mais de 2.000 estrelas no GitHub
- 10 empresas de segurança usando Opengrep em produção
Mas o primeiro ano de um fork de código aberto não se trata apenas de entregar funcionalidades. Trata-se de construir confiança no projeto, provar que os objetivos por trás do fork se mantêm ao longo do tempo, estabelecer governança e melhorar as práticas de segurança à medida que o projeto amadurece. Isso está descrito em nosso manifesto e no README do nosso repositório.
Esta publicação reflete sobre o que funcionou, o que precisou de melhoria e o que vem a seguir para o Opengrep.
Q&A com os Mantenedores
Hoje, o Opengrep é mantido por Dimitris Mostrous, Maciej Piróg e Corneliu Hoffman.
Neste Q&A, fazemos a eles todas as perguntas importantes sobre o Opengrep.
P. O que o fork possibilitou que não era possível dentro do Semgrep na época?
R. O fork nos permitiu tomar várias decisões arquitetônicas que teriam sido difíceis dentro do projeto upstream existente.
Primeiro, migramos o motor para OCaml 5 com paralelismo de memória compartilhada. Na época, o Semgrep ainda usava um modelo de concorrência baseado em fork, o que tornava certas melhorias, como o suporte para Windows, extremamente difíceis. A mudança para OCaml 5 estabeleceu uma base melhor para melhorias de desempenho e suporte multiplataforma. Como resultado, conseguimos introduzir suporte nativo para Windows.
Em seguida, tornamos a análise de taint cross-function disponível em código aberto para uso por qualquer fornecedor terceirizado. No Opengrep, ela está disponível via a flag --taint-intrafile, incluindo suporte para funções de ordem superior em várias linguagens.
Também expandimos o suporte a linguagens, adicionando Visual Basic e habilitando Apex e Elixir no motor de código aberto. O suporte a taint para Clojure também foi adicionado.
Finalmente, o fork nos permitiu remover telemetria e dependências de serviços proprietários.
P. Onde posso ver uma diferença mensurável entre Opengrep e Semgrep CE?
R. O Opengrep se mostra mais rápido tanto para varredura de regras de busca quanto para varredura de regras de taint. Ele tem melhor detecção de taint, com mais achados em cenários multi-hop (por exemplo, 25 vs 5 no ComfyUI com regras de taint). Também é mais fácil de executar em uma gama mais ampla de ambientes. O Opengrep é distribuído como um binário autocontido sem dependência de Python, suporta mais linguagens de forma nativa e introduz funcionalidades como timeouts por regra, timeouts dinâmicos baseados no tamanho do arquivo e anotações de ignorar configuráveis.
P. Que trabalho de engenharia foi realizado no primeiro ano?
R. Por trás das melhorias de desempenho e novas capacidades, houve um volume significativo de trabalho de engenharia:
- 43 releases entregues
- 1.116 commits em 318 pull requests
- 1.546 arquivos modificados
- 21 contribuidores envolvidos no projeto
A maior parte do desenvolvimento foi liderada pelos três mantenedores principais, mas o projeto também começou a atrair contribuições externas. No primeiro ano, 17 contribuidores externos enviaram 29 pull requests. As contribuições externas incluem taint tracking e melhorias de linguagem (funções de escopo Kotlin), infraestrutura de distribuição (script de instalação) e melhorias de saída (fingerprinting). A barreira de entrada é alta: a base de código tem aproximadamente 200 mil linhas de OCaml, e contribuir com um recurso de linguagem exige a compreensão de como as linguagens são analisadas, traduzidas para a AST genérica e como as representações intermediárias e o motor de taint funcionam. É um objetivo chave para nós expandir a base de contribuidores externos para 2026.
P. O que deu errado?
R. Não garantimos o nome do pacote no pypi e distribuímos wheels em nosso release. Em combinação com uma má configuração, isso criou um caminho para um usuário mal-intencionado sequestrar o pacote.
Governança e sustentabilidade a longo prazo
A equipe de mantenedores (Dimitris Mostrous, Maciej Piróg e Corneliu Hoffman) é responsável pela direção técnica do projeto, incluindo a revisão de contribuições, a manutenção de releases e a orientação do roadmap.
Opengrep começou como um esforço colaborativo entre várias empresas no ecossistema de segurança que compartilhavam o objetivo de manter capacidades avançadas de análise estática disponíveis em código aberto. Hoje, o projeto é gerenciado pela equipe de mantenedores e desenvolvido abertamente no GitHub, com discussões de roadmap e decisões técnicas visíveis para a comunidade.
Olhando para o futuro, o objetivo é continuar expandindo a comunidade em torno do Opengrep, mantendo uma governança transparente.
Opengrep é lançado sob a licença LGPL-2.1, garantindo que o motor e seus derivados permaneçam abertos.
Por que o Opengrep é importante na era da análise de segurança por IA
Scanners de IA são probabilísticos. A mesma entrada pode produzir saídas diferentes entre as execuções, dependendo do estado do modelo, amostragem e contexto. Isso é aceitável para a caça de novas vulnerabilidades, mas cria problemas reais em pipelines de CI/CD: resultados que mudam entre as execuções comprometem a reprodutibilidade, dificultam a conformidade e corroem a confiança nas ferramentas. O Opengrep produz os mesmos resultados a partir do mesmo código e regras, sempre. Essa consistência é o que faz com que a saída da varredura funcione como um gate de pipeline, seja validada em uma auditoria e dê aos desenvolvedores um motivo para agir sobre os resultados.
Há também uma lacuna prática. Scanners de IA geralmente exigem chamadas de API, computação GPU ou ambos. Testes de James Berthoty na Latio mostraram um modelo probabilístico gastando 17 minutos e 155.000 tokens para encontrar um problema que o Opengrep detectou em 30 segundos. O Opengrep roda localmente, não precisa de serviços externos e opera com regras explícitas que as equipes podem inspecionar e ajustar. Para classes de vulnerabilidades conhecidas rodando em cada commit, a economia é clara.
Os pipelines de segurança mais robustos combinam ambos. A varredura determinística é executada primeiro, detectando padrões conhecidos de forma rápida e consistente; em seguida, o raciocínio de IA lida com a triagem, avaliação de explorabilidade e priorização. Por exemplo, o Opengrep pode alimentar a camada SAST, e a IA pode atuar para suprimir falsos positivos e avaliar a severidade no contexto. A camada determinística se torna mais valiosa em um pipeline alimentado por IA porque a IA precisa de um sinal consistente para raciocinar.
À medida que agentes de IA e assistentes de codificação se tornam parte dos fluxos de trabalho de desenvolvimento, eles precisam de ferramentas que possam ser chamadas programaticamente com saída determinística, resultados estruturados e comportamento previsível em cada invocação. O Opengrep se encaixa bem nesse padrão e pode se integrar a fluxos de trabalho de IA programaticamente ou usando nossa skill de agente oficial. Além disso, agentes de codificação podem ser usados para definir regras que, por sua vez, podem ser usadas para escanear de forma eficiente e em escala usando o Opengrep.
O que vem a seguir para o Opengrep?
Com a arquitetura central agora estabelecida, a próxima fase do Opengrep foca na expansão das capacidades do motor e na melhoria da usabilidade. Muitas de nossas prioridades vêm diretamente do feedback de usuários em produção e contribuidores da comunidade.
Uma das maiores prioridades é a análise de taint entre arquivos, permitindo que o motor rastreie como dados não confiáveis fluem por múltiplos arquivos, em vez de apenas dentro de um único arquivo. Isso melhorará significativamente a detecção de vulnerabilidades complexas em bases de código reais.
Outro marco é a remoção do wrapper Python restante, avançando para um binário OCaml totalmente autônomo e simplificando a instalação e o uso de CI. Nosso roadmap também inclui suporte a novas linguagens, melhorias nas gramáticas de linguagens existentes e uma distribuição mais ampla através de gerenciadores de pacotes como Homebrew, Winget e apt.
Nosso roadmap é ambicioso, mas o foco permanece em construir um motor de análise estática rápido e capaz que permaneça abertamente disponível para desenvolvedores e equipes de segurança.
