Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
gitgalaxy — 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. | Kitploit
Herramientas/GitLabGitLab/squid-protocol1/gitgalaxy
Escáneres de VulnerabilidadesAnálisis Estático de Código (SAST)Análisis de CódigoAnálisis de MalwareDevSecOpsDetección de Secretos
GitLabsquid-protocol1/gitgalaxy

gitgalaxy

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.

Ver Repositorio
5hace 17 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

GitGalaxy

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

La versión corta

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:

  • análisis de arquitectura
  • priorización de exposición al riesgo
  • análisis de dependencias/SBOM
  • análisis de refactorización y propiedad
  • análisis de código heredado
  • contexto de codebase orientado a IA
  • flujos de trabajo CI/CD
  • análisis de riesgo histórico

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.


El problema

Los repositorios grandes contienen rutinariamente:``` text Go + C++ + Python + Java + Bash + YAML

  • generated code + vendored code + legacy code
  • half-migrated modules + broken dependencies
root@kitploit:~
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

Un solo grafo, muchos consumidores

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?

Análisis histórico ¿Cómo cambia la exposición medida a medida que evoluciona el repositorio?

Pipeline de arquitectura de GitGalaxy


La tesis de la extracción estructural

GitGalaxy deliberadamente no comienza construyendo un AST completo para cada lenguaje.

Utiliza aproximadamente 97 categorías de señales estructurales para identificar cosas como:

  • límites de funciones y métodos
  • clases y declaraciones
  • argumentos
  • ramas y flujo de control
  • mutación de estado
  • E/S
  • APIs y rutas
  • importaciones y dependencias
  • operaciones inseguras
  • reflexión y ejecución dinámica
  • concurrencia
  • cierres
  • globales
  • entropía y anomalías de archivos físicos

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.


Validación estructural: GitGalaxy vs Tree-sitter vs Ctags

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:

  • funciones
  • clases
  • argumentos

El punto de referencia deliberadamente no se trata como un concurso de popularidad entre tres herramientas.

Cuando las herramientas discrepan:

  1. la discrepancia se registra;
  2. se inspecciona la fuente;
  3. se investiga el comportamiento de cada herramienta;
  4. se corrige GitGalaxy cuando GitGalaxy está equivocado;
  5. se corrige el código del comparador/adaptador cuando el comparador está equivocado;
  6. las limitaciones genuinas de las herramientas se documentan;
  7. el resultado se vuelve a medir.

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.

Triple comparación

Consulta:

  • tests/tools/tri_comparison_chart.py
  • docs/self_scan/tri_comparison_ledger.json — el registro completo validado por forma
  • docs/self_scan/tri_comparison_points_of_interest.md — el mismo registro, renderizado y clasificado por intensidad de señal
  • docs/self_scan/how_to_investigate_a_discrepancy.md
  • docs/self_scan/manual_verification.json

Qué pregunta realmente el punto de referencia

No:

"¿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.

Lenguajes sin cobertura de comparador adecuada

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:

  • ABAP
  • Dockerfile
  • JCL
  • LiveCode
  • YAML

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 validación es una escalera

La evidencia de GitGalaxy se está organizando en torno a preguntas progresivamente más sólidas.

1. Validez estructural

¿Identifica GitGalaxy correctamente las estructuras de código?

Tree-sitter + Ctags + discrepancias investigadas de forma independiente. Consulta "Validación estructural" arriba.

2. Validez de regresión

¿La implementación permanece estable en código real?

Pruebas de maestro dorado contra Language Crucible.

3. Validez de escala

¿Funciona en repositorios reales?

Salida de escaneo sin editar de cientos de repositorios.

4. Validez del modelo

¿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.

5. Validez temporal

¿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.

6. Validez externa

¿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.


Exposición al riesgo: qué afirma GitGalaxy

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:

  • secretos
  • superficie de inyección
  • operaciones inseguras/de memoria
  • ejecución dinámica
  • E/S
  • concurrencia
  • mutación de estado
  • reflexión
  • APIs
  • dependencias
  • entropía
  • otras características estructurales/de seguridad

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.


La siguiente validación: riesgo a lo largo del historial de Git

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

root@kitploit:~
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**.

![Velocidad de escaneo de
GitGalaxy](https://assets.kitploit.com/production/public/readmes/7003/596585161af8eeb861f49e2968927d69059333f145c0e2b6e9bb0cb9c9d7bc36.png)

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.

CI/CD

Se proporcionan plantillas para:

  • GitHub Actions
  • GitLab CI
  • Bitbucket Pipelines
  • Azure Pipelines
  • entornos de CI genéricos invocables mediante shell

Consulta templates/ y la guía de integración con CI.


Explora la evidencia


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

Visualizador Visualización de repositorios basada en navegador local


Dirección de investigación actual

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.


Licencia

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.

Descargar herramienta