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 crear Opengrep. El objetivo subyacente era sencillo: 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, en aquel momento, resultaban difíciles o imposibles de abordar dentro de Semgrep : la migración a OCaml 5 con paralelismo de memoria compartida, la introducción del análisis de contaminación entre funciones dentro de un mismo archivo, la ampliación de la compatibilidad con otros lenguajes (incluidos Visual Basic, Apex y Elixir) y la implementación de la compatibilidad nativa con Windows. Desde entonces, Semgrep llevado a cabo su propia migración a OCaml 5 y ha incorporado la compatibilidad con Windows, lo que refleja unas prioridades técnicas similares.
Un año después, esos cambios están empezando a dar resultados tangibles, sin dejar de ser totalmente compatibles con las normas y configuraciones existentes:
- Escaneos entre un 25 % y un 74 % más rápidos al ejecutar conjuntos completos de reglas en repositorios de gran tamaño
- Análisis de contaminación hasta dos veces más rápido, lo que permite realizar comprobaciones de seguridad del flujo de datos más exhaustivas
- 1,74 millones de descargas de archivos binarios de las versiones de GitHub
- Más de 2000 estrellas en GitHub
- 10 empresas de seguridad que utilizan Opengrep en entornos de producción
Pero el primer año de una bifurcación de código abierto no consiste solo en lanzar nuevas funciones. Se trata de generar confianza en el proyecto, demostrar que los objetivos que motivaron la bifurcación se mantienen a lo largo del tiempo, establecer un sistema de gobernanza y mejorar las prácticas de seguridad a medida que el proyecto madura. Todo esto se describe en nuestro manifiesto y en el archivo README de nuestro repositorio.
En esta entrada se reflexiona sobre lo que ha funcionado, lo que hay que mejorar y cuáles son los próximos pasos para Opengrep.
Preguntas y respuestas para los mantenedores
En la actualidad, Opengrep está a cargo de Dimitris Mostrous, Maciej Piróg y Corneliu Hoffman.
En esta sesión de preguntas y respuestas, les planteamos todas las cuestiones importantes relacionadas con Opengrep.
P. ¿Qué permitió el fork que no fuera posible dentro de Semgrep aquel momento?
A. La bifurcación nos permitió tomar varias decisiones arquitectónicas que habrían sido difíciles de llevar a cabo dentro del proyecto principal existente.
En primer lugar, migramos el motor a OCaml 5 con paralelismo de memoria compartida. En aquel momento, Semgrep utilizando un modelo de concurrencia basado en procesos derivados, lo que dificultaba enormemente ciertas mejoras, como la compatibilidad con Windows. El paso a OCaml 5 sentó unas bases más sólidas para mejorar el rendimiento y la compatibilidad multiplataforma. Como resultado, pudimos introducir la compatibilidad nativa con Windows.
A continuación, pusimos a disposición del público el análisis de contaminación entre funciones en código abierto para que cualquier proveedor externo pudiera utilizarlo. En Opengrep, está disponible mediante el indicador --taint-intrafile, e incluye compatibilidad con funciones de orden superior en varios lenguajes.
También hemos ampliado la compatibilidad con lenguajes, añadiendo Visual Basic y habilitando Apex y Elixir en el motor de código abierto. Además, se ha añadido compatibilidad con el sistema de «taint» de Clojure.
Por último, la bifurcación nos ha permitido eliminar la telemetría y las dependencias de servicios propietarios.
P. ¿En qué aspectos se nota una diferencia apreciable entre Opengrep y Semgrep ?
A. Opengrep ofrece resultados más rápidos tanto en el análisis de reglas de búsqueda como en el de reglas de contaminación. Cuenta con una mejor detección de contaminación, con más resultados en escenarios de múltiples saltos (por ejemplo, 25 frente a 5 en ComfyUI con reglas de contaminación). También es más fácil de ejecutar en una gama más amplia de entornos. Opengrep se distribuye como un binario autónomo sin dependencia de Python, admite más lenguajes de forma predeterminada 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é trabajos de ingeniería realizaste durante el primer año?
A. Detrás de las mejoras en el rendimiento y las nuevas funciones se escondía una importante labor de ingeniería:
- 43 envíos realizados
- 1.116 confirmaciones repartidas en 318 solicitudes de incorporación de cambios
- 1.546 archivos modificados
- 21 colaboradores que participan en el proyecto
La mayor parte del desarrollo ha estado a cargo de los tres mantenedores principales, pero el proyecto también ha comenzado a atraer contribuciones externas. Durante el primer año, 17 colaboradores externos enviaron 29 solicitudes de incorporación de cambios. Las contribuciones externas incluyen el seguimiento de taint y mejoras en el lenguaje (funciones de ámbito de Kotlin), la infraestructura de distribución (script de instalación) y mejoras en la salida (huellas digitales). La barrera de entrada es alta: el código base tiene unas 200 000 líneas de OCaml, y contribuir con una característica del lenguaje requiere comprender cómo se analizan los lenguajes, cómo se traducen al AST genérico y cómo funcionan las representaciones intermedias y el motor de contaminación. Uno de nuestros objetivos clave es ampliar la base de colaboradores externos de cara a 2026.
P. ¿En qué te equivocaste?
A. No registramos el nombre del paquete en PyPI y distribuimos archivos «wheel» en nuestra versión. Esto, junto con un error de configuración, abrió la puerta a que un usuario malintencionado se apropiara del paquete.
Gobernanza y sostenibilidad a largo plazo
El equipo de mantenimiento (Dimitris Mostrous, Maciej Piróg y Corneliu Hoffman) se encarga de la dirección técnica del proyecto, lo que incluye revisar las contribuciones, gestionar las versiones y marcar el rumbo del proyecto.
Opengrep surgió como una iniciativa de colaboración entre varias empresas del ecosistema de la seguridad que compartían el objetivo de mantener disponibles en código abierto capacidades avanzadas de análisis estático. En la actualidad, el proyecto está a cargo del equipo de mantenimiento y se desarrolla de forma abierta en GitHub, con debates sobre la hoja de ruta y decisiones técnicas a la vista de la comunidad.
De cara al futuro, el objetivo es seguir ampliando la comunidad en torno a Opengrep, manteniendo al mismo tiempo una gobernanza transparente.
Opengrep se distribuye bajo la licencia LGPL-2.1, lo que garantiza que el motor y sus derivados sigan siendo de código abierto.
Por qué Opengrep es importante en la era del análisis de seguridad basado en la IA
Los escáneres de IA son probabilísticos. Una misma entrada puede generar resultados diferentes en cada ejecución, dependiendo del estado del modelo, el muestreo y el contexto. Esto está bien para detectar vulnerabilidades nuevas, pero crea problemas reales en los procesos de CI/CD: los resultados que varían entre ejecuciones socavan la reproducibilidad, dificultan el cumplimiento normativo y minan la confianza en las herramientas. Opengrep genera los mismos resultados a partir del mismo código y las mismas reglas, siempre. Esa consistencia es lo que hace que el resultado del escaneo funcione como una puerta de control en el proceso, resista una auditoría y dé a los desarrolladores una razón para actuar ante los resultados.
También existe una limitación práctica. Los escáneres de IA suelen requerir llamadas a la API, recursos de GPU o ambos. Las pruebas realizadas por James Berthoty en Latio demostraron que un modelo probabilístico tardaba 17 minutos y consumía 155 000 tokens en detectar un problema que Opengrep detectaba en 30 segundos. Opengrep se ejecuta localmente, no necesita servicios externos y funciona con reglas explícitas que los equipos pueden inspeccionar y ajustar. Para las clases de vulnerabilidades conocidas que se ejecutan en cada commit, la rentabilidad es evidente.
Los procesos de seguridad más sólidos combinan ambas cosas. En primer lugar, se ejecuta un análisis determinista, que detecta patrones conocidos de forma rápida y sistemática; a continuación, el razonamiento basado en IA se encarga de la clasificación, la evaluación de la vulnerabilidad y la priorización. Por ejemplo, Opengrep puede impulsar la SAST , mientras que la IA se integra en la parte superior para suprimir los falsos positivos y evaluar la gravedad en su contexto. La capa determinista cobra mayor relevancia en un proceso impulsado por IA, ya que esta necesita una señal consistente sobre la que basar su razonamiento.
A medida que los agentes de IA y los asistentes de programación se integran en los flujos de trabajo de desarrollo, necesitan herramientas a las que puedan acceder mediante programación y que ofrezcan resultados deterministas, estructurados y un comportamiento predecible en cada ejecución. Opengrep se ajusta perfectamente a este perfil y puede integrarse en los flujos de trabajo de IA mediante programación o utilizando nuestra habilidad oficial para agentes. Además, los agentes de programación pueden utilizarse para definir reglas que, a su vez, permitan realizar análisis de forma eficiente y a gran escala mediante Opengrep.
¿Qué le depara el futuro a Opengrep?
Ahora que la arquitectura básica ya está en marcha, la siguiente fase de Opengrep se centra en ampliar las capacidades del motor y mejorar la usabilidad. Muchas de nuestras prioridades se derivan directamente de los comentarios de los usuarios en producción y de los colaboradores de la comunidad.
Una de las principales prioridades es el análisis de contaminación entre archivos, que permite al motor rastrear cómo fluyen los datos no fiables a través de varios archivos, en lugar de limitarse a un solo archivo. Esto mejorará considerablemente la detección de vulnerabilidades complejas en los códigos fuente reales.
Otro hito es la eliminación del envoltorio de Python restante, el avance hacia un binario de OCaml totalmente independiente y la simplificación de la instalación y el uso de la integración continua (CI). Nuestra hoja de ruta también incluye la compatibilidad con nuevos lenguajes, mejoras en las gramáticas de los 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 nuestro objetivo sigue siendo crear un motor de análisis estático rápido y eficaz que siga estando a disposición de los desarrolladores y los equipos de seguridad.
