Já passou um ano desde que um grupo de fornecedores de segurança: Aikido , Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, fizeram um fork Semgrep criar o Opengrep. O objetivo subjacente 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 centrou-se em quatro áreas de trabalho que, na altura, eram difíceis ou impossíveis de realizar no âmbito Semgrep : a migração para o OCaml 5 com paralelismo de memória partilhada, a introdução da análise de contaminação entre funções dentro do mesmo ficheiro, a expansão do suporte a linguagens (incluindo Visual Basic, Apex e Elixir) e a implementação do suporte nativo ao Windows. Desde então, Semgrep com a sua própria migração para o OCaml 5 e com o suporte ao Windows, refletindo prioridades técnicas semelhantes.
Um ano depois, essas alterações começam a dar resultados mensuráveis, mantendo-se totalmente compatíveis com as regras e configurações existentes:
- Análises 25 a 74 % mais rápidas ao executar conjuntos completos de regras em grandes repositórios
- Análise de contaminação até 2 vezes mais rápida, permitindo verificações de segurança mais aprofundadas do fluxo de dados
- 1,74 milhões de downloads de ficheiros binários das versões do GitHub
- Mais de 2 000 estrelas no GitHub
- 10 empresas de segurança que utilizam o Opengrep em ambiente de produção
Mas o primeiro ano de um fork de código aberto não se resume apenas ao lançamento de funcionalidades. Trata-se de criar confiança no projeto, provar que os objetivos subjacentes ao fork se mantêm ao longo do tempo, estabelecer uma estrutura de governação e melhorar as práticas de segurança à medida que o projeto amadurece. Isto está descrito no nosso manifesto e no ficheiro README do nosso repositório.
Este artigo reflete sobre o que funcionou, o que precisava de ser melhorado e o que se segue para o Opengrep.
Perguntas e respostas do responsável pela manutenção
Atualmente, o Opengrep é mantido por Dimitris Mostrous, Maciej Piróg e Corneliu Hoffman.
Nesta sessão de perguntas e respostas, colocamos todas as questões importantes sobre o Opengrep.
P. O que é que o fork permitiu fazer que não era possível no Semgrep altura?
A. A bifurcação permitiu-nos tomar várias decisões arquitetónicas que teriam sido difíceis de implementar no projeto principal existente.
Em primeiro lugar, migramos o motor para o OCaml 5 com paralelismo de memória partilhada. Na altura, Semgrep ainda Semgrep um modelo de concorrência baseado em forks, o que tornava certas melhorias, como o suporte ao Windows, extremamente difíceis. A migração para o OCaml 5 estabeleceu uma base mais sólida para melhorias de desempenho e suporte multiplataforma. Como resultado, conseguimos introduzir o suporte nativo ao Windows.
Posteriormente, disponibilizámos a análise de contaminação entre funções em código aberto para utilização por qualquer fornecedor externo. No Opengrep, esta funcionalidade está disponível através da opção --taint-intrafile, incluindo suporte para funções de ordem superior em várias linguagens de programação.
Também alargámos o suporte a linguagens de programação, adicionando o Visual Basic e ativando o Apex e o Elixir no motor de código aberto. Foi ainda adicionado suporte para o mecanismo de «taint» do Clojure.
Por fim, o fork permitiu-nos eliminar a telemetria e as dependências de serviços proprietários.
P. Onde posso ver uma diferença tangível entre o Opengrep e Semgrep ?
A. O Opengrep apresenta resultados mais rápidos tanto na análise de regras de pesquisa como na análise de regras de contaminação. Possui uma melhor deteção de contaminação, com mais resultados em cenários de múltiplos saltos (por exemplo, 25 contra 5 no ComfyUI com regras de contaminação). É também mais fácil de executar numa gama mais ampla de ambientes. O Opengrep é fornecido como um binário autónomo sem dependência de Python, suporta mais linguagens de forma nativa e introduz funcionalidades como tempos de espera por regra, tempos de espera dinâmicos com base no tamanho do ficheiro e anotações de ignorar configuráveis.
P. Que trabalhos de engenharia realizou no primeiro ano?
A. Por trás das melhorias de desempenho e das novas funcionalidades, esteve um trabalho de engenharia considerável:
- 43 versões lançadas
- 1 116 commits em 318 pull requests
- 1 546 ficheiros modificados
- 21 colaboradores envolvidos no projeto
A maior parte do desenvolvimento tem sido liderada pelos três principais mantenedores, mas o projeto também começou a atrair contribuições externas. No primeiro ano, 17 colaboradores externos enviaram 29 pull requests. As contribuições externas incluem o rastreamento de contaminação e melhorias na linguagem (funções de escopo Kotlin), infraestrutura de distribuição (script de instalação) e melhorias na saída (identificação digital). A barreira à entrada é elevada: a base de código tem cerca de 200 mil linhas de OCaml, e contribuir com uma funcionalidade da linguagem requer compreender como as linguagens são analisadas, traduzidas para a AST genérica e como funcionam as representações intermédias e o motor de contaminação. É um objetivo fundamental para nós aumentar a base de colaboradores externos até 2026.
P. O que é que fizeste de errado?
A. Não protegemos o nome do pacote no PyPI e distribuímos ficheiros wheel na nossa versão. Em combinação com uma configuração incorreta, isto criou uma brecha que permitiu a um utilizador mal-intencionado sequestrar o pacote.
Governança e sustentabilidade a longo prazo
A equipa de mantenedores (Dimitris Mostrous, Maciej Piróg e Corneliu Hoffman) é responsável pela orientação técnica do projeto, incluindo a revisão das contribuições, a manutenção das versões e a definição do plano de desenvolvimento.
O Opengrep surgiu como um esforço colaborativo entre várias empresas do ecossistema de segurança que partilhavam o objetivo de manter disponíveis, em código aberto, capacidades avançadas de análise estática. Atualmente, o projeto é gerido pela equipa de mantenedores e desenvolvido abertamente no GitHub, sendo que as discussões sobre o roteiro e as decisões técnicas estão à vista da comunidade.
Olhando para o futuro, o objetivo é continuar a expandir a comunidade em torno do Opengrep, mantendo uma governação transparente.
O Opengrep é distribuído sob a licença LGPL-2.1, garantindo que o motor e os seus derivados permaneçam abertos.
Por que é que o Opengrep é importante na era da análise de segurança com IA
Os scanners de IA são probabilísticos. A mesma entrada pode produzir resultados diferentes entre execuções, dependendo do estado do modelo, da amostragem e do contexto. Isso é adequado para a deteção de novas vulnerabilidades, mas cria problemas reais nos pipelines de CI/CD: resultados que variam entre execuções comprometem a reprodutibilidade, dificultam a conformidade e minam a confiança nas ferramentas. O Opengrep produz sempre os mesmos resultados a partir do mesmo código e das mesmas regras. É essa consistência que faz com que os resultados da verificação funcionem como um filtro do pipeline, resistam a uma auditoria e dêem aos programadores um motivo para agir com base nos resultados.
Existe também uma lacuna prática. Os scanners de IA requerem normalmente chamadas de API, computação por GPU ou ambas as coisas. Testes realizados por James Berthoty na Latio mostraram que um modelo probabilístico demorou 17 minutos e gastou 155 000 tokens para encontrar um problema que o Opengrep detetou em 30 segundos. O Opengrep é executado localmente, não necessita de serviços externos e opera com base em regras explícitas que as equipas podem inspecionar e ajustar. Para classes de vulnerabilidades conhecidas executadas em cada commit, a vantagem económica é evidente.
Os pipelines de segurança mais robustos combinam ambas as abordagens. A análise determinística é executada em primeiro lugar, detetando padrões conhecidos de forma rápida e consistente; em seguida, o raciocínio da IA encarrega-se da triagem, da avaliação da vulnerabilidade e da definição de prioridades. Por exemplo, o Opengrep pode alimentar a SAST , e a IA pode ser integrada na camada superior para suprimir falsos positivos e avaliar a gravidade do problema no contexto. A camada determinística ganha ainda mais valor num pipeline alimentado por IA, uma vez que a IA necessita de sinais consistentes para poder raciocinar.
À medida que os agentes de IA e os assistentes de programação se tornam parte integrante dos fluxos de trabalho de desenvolvimento, necessitam de ferramentas que possam ser chamadas programaticamente, com resultados determinísticos, estruturados e um comportamento previsível em cada invocação. O Opengrep encaixa-se perfeitamente nesse padrão e pode integrar-se nos fluxos de trabalho de IA programaticamente ou através da nossa funcionalidade oficial para agentes. Além disso, os agentes de programação podem ser utilizados para definir regras que, por sua vez, podem ser aplicadas para realizar análises de forma eficiente e em grande escala utilizando o Opengrep.
O que se segue para o Opengrep?
Com a arquitetura central já implementada, a próxima fase do Opengrep centra-se na expansão das capacidades do motor e na melhoria da usabilidade. Muitas das nossas prioridades resultam diretamente do feedback dos utilizadores em produção e dos colaboradores da comunidade.
Uma das principais prioridades é a análise de contaminação entre ficheiros, permitindo que o motor acompanhe a forma como os dados não confiáveis circulam entre vários ficheiros, em vez de apenas dentro de um único ficheiro. Isto irá melhorar significativamente a deteção de vulnerabilidades complexas em bases de código reais.
Outro marco importante é a remoção do wrapper Python remanescente, avançando para um binário OCaml totalmente autónomo e simplificando a instalação e a utilização da integração contínua (CI). O nosso plano de desenvolvimento inclui também o suporte a novas linguagens, melhorias nas gramáticas das linguagens existentes e uma distribuição mais ampla através de gestores de pacotes como o Homebrew, o Winget e o apt.
O nosso plano de ação é ambicioso, mas o nosso foco continua a ser a criação de um motor de análise estática rápido e eficaz, que permaneça disponível gratuitamente para programadores e equipas de segurança.
