Ha pasado un año desde que un grupo de proveedores de seguridad: Aikido Security, Arnica, Amplify, Endor Labs, Jit, Kodem, Legit, Mobb, Orca Security, Phoenix Security, bifurcaron Semgrep para crear Opengrep. El objetivo subyacente era simple: mantener las capacidades de análisis estático disponibles en código abierto y crear el motor más avanzado.
El proyecto se centró en cuatro áreas de trabajo que eran difíciles o imposibles dentro de Semgrep CE en ese momento: la migración a OCaml 5 con paralelismo de memoria compartida, la introducción del análisis de taint intra-archivo entre funciones, la expansión del soporte de lenguajes (incluyendo Visual Basic, Apex y Elixir), y la habilitación del soporte nativo para Windows. Desde entonces, Semgrep ha seguido con su propia migración a OCaml 5 y soporte para Windows, reflejando prioridades técnicas similares.
Un año después, esos cambios están empezando a mostrar resultados medibles, mientras que siguen siendo totalmente compatibles con las reglas y configuraciones existentes:
- Escaneos entre un 25 y un 74% más rápidos al ejecutar conjuntos completos de reglas en grandes repositorios
- Análisis de taint hasta 2 veces más rápido, lo que permite comprobaciones de seguridad de flujo de datos más profundas
- 1,74 millones de descargas de binarios desde lanzamientos de GitHub
- Más de 2.000 estrellas en GitHub
- 10 empresas de seguridad que utilizan Opengrep en producción
Pero el primer año de una bifurcación de código abierto no se trata solo de lanzar funcionalidades. Se trata de generar confianza en el proyecto, demostrar que los objetivos detrás de la bifurcación se mantienen a lo largo del tiempo, establecer una gobernanza y mejorar las prácticas de seguridad a medida que el proyecto madura. Esto se describe en nuestro manifiesto y en el README de nuestro repositorio.
Esta publicación reflexiona sobre lo que funcionó, lo que necesitaba mejorar y lo que sigue para Opengrep.
Preguntas y respuestas con los mantenedores
Hoy, Opengrep es mantenido por Dimitris Mostrous, Maciej Piróg y Corneliu Hoffman.
En esta sesión de preguntas y respuestas, les hacemos todas las preguntas importantes sobre Opengrep.
P. ¿Qué permitió la bifurcación que no era posible dentro de Semgrep en ese momento?
R. La bifurcación nos permitió tomar varias decisiones arquitectónicas que habrían sido difíciles dentro del proyecto upstream existente.
Primero, migramos el motor a OCaml 5 con paralelismo de memoria compartida. En ese momento, Semgrep todavía utilizaba un modelo de concurrencia basado en bifurcaciones, lo que dificultaba enormemente ciertas mejoras como el soporte para Windows. La migración a OCaml 5 estableció una base mejor para las mejoras de rendimiento y el soporte multiplataforma. Como resultado, pudimos introducir soporte nativo para Windows.
Luego, pusimos a disposición el análisis de taint entre funciones en código abierto para el uso de cualquier proveedor externo. En Opengrep está disponible a través de la flag --taint-intrafile, incluyendo soporte para funciones de orden superior en múltiples lenguajes.
También ampliamos el soporte de lenguajes, añadiendo Visual Basic y habilitando Apex y Elixir en el motor de código abierto. También se añadió soporte de taint para Clojure.
Finalmente, la bifurcación nos permitió eliminar la telemetría y las dependencias de servicios propietarios.
P. ¿Dónde puedo ver una diferencia medible entre Opengrep y Semgrep CE?
R. Opengrep resulta más rápido tanto para el escaneo de reglas de búsqueda como para el escaneo de reglas de taint. Ofrece una mejor detección de taint, con más hallazgos en escenarios de múltiples saltos (por ejemplo, 25 frente a 5 en ComfyUI con reglas de taint). También es más fácil de ejecutar en una gama más amplia de entornos. Opengrep se distribuye como un binario autocontenido sin dependencia de Python, soporta más lenguajes de forma nativa e introduce características como tiempos de espera por regla, tiempos de espera dinámicos basados en el tamaño del archivo y anotaciones de ignorar configurables.
P. ¿Qué trabajo de ingeniería se llevó a cabo durante el primer año?
R. Detrás de las mejoras de rendimiento y las nuevas capacidades hubo una cantidad significativa de trabajo de ingeniería:
- 43 lanzamientos realizados
- 1.116 commits en 318 pull requests
- 1.546 archivos modificados
- 21 colaboradores involucrados en el proyecto
La mayor parte del desarrollo ha sido liderada por los tres mantenedores principales, pero el proyecto también ha empezado a atraer contribuciones externas. En el primer año, 17 colaboradores externos enviaron 29 pull requests. Las contribuciones externas incluyen el seguimiento de taint (taint tracking) y mejoras del lenguaje (funciones de ámbito de Kotlin), infraestructura de distribución (script de instalación) y mejoras de salida (fingerprinting). La barrera de entrada es alta: la base de código es de aproximadamente 200k líneas de OCaml, y contribuir con una característica de lenguaje requiere comprender cómo se analizan los lenguajes, se traducen al AST genérico y cómo funcionan las representaciones intermedias y el motor de taint. Es un objetivo clave para nosotros aumentar la base de colaboradores externos para 2026.
P. ¿Qué hicimos mal?
R. No aseguramos el nombre del paquete en pypi y distribuimos wheels en nuestra versión. En combinación con una mala configuración, esto creó una vía para que un usuario malintencionado secuestrara el paquete.
Gobernanza y sostenibilidad a largo plazo
El equipo de mantenedores (Dimitris Mostrous, Maciej Piróg y Corneliu Hoffman) es responsable de la dirección técnica del proyecto, incluyendo la revisión de contribuciones, el mantenimiento de las versiones y la guía de la hoja de ruta.
Opengrep comenzó como un esfuerzo colaborativo entre varias empresas del ecosistema de seguridad que compartían el objetivo de mantener disponibles capacidades avanzadas de análisis estático en código abierto. Hoy en día, el proyecto es gestionado por el equipo de mantenedores y desarrollado abiertamente en GitHub, con discusiones sobre la hoja de ruta y decisiones técnicas visibles para la comunidad.
De cara al futuro, el objetivo es seguir expandiendo la comunidad en torno a Opengrep manteniendo una gobernanza transparente.
Opengrep se publica bajo la licencia LGPL-2.1, asegurando que el motor y sus derivados permanezcan abiertos.
Por qué Opengrep es importante en la era del análisis de seguridad con IA
Los escáneres de IA son probabilísticos. La misma entrada puede producir diferentes salidas entre ejecuciones, dependiendo del estado del modelo, el muestreo y el contexto. Esto está bien para la búsqueda de vulnerabilidades novedosas, pero crea problemas reales en los pipelines de CI/CD: los resultados que varían entre ejecuciones socavan la reproducibilidad, dificultan el cumplimiento y erosionan la confianza en las herramientas. Opengrep produce los mismos hallazgos a partir del mismo código y reglas, siempre. Esa consistencia es lo que hace que la salida del escaneo funcione como una puerta de pipeline, se mantenga en una auditoría y dé a los desarrolladores una razón para actuar sobre los hallazgos.
También existe una brecha práctica. Los escáneres de IA suelen requerir llamadas a la API, computación GPU o ambas. Las pruebas realizadas por James Berthoty en Latio mostraron que un modelo probabilístico tardó 17 minutos y 155.000 tokens en encontrar un problema que Opengrep detectó en 30 segundos. Opengrep se ejecuta localmente, no necesita servicios externos y opera con reglas explícitas que los equipos pueden inspeccionar y ajustar. Para las clases de vulnerabilidades conocidas que se ejecutan en cada commit, la economía es clara.
Los pipelines de seguridad más sólidos superponen ambos. El escaneo determinista se ejecuta primero, detectando patrones conocidos de forma rápida y consistente, luego el razonamiento de IA se encarga del triaje, la evaluación de explotabilidad y la priorización. Por ejemplo, Opengrep puede alimentar la capa SAST, y la IA puede situarse encima para suprimir falsos positivos y evaluar la severidad en contexto. La capa determinista adquiere más valor en un pipeline impulsado por IA porque la IA necesita una señal consistente sobre la que razonar.
A medida que los agentes de IA y los asistentes de codificación se integran en los flujos de trabajo de desarrollo, necesitan herramientas que puedan invocar programáticamente con una salida determinista, resultados estructurados y un comportamiento predecible en cada invocación. Opengrep encaja bien en ese patrón y puede integrarse con los flujos de trabajo de IA programáticamente o utilizando nuestra habilidad de agente oficial. Además, los agentes de codificación pueden utilizarse para definir reglas que luego pueden emplearse para escanear de manera eficiente y a escala utilizando Opengrep.
¿Qué sigue para Opengrep?
Con la arquitectura central ya establecida, la siguiente fase de Opengrep se centra en expandir las capacidades del motor y mejorar la usabilidad. Muchas de nuestras prioridades provienen directamente de los comentarios de los usuarios en producción y los colaboradores de la comunidad.
Una de las mayores prioridades es el análisis de taint entre archivos, permitiendo que el motor rastree cómo los datos no confiables fluyen a través de múltiples archivos en lugar de solo dentro de un único archivo. Esto mejorará significativamente la detección de vulnerabilidades complejas en bases de código reales.
Otro hito es la eliminación del wrapper de Python restante, avanzando hacia un binario OCaml completamente autónomo y simplificando la instalación y el uso en CI. Nuestra hoja de ruta también incluye soporte para nuevos lenguajes, mejoras en las gramáticas de lenguajes existentes y una distribución más amplia a través de gestores de paquetes como Homebrew, Winget y apt.
Nuestra hoja de ruta es ambiciosa, pero el enfoque sigue siendo construir un motor de análisis estático rápido y capaz que permanezca abiertamente disponible para desarrolladores y equipos de seguridad.
