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.
1 scansione · 97 segnali strutturali · 50+ linguaggi · 0 necessità di compilazione
19 punteggi di esposizione al rischio · 6 report finali · 0 dipendenze · pip install gitgalaxy
GitGalaxy esiste per un problema ricorrente: comprendere un codebase reale, ampio e multilingua che non compila in modo pulito — lo stato in cui si trovano effettivamente la maggior parte dei repository in produzione, non l'input pulito e monolingua che la maggior parte degli strumenti di analisi statica presuppone.
time(s) ≈ 3.36e-05 × LOC^0.969 sopra (R²=0,88, quasi lineare, che non degrada su input di grandi dimensioni) — vedi Proof, Not Just Claims per il grafico e la derivazione, non solo questo titolo arrotondato.Questo non è uno scanner di vulnerabilità in competizione con CodeQL, Semgrep o SonarQube. Questi strumenti eseguono un'analisi profonda e precisa una volta che il codice compila, di solito un linguaggio alla volta. GitGalaxy risponde prima a una domanda diversa — che aspetto ha realmente questo intero sistema e dove è concentrato il rischio — attraverso ogni linguaggio del repository simultaneamente, prima ancora che questi strumenti più profondi abbiano una build su cui lavorare. Vedi "How This Compares, Architecturally" più sotto per sapere esattamente dove inizia e finisce il lavoro di ciascuno strumento.
Gitgalaxy può valutare repository completi, composti da miscele di oltre 50 linguaggi diversi, mappare l'architettura e far emergere le esposizioni al rischio insieme agli obiettivi di refactoring prioritari — hotspot, rischio bus-factor e file portanti — così sai su cosa concentrarti per primo. Il grafico sottostante è un flusso di lavoro derivato da una scansione gitgalaxy del nostro repository di test golden, che contiene file di codice campione dal software di volo Apollo-11 del 1969 fino agli stack tecnologici moderni. Benchmark
L'output principale di Gitgalaxy è una cosa sola: un grafo strutturale deterministico dell'intero repository. L'audit di sicurezza, la priorizzazione del refactoring e la traduzione da linguaggi legacy a moderni (vedi Enterprise Codebase Tools & Use Cases più sotto) sono tutti consumatori di quello stesso grafo, non prodotti separati con motori separati — ecco perché questo si avvicina più a una piattaforma di intelligence architetturale che a uno scanner di vulnerabilità monouso.
La maggior parte dei motori di code intelligence usa un AST, come tree-sitter, che offre una visione eccessivamente granulare di un repository (come chiedere di capire una casa e ricevere un elenco di ogni mattone e vetrata) e limita i linguaggi e i file che possono essere scansionati. I repository moderni sono poliglotti. Molti repository hanno codice vecchio senza un buon AST. Per aggirare questo problema, Gitgalaxy usa un motore personalizzato di analisi strutturale regex/lessicale con un livello statistico sovrapposto — costruisce un vettore di caratteristiche per file (da ~97 categorie di "segnali" regex - che marcano i confini di funzioni, flusso di controllo, I/O, mutazione di stato e decine di altri comportamenti strutturali e rilevanti per la sicurezza) e per repository (grafo delle dipendenze tramite risoluzione delle importazioni + PageRank/centralità), poi trasforma quei conteggi grezzi in punteggi di rischio normalizzati da 0 a 100 tramite funzioni sigmoidali, ed esporta il risultato in sei formati.
Gitgalaxy scambia la precisione a livello di AST con velocità di ordini di grandezza superiori e una copertura linguistica universale, nello stesso spirito con cui BLAST ha scambiato l'allineamento esaustivo di Smith-Waterman con la velocità euristica in genomica. L'output include SARIF, SBOM CycloneDX, un knowledge graph SQLite interrogabile, un brief architetturale ottimizzato per LLM e dati di visualizzazione 3D da una singola passata di scansione — vedi "Quale Problema Risolve Questo?" più sopra per cifre reali sui tempi di scansione anziché un semplice aggettivo.
Il risultato è un knowledge graph deterministico del repository, costruito senza mai richiedere che il codice compili. Calcola il rapporto tra codice di test e logica principale, mappa il "raggio d'esplosione" a valle di ogni file attraverso il grafo delle dipendenze e fa emergere segnali di struttura del progetto che i linter riga per riga perdono del tutto. L'estrazione dei segnali per file viene eseguita in tempo lineare rispetto alla dimensione del codebase; le metriche grafiche a livello di repository (centralità, rilevamento di comunità) usano algoritmi standard di analisi delle reti con limiti di campionamento espliciti su grafi molto grandi.
Intersecando quel grafo strutturale con la cronologia git emergono anche due segnali di refactoring specifici e prioritari: rischio bus-factor (file portanti posseduti quasi interamente da un singolo contributore) e hotspot di refactoring (file che sono simultaneamente ad alta modifica, alta complessità e alto debito — il segnale standard per capire dove lo sforzo di refactoring ripaga davvero). Entrambi sono target nominati a livello di file, non solo un punteggio.
GitGalaxy produce due diversi tipi di output, e vanno letti in modo diverso.
I punteggi di esposizione al rischio sono un segnale da 0 a 100, normalizzato per densità, in 19 categorie (segreti, superficie di iniezione, corruzione della memoria e altro), aggregato dalla funzione al file alla cartella al repository. Un punteggio alto significa questo merita attenzione per primo — è un segnale di priorizzazione, non un verdetto. Due file possono avere lo stesso punteggio per ragioni completamente diverse: un problema reale, oppure un pattern legittimo che in superficie sembra identico. Un malware cifrato e una routine crittografica ben testata producono entrambi alta entropia. GitGalaxy non può dirti quale dei due ha trovato — solo che lì c'è qualcosa che merita un secondo sguardo.
I finding sono segnalazioni individuali a livello di riga: una specifica firma strutturale che ha superato una soglia di rischio. Questi sono prove da esaminare, non vulnerabilità confermate. GitGalaxy non esegue mai codice, non traccia il dataflow a runtime e non verifica l'exploitability — ti dice che un pattern esiste nel testo, in quella riga esatta, e ti passa il contesto per giudicarlo tu stesso.
Questo è intenzionale, non un limite che nascondiamo. GitGalaxy è costruito per propendere verso il recall piuttosto che la precisione: segnala di più e lascia che un umano o uno strumento più profondo restringa l'elenco, piuttosto che rischiare di tacere su qualcosa di reale. I falsi positivi sono il costo previsto di questo compromesso, come lo sono per ogni analizzatore statico che non esegue il codice che legge.
Questo significa anche che GitGalaxy è più efficace contro una classe specifica di problemi — negligenza, non elusione avversaria. Una chiave hardcoded che qualcuno ha dimenticato di rimuovere, un registry insicuro, una chiamata eval() chiaramente pericolosa — nessuno dall'altra parte sta cercando di nascondersi da uno scanner. Un attaccante specificamente motivato che sa come funziona il rilevamento statico basato su firme può eludere singoli segnali come le soglie di entropia senza troppo sforzo. Tratta GitGalaxy come il primo passaggio rapido su un codebase troppo grande per essere letto a mano — non l'ultima parola sul fatto che qualcosa sia sicuro.
La maggior parte degli scanner di dipendenze funziona tramite una tabella di consultazione: sanno che una vulnerabilità esiste perché qualcuno l'ha trovata, l'ha segnalata e ora ha un numero CVE in un feed. È utile, ma è necessariamente reattivo — uno scanner costruito in questo modo è cieco a tutto ciò che non è ancora stato scoperto e divulgato, incluse varianti semplici di pattern notoriamente dannosi che sembrano solo leggermente diversi dall'istanza segnalata.
GitGalaxy adotta un approccio diverso: invece di confrontare istanze note, confronta classi di debolezza. I suoi finding sono etichettati per CWE (Common Weakness Enumeration) — credenziali hardcoded, esecuzione dinamica del codice, deserializzazione non sicura — non per ID CVE. Una firma strutturale per "esecuzione dinamica di input contaminato" intercetta quel pattern ovunque appaia, con qualsiasi nome di variabile, in qualsiasi disposizione specifica — non solo l'istanza di cui qualcuno ha già presentato un report.
La stessa filosofia si estende al livello SBOM. Invece di chiedersi "questa versione del pacchetto appare in un database di vulnerabilità", GitGalaxy si chiede "il contenuto effettivo su disco di questo pacchetto corrisponde strutturalmente a ciò che dovrebbe apparire in una versione legittima" — entropia, impronta strutturale, flag di anomalie comportamentali. È così che una dipendenza manomessa viene individuata fin dal primo giorno, prima che qualcuno abbia scoperto o divulgato qualcosa, perché non c'è alcun CVE da attendere.
Questo è un complemento agli strumenti basati su feed CVE (Snyk, Dependabot, OSV-Scanner), non un loro sostituto — quelli sono la risposta giusta per "questo specifico bug noto è presente?". GitGalaxy è la risposta giusta per la rete più ampia: classi di debolezza e anomalie fisiche che non richiedono che qualcuno abbia prima trovato e segnalato l'istanza specifica.
Questa è una comparazione auto-dichiarata di ciò che ogni strumento richiede e rileva strutturalmente, non un benchmark indipendente — verifica rispetto alla documentazione di ciascun progetto. Esiste per rispondere chiaramente a una domanda: quale lacuna GitGalaxy è effettivamente costruito per coprire, rispetto a strumenti che svolgono un lavoro correlato ma diverso.
| GitGalaxy | Semgrep | CodeQL | Snyk / Dependabot | |
|---|---|---|---|---|
| Richiede un AST o una build | No — firme strutturali regex/lessicali | Sì — pattern matching AST per linguaggio | Sì — compila/estrae un database di codice | No — legge i manifest dei pacchetti |
| Base di rilevamento | Classe di debolezza (CWE) + anomalia fisica/strutturale | Regole di pattern matching (SAST) | Query dataflow/taint (SAST) | Consultazione database CVE/advisory (SCA) |
| Funziona su codice rotto/non compilato | Sì — questo è l'obiettivo di progettazione | Parziale, dipende dalla regola/parser | No — richiede una build funzionante | Sì — legge solo il manifest |
| Offline / air-gapped | Sì, completamente locale | Il motore OSS viene eseguito localmente; Cloud Platform è hosting | Viene eseguito localmente; usato comunemente tramite GitHub-hosted Actions | Dipendente dal cloud (Snyk); GitHub-hosted (Dependabot) |
Dove i pari di GitGalaxy nella categoria SAST richiedono un AST o una build compilabile, e dove gli strumenti basati su feed CVE richiedono un manifest dei pacchetti, è esattamente la lacuna che GitGalaxy è costruito per coprire — non un'affermazione che sostituisce ciò che quelli fanno bene.
Ogni affermazione su "firma strutturale" e "senza AST" sopra è supportata da tre cose che puoi ispezionare e rieseguire tu stesso, non solo prendere per fede:
gitgalaxy/standards/language_standards.py definisce ogni regola regex che il motore usa per riconoscere un costrutto — l'inizio di una funzione, un confine API, un bypass di sicurezza — nei 45 linguaggi che hanno vere firme strutturali (~1.970 pattern compilati in totale). Ognuna di queste regole è testata per ciò che dovrebbe corrispondere, ciò che dovrebbe esplicitamente escludere (il controllo dei falsi positivi che la maggior parte degli strumenti basati su regex salta) e per il fatto che non può essere bloccata da un input avversario. Vedi tests/README.md per l'indice completo e epic #518 per l'audit che l'ha chiuso — dozzine di bug regex reali trovati e corretti lungo il percorso, non solo copertura teorica.language-crucible è uno snapshot pinnato e taggato di ~120 sottodirectory reali estratte da importanti progetti open-source — il C++ di Godot, il compilatore C# Roslyn, curl, Kubernetes, il software di volo AGC dell'Apollo 11 e altro — deliberatamente lasciate scollegate e non compilabili, lo stesso stato ostile in cui si trovano i repository reali. Ogni pull request che tocca il motore di parsing riscansiona l'intero corpus e confronta l'output, campo per campo, con uno snapshot archiviato (tests/golden_master_audit.json); una differenza significa che l'output è cambiato su codice reale e deve essere spiegata prima di essere accettata — non uno smoke test, ma una vera comparazione golden-master. Vedi tests/README.md per capire esattamente come questo è integrato nella CI e il README di language-crucible per capire perché quel corpus è costruito in quel modo._galaxy_audit.json, _galaxy_master.db e _galaxy_llm.md prodotto dallo scanner, mantenuto versionato per ogni release del motore. Il manifest del corpus che fissa esattamente quali repository e commit sono stati scansionati copre attualmente un sottoinsieme di 323 repository del batch più ampio archiviato lì — dichiarato chiaramente nel README di quel repository piuttosto che lasciarlo intendere come completo.Lo stesso batch di output grezzo è ciò da cui è stata ricavata l'affermazione sulla velocità sopra — ogni repository è stato tracciato, non solo il favorevole esempio di Kubernetes:
Sempre la versione più recente dello scanner — derivazione completa e metodologia nella sezione Speed Telemetry di gitgalaxy-raw-output.
GitGalaxy è pensato per essere eseguito nella CI, non solo per ricevere stelle ed essere dimenticato — quindi monitoriamo l'integrazione CI/produzione come segnale di adozione a sé stante accanto alla scoperta umana, invece di filtrarlo come rumore.
A sinistra: stelle e fork GitHub (cumulativi — ricostruiti dal timestamp di ogni stella/fork, non solo uno snapshot in avanti) insieme a clonatori unici giornalieri e visualizzazioni del profilo. A destra: utilizzo del Catalogo CI/CD GitLab (progetti unici che eseguono GitGalaxy in una pipeline negli ultimi 30 giorni) e adozione di GitHub Action (repository unici che fanno riferimento all'azione in un workflow, tramite ricerca nel codice — GitGalaxy non è ancora elencato nel Marketplace, quindi questo è il miglior segnale passivo disponibile). A differenza del pannello sinistro, GitHub e GitLab non espongono alcuna cronologia per questi due — aspettatevi che il pannello destro si riempia giorno dopo giorno piuttosto che mostrare una tendenza retroattiva.
Volume di distribuzione combinato su PyPI, GitHub e GitLab rispetto ai nostri repository di controllo baseline — non un conteggio deduplicato in modo uniforme. Il conteggio dei clonatori unici di GitHub e il conteggio dei progetti unici di GitLab sono davvero deduplicati; i dati pubblici di download di PyPI non hanno identità su cui basare la deduplicazione (misurati senza mirror, il che esclude i bot noti di sincronizzazione mirror ma non le installazioni guidate da CI), quindi quella componente è un conteggio grezzo di eventi di download. Le linee di ripartizione GitHub/PyPI iniziano a metà dell'intervallo perché il tracciamento per fonte è stato aggiunto dopo il tracciamento del totale; la linea totale prima di quel punto è un aggregato di tutte le fonti.
Metodologia completa, inclusa esattamente cosa è e cosa non è deduplicato per fonte: squid-protocol/squid-telemetry.
GitGalaxy esegue il 100% della sua scansione e vettorizzazione localmente — il motore funziona allo stesso modo completamente air-gapped o connesso.
Inserisci il template della tua piattaforma direttamente nella tua pipeline — ognuno esegue una scansione GitGalaxy e può far fallire la build in caso di superamento delle soglie di rischio o di corrispondenza con firme malware.
| Piattaforma | Template |
|---|---|
| GitHub Actions | gitgalaxy-pipeline.yml — consulta la guida all'integrazione completa |
| GitLab CI | scan.yml |
| Bitbucket Pipelines | bitbucket-pipelines.yml + bitbucket_insights.py (pubblica i risultati come annotazioni Bitbucket Code Insights) |
| Azure Pipelines | azure-pipelines.yml |
| Qualsiasi altra piattaforma (Jenkins, CircleCI, ecc.) | scan.yml — template generico, invocabile da shell |
Il grafo strutturale del motore principale alimenta un set di strumenti autonomi costruiti sopra di esso, ciascuno dei quali è un modulo separato sotto gitgalaxy/tools/ che consuma lo stesso output di scansione deterministico invece di ri-analizzare il repository stesso.
Una pipeline di traduzione deterministica e ad alta fedeltà. Converte il COBOL legacy in architetture Spring Boot moderne e pienamente compilabili, mappando la memoria in modo esatto e generando lo scaffolding di entità JPA, controller REST e build Maven, prima di utilizzare l'AI per tradurre la logica di business isolata.
Una suite analitica per ripulire i monoliti mainframe. Neutralizza in modo sicuro le trappole lessicali legacy, estrae la memoria di esecuzione morta, mappa gli ordini di esecuzione topologici dei DAG e genera configurazioni JCL Zero-Trust per deployment cloud moderni.
Firewall pre-commit che esaminano i contenuti fisici dei file invece di fidarsi dei file manifest — progettati per bloccare steganografia, loop di decrittazione XOR a livello di byte, typosquatting con omoglifi e vault crittografici esposti prima che entrino nella tua pipeline CI/CD. Distribuiscili direttamente tramite la nostra GitHub Action.
Un generatore di Software Bill of Materials (SBOM) che non si fida ciecamente di package.json o requirements.txt — individua le dipendenze fisiche sul disco, ne verifica l'entropia e l'identità linguistica rispetto a come dovrebbe apparire una versione legittima e genera report JSON CycloneDX 1.4 rigorosi.
Uno strumento di mappatura deterministico per la superficie API non documentata e obsoleta. Utilizza regex strutturali per individuare la logica di routing fisica attiva (Express, Spring Boot, FastAPI) e applica la teoria degli insiemi alla documentazione ufficiale OpenAPI/Swagger per isolare le API Shadow (route non documentate) e le API Ghost (route documentate ma non più implementate).
Analisi dei log che opera a 0,07 GB/sec senza richiedere alcun indice. Elabora in streaming enormi dump di database per individuare e mascherare i PII (carte di credito, SSN, chiavi AWS) e utilizza mappe architetturali statiche per riportare le frequenze di esecuzione runtime sotto forma di istogrammi ASCII di serie temporali.
Il Sensore AppSec segnala gli agenti AI collegati a capacità di mutazione diretta dello stato: un framework di orchestrazione LLM (LangChain, LlamaIndex) importato insieme a I/O diretto di rete/disco, combinato con una densità di programmazione difensiva al di sotto della soglia. Si tratta di un segnale di identità della libreria, non di un'affermazione sul comportamento runtime — un motore basato solo su regex, senza tracciamento del flusso di dati, non può dimostrare che il codice esegua effettivamente quel percorso, quindi non lo afferma (vedi #1102 per i controlli rimossi perché facevano questa affermazione non dimostrabile). Separatamente, il Firewall Dev Agent valuta la massa dei token e il blast radius per impedire agli agenti di codifica autonomi di modificare file pericolosi o che drenano i token di contesto.
Se preferisci l'analisi visiva, abbiamo creato una dashboard topologica in cui ogni file rappresenta un nodo, dimensionato e colorato in base a specifiche metriche di rischio.
Basta trascinare il file your_repo_GPU_galaxy.json generato (o un .zip del repository grezzo) direttamente in GitGalaxy.io. Tutto il rendering e la scansione avvengono interamente nella memoria locale del tuo browser.
Mappatura di 3,2 milioni di righe di C++ in 11 secondi | OpenCV 
Copyright (c) 2026 Joe Esquibel
GitGalaxy è distribuito sotto la PolyForm Noncommercial License 1.0.0.
Siamo profondamente impegnati verso le comunità open-source e accademiche. Se utilizzi GitGalaxy per progetti personali, ricerca accademica o sviluppo non commerciale, il motore è gratuito al 100%.
Per eliminare i ritardi legati alla licenza commerciale nel tuo terminale o nelle pipeline CI/CD personali, imposta semplicemente la seguente variabile d'ambiente:```bash export GITGALAXY_LICENSE_KEY="COMMUNITY_FREE_TIER"
### Uso Commerciale e Aziendale
L'esecuzione di GitGalaxy in ambienti aziendali, codebase proprietarie o pipeline CI/CD commerciali richiede una licenza enterprise. Le pipeline aziendali senza licenza subiranno un'intenzionale attrito di esecuzione e il tentativo di utilizzare la chiave Community Free Tier in un ambiente aziendale attiverà espliciti avvisi di non conformità nei tuoi log di audit.
Per ottenere una chiave commerciale per la tua organizzazione e garantire log di conformità puliti, contatta: **[email protected]**