
Motor de grafo de conocimiento heurístico sin AST para inteligencia profunda de repositorios y escaneo de seguridad de confianza cero. Se integra como componente de GitLab CI/CD, bloquea código hostil y exporta telemetría SARIF al panel de seguridad de GitLab.
Inteligencia estructural a escala de repositorio sin compilación.
Docs · Visualizer · Language Crucible · Raw Output
1 escaneo · 97 señales estructurales · 50+ lenguajes · sin compilación · 19 categorías de exposición al riesgo · 6 salidas
GitGalaxy construye un grafo estructural agnóstico al lenguaje de un repositorio completo directamente desde el texto fuente.
Está diseñado para repositorios que son políglotas, parcialmente rotos, heredados, con mucho código de terceros, o difíciles de analizar mediante un flujo de trabajo basado en compilación.
En lugar de requerir una compilación exitosa y un parser/herramienta separado para cada lenguaje, GitGalaxy extrae un vocabulario común de firmas estructurales---funciones, clases, argumentos, flujo de control, mutación de estado, E/S, APIs, dependencias y otras señales---y normaliza esas observaciones en un único modelo de repositorio.
El mismo grafo puede alimentar luego:
Tesis central: el análisis sintáctico completo del lenguaje no siempre es necesario para recuperar información estructural altamente útil a escala de repositorio.
Los repositorios grandes contienen rutinariamente:``` text Go + C++ + Python + Java + Bash + YAML
Las herramientas tradicionales por lenguaje pueden ser excelentes dentro de su alcance previsto
y, aun así, dejar el repositorio fragmentado entre representaciones específicas de cada lenguaje.
GitGalaxy adopta una compensación diferente:``` text
Source repository
|
v
Structural signatures
|
v
Normalized entities + risk signals
|
v
Deterministic repository graph
|
+---- Architecture
+---- Risk exposure
+---- Dependencies / SBOM
+---- AI context
+---- Refactoring
+---- Git-history analysis
El resultado principal de GitGalaxy es una representación estructural determinista del repositorio.
Consumidor Pregunta
Arquitectura ¿De qué está hecho este repositorio?
Análisis estructural ¿Dónde están las funciones, clases, APIs, dependencias y estructuras de control?
Exposición al riesgo ¿Dónde se concentran los patrones de riesgo potencialmente importantes?
Refactorización ¿Qué archivos son complejos, con alta rotación o críticos para la carga?
Cadena de suministro ¿Qué dependencias existen físicamente en el disco?
Contexto de IA ¿Qué arquitectura y relaciones debería conocer un agente?
Migración de legado ¿Dónde están las unidades estructurales a transformar?

