squid-protocol1/gitgalaxyAST-freie heuristische Wissensgraph-Engine für tiefgreifende Repository-Intelligenz und Zero-Trust-Sicherheitsscans. Integriert als GitLab-CI/CD-Komponente, blockiert bösartigen Code und exportiert SARIF-Telemetrie an das GitLab Security Dashboard.
Repository-weite strukturelle Intelligenz ohne Kompilierung.
Docs · Visualizer · Language Crucible · Keyword Rosetta · Raw Output
1 Scan · 97 strukturelle Signale · 50+ Sprachen · keine Kompilierung · 17 Risikoexpositionskategorien · 6 Ausgaben
GitGalaxy erstellt einen sprachunabhängigen strukturellen Graphen eines gesamten Repositorys direkt aus dem Quelltext — kein Build, keine sprachspezifische Toolchain.
Es ist für Repositorys konzipiert, die polyglott, teilweise defekt, Legacy-, vendor-lastig oder anderweitig schwierig über einen Build-First-Workflow zu analysieren sind:
Go + C++ + Python + Java + Bash + YAML
+ generated code + vendored code + legacy code
+ half-migrated modules + broken dependencies
Statt eines separaten Parsers pro Sprache extrahiert GitGalaxy ein gemeinsames Vokabular von strukturellen Signaturen — Funktionen, Klassen, Argumente, Kontrollfluss, Zustandsmutation, I/O, APIs, Abhängigkeiten — und normalisiert sie in ein deterministisches Repository-Modell, das Architekturanalyse, Risikoexpositions-Priorisierung, SBOM-Generierung, Refactoring- und Ownership- Analyse, KI-orientierten Codebase-Kontext und CI/CD-Gates speist.
Zentrale These: vollständiges Sprach-Parsing ist nicht immer notwendig, um hochgradig nützliche strukturelle Informationen im Repository-Maßstab zu gewinnen.
Wie diese These getestet wird — gegen Tree-sitter und Ctags, gegen ein eingesetztes Kontrollkorpus und als Nächstes gegen die Git-Historie — ist unten in Genauigkeit, gemessen zusammengefasst und vollständig im Validierungsprogramm dargelegt.
Ein Befehl:
pip install gitgalaxy
galaxyscope path/to/repo
Sechs koordinierte Ansichten desselben deterministischen Scans:
| Ausgabe | Zweck |
|---|---|
| LLM-Architektur-Brief | Kompakter maschinen-/agentenorientierter Kontext (unten) |
| SARIF | CI-/Security-Dashboard-Integration |
| CycloneDX SBOM | Abhängigkeitsinventar/Compliance |
| SQLite | Abfragbarer Wissensgraph des Repositorys |
| JSON-Audit-Daten | Forensik-/Automatisierungsworkflows |
| 3D-Visualisierungsdaten | Interaktive Repository-Topologie |
Der Flaggschiff-Report ist ein einzelner Markdown-Brief, der dazu dient, einem Ingenieur — oder einem KI-Agenten — ein funktionierendes mentales Modell eines Repositorys zu übergeben, das er noch nie gesehen hat. Er ist ein in sich geschlossenes Paket: Die Risikogleichungen sind im Report selbst abgedruckt, und ein eingebetteter Interpretations-Prompt ermöglicht es jedem LLM, ihn zu erzählen, ohne zu halluzinieren, was die Zahlen bedeuten. Die Abschnitte behandeln Makrozustand und Sprachzusammensetzung, Netzwerktopologie (Modularität, Artikulationspunkte, zyklische Dichte), Abhängigkeits-Engpässe, die schwersten Funktionen und Dateien, strukturelle Signaturen pro Datei mit PageRank-Blast-Radius, gezielte und kumulative Risiko-Hitlists, Supply-Chain-Audits und Refactoring-Ziele, geordnet nach Volatilität und Zentralisierung der Autorenschaft — plus eine detaillierte Liste jeder Datei, die er verweigert hat zu scannen, und warum.
Zwei Beispiele, gescannt am 2026-08-31 mit der aktuellen Engine. Beide
Repositorys sind öffentlich — klonen Sie eines davon und führen Sie
galaxyscope --llm-only <path> aus, um den vollständigen Brief zu reproduzieren:
curl — 4.250 Artefakte, 696 gescannt, 112.653 LOC über C, Perl, Python,
Shell, M4 und Makefile. Der Brief reiht src/tool_setup.h als oberste
strukturelle Säule ein (80 eingehende Verbindungen) und setzt eine Perl-Funktion —
APPEND_imap in tests/ftpserver.pl, Impact 2135, 1.672 LOC — an die Spitze
der repositoryweiten Funktions-Hitlist, im selben Ranking wie der C-Code. Dieser
sprachübergreifende Graph ist das Produkt: ein vergleichbarer Signalsatz über
jede Sprache im Repository hinweg. Der ehrliche Vorbehalt im selben Brief: Nur
16,4 % der Artefakte wurden gescannt — der Ingestion-Filter verwirft Binärdateien,
generierten Code und Testdaten aggressiv, und §5 des Briefs listet jede
Ausnahme nach Erweiterung und Grund auf.
cics-genapp (IBMs CICS-COBOL/DB2-Beispiel) — 92,1 % gescannt: 44 COBOL-
Programme, 29 JCL-Jobs. Die kumulative Hitlist der strukturellen Oberfläche
führt mit base/src/lgupdb01.cbl (Mutationsoberfläche ~100 %, Komplexitätslast
92 %), und der schwerste Paragraph im Repository ist UPDATE-POLICY-DB2-INFO —
die SELECT FOR UPDATE-Row-Locking-Logik, genau dort, wo ein Maintainer dieses
Programms zuerst nachsehen möchte. Derselbe Brief zeigt auch eine Einschränkung
deutlich: Bei einer flachen Architektur ohne echten Import-Graphen degeneriert
die Liste der „strukturellen Säulen" zu Dateien ohne Verbindungen, und der
Report empfiehlt, die Verbindungszahlen zu prüfen, bevor man ihm vertraut.
Hunderte uneditierte Briefs für unabhängig ausgewählte Repositorys sind
committet unter
gitgalaxy-raw-output;
der stets aktuelle Self-Scan-Brief dieses Repositorys selbst befindet sich unter
docs/gitgalaxy_architecture_brief.md.
| Konsument | Frage |
|---|---|
| Architektur | Woraus besteht dieses Repository? |
| Strukturanalyse | Wo sind die Funktionen, Klassen, APIs, Abhängigkeiten und Kontrollstrukturen? |
| Structural Surface Profile (früher Risikoexposition) | Wo konzentriert sich ein gegebenes strukturelles/inhaltliches Muster? |
| Refactoring | Welche Dateien sind komplex, stark verändert oder tragend? |
| Lieferkette | Welche Abhängigkeiten existieren physisch auf der Festplatte? |
| KI-Kontext | Welche Architektur und Beziehungen sollte ein Agent kennen? |
| Legacy-Migration | Wo sind die strukturellen Einheiten, die transformiert werden müssen? |
| Historische Analyse | Wie verändert sich die gemessene Exposition, während sich das Repository weiterentwickelt? |
Zwei laufende Messprogramme stützen die obigen Aussagen, und ein drittes, für die Abhängigkeits- und Aufrufgraphen, ist in Arbeit. Die vollständige Darstellung — Methodik, Urteile, Grenzen und was als Nächstes kommt — findet sich im Validierungsprogramm; dies ist die Zusammenfassung.
GitGalaxy wird gegen Tree-sitter und Universal Ctags auf dem gepinnten Language Crucible- Korpus benchmarkt — 24 von 45 Sprachen erhalten alle drei Tools, 13 weitere erhalten zwei, und jede Abweichung wird gegen echten Quellcode untersucht und mit einem Urteil festgehalten (200 von 201 protokollierten Diskrepanzformen validiert). Auf diesem Korpus beträgt GitGalaxys validierte Funktionspräzision 100 % über alle 31 mit Tree-sitter vergleichbaren Sprachen, und es ist nie das Tool, das bei einer validierten Klassen- oder Argument-Diskrepanz als falsch befunden wird. Die Grenze: drei strukturelle Ziele, ein fester Korpus — nicht „parst so genau wie ein AST" im Allgemeinen.