squid-protocol1/gitgalaxyMotore di knowledge graph euristico senza AST per un'intelligenza approfondita dei repository e scansione di sicurezza zero-trust. Si integra come componente GitLab CI/CD, blocca il codice ostile ed esporta la telemetria SARIF nel GitLab Security Dashboard.
Intelligenza strutturale a scala di repository senza compilazione.
Docs · Visualizer · Language Crucible · Raw Output
1 scansione · 97 segnali strutturali · 50+ linguaggi · nessuna compilazione · 19 categorie di esposizione al rischio · 6 output
GitGalaxy costruisce un grafo strutturale agnostico rispetto al linguaggio dell'intero repository direttamente dal testo sorgente.
È progettato per repository poliglotti, parzialmente rotti, legacy, ricchi di vendor, o comunque difficili da analizzare tramite un flusso di lavoro build-first.
Invece di richiedere una build riuscita e un parser/toolchain separato per ogni linguaggio, GitGalaxy estrae un vocabolario comune di firme strutturali---funzioni, classi, argomenti, flusso di controllo, mutazione di stato, I/O, API, dipendenze e altri segnali---e normalizza queste osservazioni in un unico modello di repository.
Lo stesso grafo può quindi alimentare:
Tesi centrale: il parsing completo del linguaggio non è sempre necessario per recuperare informazioni strutturali altamente utili a scala di repository.
I repository di grandi dimensioni contengono regolarmente:``` text Go + C++ + Python + Java + Bash + YAML
La tooling tradizionale per i linguaggi può essere eccellente nel suo ambito previsto,
lasciando comunque il repository frammentato tra rappresentazioni specifiche per linguaggio.
GitGalaxy fa una scelta diversa:``` 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
L'obiettivo non è riprodurre ogni dettaglio sintattico di ogni linguaggio.
L'obiettivo è recuperare le informazioni strutturali di cui l'intelligenza a valle del repository ha effettivamente bisogno.
L'output principale di GitGalaxy è una rappresentazione strutturale deterministica del repository.
Consumatore Domanda
Architettura Di cosa è fatto questo repository?
Analisi strutturale Dove sono funzioni, classi, API, dipendenze e strutture di controllo?
Esposizione al rischio Dove sono concentrati i pattern di rischio potenzialmente importanti?
Refactoring Quali file sono complessi, ad alto tasso di modifica o portanti?
Supply chain Quali dipendenze esistono fisicamente su disco?
Contesto AI Quale architettura e quali relazioni dovrebbe conoscere un agente?
Migrazione legacy Dove sono le unità strutturali da trasformare?
GitGalaxy deliberatamente non inizia costruendo un AST completo per ogni linguaggio.
Utilizza circa 97 categorie di segnali strutturali per identificare elementi come:
Questo crea un'ipotesi specifica e verificabile:
Per l'intelligenza a scala di repository, l'estrazione strutturale mirata può recuperare le entità necessarie per un'utile intelligenza del codice senza richiedere un parser linguistico completo per ogni file.
Questa ipotesi è in fase di verifica empirica.
Questo è attualmente uno dei programmi di validazione più importanti del progetto.
GitGalaxy viene valutato rispetto a Tree-sitter e Universal Ctags sullo stesso corpus Language Crucible.
I primi obiettivi strutturali sono:
Il benchmark deliberatamente non viene trattato come una gara di popolarità tra tre strumenti.
Quando gli strumenti non concordano:
24 dei 45 linguaggi vedono confrontati tutti e tre gli strumenti, altri
16 ne vedono due, e 5 linguaggi solo-GitGalaxy (abap, dockerfile,
jcl, livecode, yaml) ricevono una verifica manuale revisionata a mano
invece di un accordo tra strumenti. Delle 180 forme di discrepanza
registrate finora, 87 sono validate (48%) — lette, indagate e
registrate con un verdetto, non solo contate.
L'obiettivo è completare l'audit, chiudere i difetti rimanenti di GitGalaxy, stabilire una verità di base indipendente dove necessario, e poi pubblicare le misurazioni finali di precisione/richiamo. Vedi il documento metodologico del tri-confronto per come funzionano il matching, il ciclo di vita del registro e l'applicazione della CI.
Vedi:
tests/tools/tri_comparison_chart.pydocs/self_scan/tri_comparison_ledger.json
— il record completo e validato per formadocs/self_scan/tri_comparison_points_of_interest.md
— lo stesso registro, renderizzato e classificato per forza del segnaledocs/self_scan/how_to_investigate_a_discrepancy.mddocs/self_scan/manual_verification.jsonNon:
"GitGalaxy è un parser migliore di Tree-sitter?"
Ma:
"Per le entità strutturali di cui GitGalaxy ha bisogno per costruire il suo grafo del repository, con quanta precisione l'estrazione strutturale mirata può recuperarle rispetto a sistemi consolidati di parsing e indicizzazione?"
Questa è l'affermazione più ristretta che l'esperimento può supportare.
Alcuni linguaggi attualmente non dispongono di un percorso comparativo indipendente adeguato con Tree-sitter/Ctags.
Questi vengono mantenuti in una categoria probatoria separata e usano una verifica manuale impegnata piuttosto che fingere che esista un accordo tra strumenti.
Questo include attualmente linguaggi come:
Dove praticabile, il passo successivo è aggiungere comparatori lessicali, basati su grammatica o specifici di dominio indipendenti. Dove non esiste un comparatore indipendente credibile, la verità di base verificata dall'uomo rimane la categoria appropriata.
Le evidenze di GitGalaxy sono organizzate attorno a domande progressivamente più forti.
GitGalaxy identifica correttamente le strutture del codice?
Tree-sitter + Ctags + disaccordi indagati in modo indipendente. Vedi "Validazione strutturale" sopra.
L'implementazione rimane stabile su codice reale?
Test golden-master contro Language Crucible.
Funziona su repository reali?
Output di scansione grezzo e non modificato da centinaia di repository.
Le firme strutturali corrispondono alle categorie di esposizione che intendono rappresentare?
Analisi statistica rispetto a risultati osservabili in modo indipendente---non solo rispetto alle equazioni di GitGalaxy stesso.
L'esposizione si comporta in modo sensato man mano che il software cambia?
Analisi della storia Git che confronta gli stati del repository prima e dopo modifiche reali.
I cambiamenti di esposizione corrispondono a risultati di sicurezza o manutenzione documentati in modo indipendente?
Lavoro futuro: fix di sicurezza, regressioni, advisory, difetti e altri dataset di eventi esterni.
Questa distinzione è importante: un punteggio può essere internamente coerente senza essere necessariamente significativo esternamente.
GitGalaxy produce misurazioni dell'esposizione al rischio, non verdetti di vulnerabilità.
Un'esposizione elevata significa:
Questa posizione merita attenzione rispetto al resto del repository.
Non significa:
"Questo codice è sicuramente vulnerabile."
Il sistema attuale produce categorie di esposizione normalizzate in tutto il repository e aggrega le informazioni dalle entità strutturali attraverso file, cartelle e viste a livello di repository.
Le firme sottostanti coprono pattern che coinvolgono aree come:
La domanda di ricerca importante è se queste firme siano empiricamente associate a classi significative di rischio software, piuttosto che semplicemente correlate con un punteggio che GitGalaxy stesso ha costruito matematicamente.
Questa distinzione guida la fase successiva.
Una volta che la validazione strutturale è sufficientemente matura, GitGalaxy può testare il suo modello di esposizione 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
L'esperimento centrale è:
> **I commit identificati in modo indipendente come fix di sicurezza
> riducono tipicamente la corrispondente esposizione GitGalaxy?**
I controlli negativi sono altrettanto importanti:
> I commit di sviluppo ordinari mostrano lo stesso comportamento?
Infine:
> Le regressioni di sicurezza aumentano l'esposizione?
L'harness pianificato conserverà lo SHA del commit, lo stato del parent, i
file/funzioni modificati, l'esposizione prima/dopo, i delta di esposizione,
le modifiche strutturali e la classificazione degli eventi.
Questo verifica:
**struttura → esposizione → evoluzione reale del software**
piuttosto che testare semplicemente la matematica interna del modello di
esposizione.
------------------------------------------------------------------------
# Prove, non solo affermazioni
### Crogiuolo linguistico
Un corpus fissato di sorgenti reali che include progetti come Godot,
Roslyn, curl, Kubernetes e il software di volo Apollo 11.
[Language Crucible](https://github.com/squid-protocol/language-crucible)
### Regressione golden-master
Il sorgente reale viene riscansionato e confrontato con l'output atteso
archiviato, così le modifiche al parser producono un diff osservabile.
Rigenerato con
[`tests/tools/update_golden_master.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/update_golden_master.py),
mai modificato a mano.
### Tri-confronto
Lo stesso corpus viene analizzato con GitGalaxy, Tree-sitter e Ctags
dove la copertura esiste — 24 dei 45 linguaggi hanno tutti e tre gli
strumenti, 87 delle 180 discrepanze registrate finora validate. Vedi
[la metodologia](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) e la
["sezione sulla validazione strutturale" sopra](#structural-validation-gitgalaxy-vs-tree-sitter-vs-ctags)
per il quadro completo.
### Output grezzo del repository
L'output non modificato di GitGalaxy viene conservato per centinaia di
repository selezionati in modo indipendente.
[Raw Output](https://github.com/squid-protocol/gitgalaxy-raw-output)
### Suite di regressione
**7.043 test** nella suite predefinita (`python -m pytest tests/`), di
cui **6.165** sono test per firma su tutti i 45 linguaggi con firma
strutturale — corrispondenze positive, esclusioni esplicite e input
avversari/ReDoS. Vedi [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) per la
ripartizione e
[`docs/why_gitgalaxy_beats_ast_here.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/why_gitgalaxy_beats_ast_here.md)
per casi specifici e comprovati in cui questa estrazione supera una
lettura AST.
### Validazione storica
Il prossimo livello di ricerca testerà se le misurazioni di esposizione
corrispondono a eventi reali di sicurezza e manutenzione nella storia di
Git.
------------------------------------------------------------------------
# Cosa è GitGalaxy — e cosa non è
### GitGalaxy è
- intelligenza strutturale a scala di repository
- analisi del sorgente agnostica rispetto al linguaggio
- una rappresentazione strutturale comune tra codice eterogeneo
- prioritizzazione dell'esposizione al rischio
- mappatura dell'architettura
- generazione di prove nativa per CI
- utile su repository rotti/non compilati
- progettato per l'operatività locale/offline
### GitGalaxy non è
- un sostituto dell'analisi profonda del dataflow di CodeQL
- un sostituto dell'ecosistema di regole di Semgrep
- un sostituto dei database CVE delle dipendenze
- una prova di sfruttabilità
- un analizzatore runtime
- un parser linguistico completo
- una garanzia che un'alta esposizione sia una vulnerabilità
-----------------------------------------------------------------------
Strumento Domanda principale
----------------------------------- -----------------------------------
**GitGalaxy** Che aspetto ha questo intero
repository, strutturalmente, e dove
dovrebbe andare prima l'attenzione?
Tree-sitter Quale struttura sintattica contiene
questo sorgente?
Ctags Dove sono le entità di codice
navigabili?
Semgrep Questo codice corrisponde a un
pattern specificato?
CodeQL Quali relazioni dati/controllo può
stabilire un'analisi più profonda?
Strumenti SCA/CVE Questa dipendenza/versione è
associata a un advisory noto?
-----------------------------------------------------------------------
------------------------------------------------------------------------
# Scala reale
GitGalaxy è pensato per repository troppo eterogenei o rotti per un
flusso di lavoro tradizionale build-first a linguaggio singolo.
Esempio: **Kubernetes**
\~1,39M di righe tra Go, YAML, JSON, Shell e Proto.
Scansione end-to-end: **50,83 secondi**.
Vedi il [repository degli output
grezzi](https://github.com/squid-protocol/gitgalaxy-raw-output) per
gli artefatti non modificati.
------------------------------------------------------------------------
# Output
Output Scopo
---------------------------- ----------------------------------------
**SARIF** Integrazione con dashboard CI/sicurezza
**CycloneDX SBOM** Inventario/conformità delle dipendenze
**SQLite** Grafo di conoscenza del repository interrogabile
**Brief architetturale LLM** Contesto compatto orientato a macchine/agenti
**Dati di audit JSON** Flussi di lavoro forensi/automatizzati
**Dati di visualizzazione 3D** Topologia interattiva del repository
Queste sono viste diverse della stessa scansione deterministica, piuttosto
che motori di analisi indipendenti.
------------------------------------------------------------------------
# Storia di Git e architettura
GitGalaxy incorpora già la storia di Git in segnali come:
- churn
- concentrazione dei contributori
- esposizione bus-factor
- hotspot di refactoring
- proprietà dei file
- attività temporale
La direzione di ricerca è estendere questo dalla **storia come segnale
contestuale** alla **storia come fonte di validazione esterna per il
modello di esposizione**.
------------------------------------------------------------------------
# Privacy e distribuzione
GitGalaxy è progettato per l'operatività locale e air-gapped.
- Il codice sorgente non viene inviato a un servizio cloud GitGalaxy.
- La scansione e la vettorizzazione avvengono localmente.
- Lo scanner non ha requisiti di rete runtime.
- L'esecuzione CI/CD può rimanere nell'ambiente dell'utente.
- Il visualizzatore browser opera su dati forniti localmente.
------------------------------------------------------------------------
# Installazione``` bash
pip install gitgalaxy
Vedi la documentazione per i comandi e la configurazione correnti.
Sono forniti template per:
Vedi templates/ e la guida all'integrazione
CI.
Risorsa Cosa contiene
Documentazione Architettura, affermazioni e metodologia
Language Crucible Benchmark cross-linguistic e corpus aureo
Output grezzo Scansioni non modificate di repository reali
tests/README.md Metodologia di regressione e
golden-master
tri_comparison_ledger.json Registro di validazione
disaccordo-per-disaccordo
manual_verification.json Casi revisionati in cui la copertura del
comparatore non è disponibile
how_to_investigate_a_discrepancy.md Metodologia per i disaccordi tra
comparatori
GitGalaxy sta attraversando una sequenza di domande sempre più difficili:
Possiamo scansionare sorgenti eterogenee senza compilarle?
↓
Possiamo recuperare in modo affidabile le entità strutturali necessarie per comprenderle?
↓
Queste misurazioni strutturali corrispondono a un'esposizione al rischio significativa?
↓
L'esposizione misurata si comporta correttamente man mano che il software reale evolve?
La validazione Tree-sitter/Ctags è attualmente circa a metà del percorso. La priorità immediata è completare quell'audit prima di trasformare le misurazioni preliminari in affermazioni più solide.
Il prossimo esperimento principale è:
Storia Git → eventi di modifica/correzione identificati in modo indipendente → scansioni GitGalaxy prima/dopo → delta di esposizione → analisi statistica.
È qui che GitGalaxy può iniziare a testare non solo se vede la struttura, ma se il suo modello strutturale traccia cambiamenti significativi nel software reale.
Copyright (c) 2026 Joe Esquibel
GitGalaxy è distribuito sotto la PolyForm Noncommercial License 1.0.0.
Consulta la licenza del repository per i termini completi.