GitGalaxy deliberadamente no comienza construyendo un AST completo para cada lenguaje.
Utiliza aproximadamente 97 categorías de señales estructurales para identificar cosas como:
Esto crea una hipótesis específica y comprobable:
Para la inteligencia a escala de repositorio, la extracción estructural dirigida puede recuperar las entidades necesarias para una inteligencia de código útil sin requerir un analizador de lenguaje completo para cada archivo.
Esa hipótesis se está probando empíricamente.
Este es actualmente uno de los programas de validación más importantes del proyecto.
GitGalaxy se está evaluando contra Tree-sitter y Universal Ctags en el mismo corpus de Language Crucible.
Los primeros objetivos estructurales son:
El punto de referencia deliberadamente no se trata como un concurso de popularidad entre tres herramientas.
Cuando las herramientas discrepan:
24 de 45 lenguajes tienen las tres herramientas comparadas, 16 más tienen dos, y
5 lenguajes solo de GitGalaxy (abap, dockerfile, jcl, livecode,
yaml) reciben verificación manual revisada a mano en lugar de acuerdo
entre herramientas. De las 180 formas de discrepancia registradas hasta ahora, 87 están
validadas (48 %) — leídas, investigadas y registradas con un veredicto,
no solo contadas.
El objetivo es terminar la auditoría, cerrar los defectos restantes de GitGalaxy, establecer una verdad fundamental independiente cuando sea necesario y luego publicar mediciones finales de precisión/recuperación. Consulta el documento de metodología de triple comparación para saber cómo funcionan el emparejamiento, el ciclo de vida del registro y la aplicación en CI.
Consulta:
tests/tools/tri_comparison_chart.pydocs/self_scan/tri_comparison_ledger.json
— el registro completo validado por formadocs/self_scan/tri_comparison_points_of_interest.md
— el mismo registro, renderizado y clasificado por intensidad de señaldocs/self_scan/how_to_investigate_a_discrepancy.mddocs/self_scan/manual_verification.jsonNo:
"¿Es GitGalaxy un mejor analizador que Tree-sitter?"
Sino:
"Para las entidades estructurales que GitGalaxy necesita para construir su grafo de repositorio, ¿con qué precisión puede la extracción estructural dirigida recuperarlas en comparación con los sistemas establecidos de análisis e indexación?"
Esa es la afirmación más acotada que el experimento puede respaldar.
Algunos lenguajes actualmente no tienen una ruta de comparación independiente adecuada con Tree-sitter/Ctags.
Estos se mantienen en una categoría probatoria separada y utilizan verificación manual confirmada en lugar de pretender que existe un acuerdo entre herramientas.
Esto actualmente incluye lenguajes como:
Cuando sea práctico, el siguiente paso es añadir comparadores léxicos, basados en gramática o específicos de dominio independientes. Cuando no existe un comparador independiente creíble, la verdad fundamental verificada por humanos sigue siendo la categoría adecuada.
La evidencia de GitGalaxy se está organizando en torno a preguntas progresivamente más sólidas.
¿Identifica GitGalaxy correctamente las estructuras de código?
Tree-sitter + Ctags + discrepancias investigadas de forma independiente. Consulta "Validación estructural" arriba.
¿La implementación permanece estable en código real?
¿Funciona en repositorios reales?
Salida de escaneo sin editar de cientos de repositorios.
¿Corresponden las firmas estructurales a las categorías de exposición que se pretende que representen?
Análisis estadístico contra resultados observables de forma independiente---no meramente contra las propias ecuaciones de GitGalaxy.
¿Se comporta la exposición de manera sensata a medida que cambia el software?
Análisis del historial de Git que compara estados del repositorio antes y después de cambios reales.
¿Corresponden los cambios de exposición a resultados de seguridad o mantenimiento documentados de forma independiente?
Trabajo futuro: correcciones de seguridad, regresiones, avisos, defectos y otros conjuntos de datos de eventos externos.
Esta distinción importa: una puntuación puede ser internamente consistente sin ser necesariamente significativa externamente.
GitGalaxy produce mediciones de exposición al riesgo, no veredictos de vulnerabilidad.
Una exposición alta significa:
Esta ubicación merece atención en relación con el resto del repositorio.
No significa:
"Este código es definitivamente vulnerable."
El sistema actual produce categorías de exposición normalizadas en todo el repositorio y agrega información de las entidades estructurales a través de archivos, carpetas y vistas a nivel de repositorio.
Las firmas subyacentes cubren patrones que involucran áreas como:
La pregunta de investigación importante es si estas firmas están asociadas empíricamente con clases significativas de riesgo de software, en lugar de meramente correlacionadas con una puntuación que el propio GitGalaxy construyó matemáticamente.
Esa distinción impulsa la siguiente fase.
Una vez que la validación estructural esté suficientemente madura, GitGalaxy puede probar su modelo de exposición longitudinalmente.``` text Git history | v security-relevant event | +-------------------+ | | v v parent state changed state | | v v GitGalaxy scan GitGalaxy scan | | +---------+---------+ | v exposure delta | v independent event class
El experimento central es:
> **¿Los commits identificados de forma independiente como correcciones de seguridad suelen
> reducir la exposición correspondiente de GitGalaxy?**
Los controles negativos son igualmente importantes:
> ¿Los commits de desarrollo ordinarios muestran el mismo comportamiento?
Finalmente:
> ¿Las regresiones de seguridad aumentan la exposición?
El arnés planificado preservará el SHA del commit, el estado del padre, los archivos/funciones
cambiados, la exposición antes/después, los deltas de exposición, los cambios
estructurales y la clasificación de eventos.
Eso prueba:
**estructura → exposición → evolución real del software**
en lugar de probar meramente las matemáticas internas del modelo
de exposición.
------------------------------------------------------------------------
# Evidencia, no solo afirmaciones
### Crisol de lenguajes
Un corpus fijado de código fuente del mundo real que incluye proyectos como Godot,
Roslyn, curl, Kubernetes y el software de vuelo del Apolo 11.
[Language Crucible](https://github.com/squid-protocol/language-crucible)
### Regresión golden-master
El código fuente real se vuelve a escanear y se compara con la salida esperada
verificada, de modo que los cambios en el parser tengan un diff observable. Se regenera con
[`tests/tools/update_golden_master.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/update_golden_master.py),
nunca se edita a mano.
### Tri-comparación
El mismo corpus se analiza contra GitGalaxy, Tree-sitter y Ctags
donde existe cobertura — 24 de 45 lenguajes obtienen las tres herramientas, 87 de
180 discrepancias registradas validadas hasta ahora. Consulta
[la metodología](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) y la
["sección de validación estructural" anterior](#structural-validation-gitgalaxy-vs-tree-sitter-vs-ctags)
para el panorama completo.
### Salida cruda del repositorio
La salida sin editar de GitGalaxy se conserva para cientos de repositorios
seleccionados de forma independiente.
[Raw Output](https://github.com/squid-protocol/gitgalaxy-raw-output)
### Suite de regresión
**7,043 pruebas** en la suite predeterminada (`python -m pytest tests/`), de
las cuales **6,165** son pruebas por firma en los 45 lenguajes
con firma estructural — coincidencias positivas, exclusiones explícitas y entradas adversariales/ReDoS.
Consulta [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) para el desglose, y
[`docs/why_gitgalaxy_beats_ast_here.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/why_gitgalaxy_beats_ast_here.md)
para casos específicos y evidenciados donde esta extracción supera una lectura AST.
### Validación histórica
La siguiente capa de investigación probará si las mediciones de exposición
corresponden a eventos reales de seguridad y mantenimiento a lo largo del historial de Git.
------------------------------------------------------------------------
# Qué es GitGalaxy — y qué no es
### GitGalaxy es
- inteligencia estructural a escala de repositorio
- análisis de código fuente independiente del lenguaje
- una representación estructural común entre código heterogéneo
- priorización de exposición al riesgo
- mapeo de arquitectura
- generación de evidencia nativa para CI
- útil en repositorios rotos/sin compilar
- diseñado para operación local/sin conexión
### GitGalaxy no es
- un reemplazo para el análisis profundo de flujo de datos de CodeQL
- un reemplazo para el ecosistema de reglas de Semgrep
- un reemplazo para las bases de datos de CVE de dependencias
- una prueba de explotabilidad
- un analizador en tiempo de ejecución
- un parser de lenguaje completo
- una garantía de que una exposición alta sea una vulnerabilidad
-----------------------------------------------------------------------
Herramienta Pregunta principal
----------------------------------- -----------------------------------
**GitGalaxy** ¿Cómo se ve este repositorio completo
estructuralmente, y hacia dónde
debería ir la atención primero?
Tree-sitter ¿Qué estructura sintáctica contiene
este código fuente?
Ctags ¿Dónde están las entidades de código
navegables?
Semgrep ¿Coincide este código con un patrón
especificado?
CodeQL ¿Qué relaciones de datos/control puede
establecer un análisis más profundo?
Herramientas SCA/CVE ¿Está esta dependencia/versión
asociada con un aviso conocido?
-----------------------------------------------------------------------
------------------------------------------------------------------------
# Escala del mundo real
GitGalaxy está pensado para repositorios demasiado heterogéneos o rotos para un
flujo de trabajo tradicional de compilar-primero con un solo lenguaje.
Ejemplo: **Kubernetes**
\~1.39M de líneas en Go, YAML, JSON, Shell y Proto.
Escaneo de extremo a extremo: **50.83 segundos**.

Consulta el [repositorio de salida
cruda](https://github.com/squid-protocol/gitgalaxy-raw-output) para
artefactos sin editar.
------------------------------------------------------------------------
# Salidas
Salida Propósito
---------------------------- ----------------------------------------
**SARIF** Integración con paneles de CI/seguridad
**SBOM CycloneDX** Inventario de dependencias/cumplimiento
**SQLite** Grafo de conocimiento del repositorio consultable
**Resumen de arquitectura LLM** Contexto compacto orientado a máquinas/agentes
**Datos de auditoría JSON** Flujos de trabajo forenses/automatizados
**Datos de visualización 3D** Topología interactiva del repositorio
Estas son vistas diferentes del mismo escaneo determinista, en lugar de
motores de análisis independientes.
------------------------------------------------------------------------
# Historial de Git y arquitectura
GitGalaxy ya incorpora el historial de Git en señales como:
- churn
- concentración de contribuidores
- exposición al factor bus
- puntos calientes de refactorización
- propiedad de archivos
- actividad temporal
La dirección de investigación es extender esto de **historial como señal
contextual** a **historial como fuente de validación externa para el modelo
de exposición**.
------------------------------------------------------------------------
# Privacidad y despliegue
GitGalaxy está diseñado para operación local y en entornos aislados.
- El código fuente no se envía a un servicio en la nube de GitGalaxy.
- El escaneo y la vectorización ocurren localmente.
- El escáner no tiene requisito de red en tiempo de ejecución.
- La ejecución en CI/CD puede permanecer dentro del entorno del usuario.
- El visualizador del navegador opera con datos suministrados localmente.
------------------------------------------------------------------------
# Instalación``` bash
pip install gitgalaxy
Consulta la documentación para conocer los comandos y la configuración actuales.
Se proporcionan plantillas para:
Consulta templates/ y la guía de integración con
CI.
Recurso Qué contiene
Documentación Arquitectura, afirmaciones y metodología
Language Crucible Benchmark y corpus de referencia multiplataforma
Salida sin procesar Escaneos sin editar de repositorios reales
tests/README.md Metodología de regresión y
golden-master
tri_comparison_ledger.json Registro de validación
desacuerdo por desacuerdo
manual_verification.json Casos revisados donde la cobertura
del comparador no está disponible
how_to_investigate_a_discrepancy.md Metodología de desacuerdo con el
comparador
GitGalaxy avanza a través de una secuencia de preguntas cada vez más difíciles:
¿Podemos escanear código fuente heterogéneo sin compilarlo?
↓
¿Podemos recuperar de forma fiable las entidades estructurales necesarias para comprenderlo?
↓
¿Se corresponden esas mediciones estructurales con una exposición al riesgo significativa?
↓
¿Se comporta correctamente la exposición medida a medida que el software real evoluciona?
La validación de Tree-sitter/Ctags está actualmente a mitad de camino. La prioridad inmediata es finalizar esa auditoría antes de convertir las mediciones preliminares en afirmaciones más sólidas.
El siguiente experimento principal es:
Historial de Git → eventos de cambio/corrección identificados de forma independiente → escaneos de GitGalaxy antes/después → deltas de exposición → análisis estadístico.
Ahí es donde GitGalaxy puede comenzar a probar no solo si ve la estructura, sino si su modelo estructural rastrea cambios significativos en software real.
Copyright (c) 2026 Joe Esquibel
GitGalaxy se distribuye bajo la Licencia No Comercial PolyForm 1.0.0.
Consulta la licencia del repositorio para conocer los términos completos.