GitGalaxy

Strukturelle Intelligenz auf Repository-Ebene ohne Kompilierung.

Docs · Visualizer · Language Crucible · Raw Output

1 Scan · 97 strukturelle Signale · 50+ Sprachen · keine Kompilierung · 19 Risiko-Expositions-Kategorien · 6 Ausgaben

Die Kurzfassung

GitGalaxy erstellt einen sprachunabhängigen strukturellen Graphen eines gesamten Repositorys direkt aus dem Quelltext.

Es ist für Repositorys konzipiert, die polyglott, teilweise defekt, veraltet, stark von Drittanbietern abhängig oder anderweitig schwer über einen Build-First-Workflow zu analysieren sind.

Statt für jede Sprache einen erfolgreichen Build und einen separaten Parser/Toolchain zu benötigen, extrahiert GitGalaxy ein gemeinsames Vokabular an strukturellen Signaturen---Funktionen, Klassen, Argumente, Kontrollfluss, Zustandsänderungen, I/O, APIs, Abhängigkeiten und andere Signale---und normalisiert diese Beobachtungen in einem einzigen Repository-Modell.

Derselbe Graph kann anschließend Folgendes speisen:

Architekturanalyse
Priorisierung der Risiko-Exposition
Abhängigkeits-/SBOM-Analyse
Refactoring- und Ownership-Analyse
Legacy-Code-Analyse
KI-orientierter Codebase-Kontext
CI/CD-Workflows
Historische Risikoanalyse

Zentrale These: Vollständiges Sprach-Parsing ist nicht immer erforderlich, um hochgradig nützliche strukturelle Informationen auf Repository-Ebene zu gewinnen.

Das Problem

Große Repositorys enthalten regelmäßig:``` text Go + C++ + Python + Java + Bash + YAML

generated code + vendored code + legacy code
half-migrated modules + broken dependencies

Traditionelle Sprachwerkzeuge können innerhalb ihres vorgesehenen Anwendungsbereichs hervorragend sein, während das Repository dennoch über sprachspezifische Darstellungen fragmentiert bleibt.

GitGalaxy trifft einen anderen Kompromiss:``` 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

Das Ziel ist nicht, jedes syntaktische Detail jeder Sprache zu reproduzieren.

Das Ziel ist, die strukturellen Informationen wiederzugewinnen, die nachgelagerte Repository-Intelligenz tatsächlich benötigt.

Ein Graph, viele Konsumenten

GitGalaxys Kernausgabe ist eine deterministische strukturelle Darstellung des Repositorys.

Konsument Frage

Architektur Woraus besteht dieses Repository?

Strukturanalyse Wo befinden sich Funktionen, Klassen, APIs, Abhängigkeiten und Kontrollstrukturen?

Risikoexposition Wo sind potenziell wichtige Risikomuster konzentriert?

Refactoring Welche Dateien sind komplex, änderungsintensiv oder tragend?

Lieferkette Welche Abhängigkeiten existieren physisch auf der Festplatte?

KI-Kontext Welche Architektur und Beziehungen sollte ein Agent kennen?

Legacy-Migration Wo befinden sich die strukturellen Einheiten, die transformiert werden sollen?

Historische Analyse Wie verändert sich die gemessene Exposition, während sich das Repository weiterentwickelt?

GitGalaxy-Architektur-Pipeline

Die These der strukturellen Extraktion

GitGalaxy beginnt bewusst nicht mit der Konstruktion eines vollständigen AST für jede Sprache.

Es verwendet etwa 97 Kategorien struktureller Signale, um Dinge wie die folgenden zu identifizieren:

Funktions- und Methodengrenzen
Klassen und Deklarationen
Argumente
Verzweigungen und Kontrollfluss
Zustandsänderungen
I/O
APIs und Routen
Importe und Abhängigkeiten
unsichere Operationen
Reflexion und dynamische Ausführung
Nebenläufigkeit
Closures
Globale Variablen
Entropie und Anomalien physischer Dateien

Dies erzeugt eine spezifische, testbare Hypothese:

Für Repository-weite Intelligenz kann gezielte strukturelle Extraktion die für nützliche Code-Intelligenz erforderlichen Entitäten wiederherstellen, ohne dass ein vollständiger Sprachparser für jede Datei erforderlich ist.

Diese Hypothese wird empirisch getestet.

Strukturelle Validierung: GitGalaxy vs. Tree-sitter vs. Ctags

Dies ist derzeit eines der wichtigsten Validierungsprogramme im Projekt.

GitGalaxy wird gegen Tree-sitter und Universal Ctags auf demselben Language Crucible-Korpus evaluiert.

Die ersten strukturellen Ziele sind:

Funktionen
Klassen
Argumente

Der Benchmark wird bewusst nicht als Beliebtheitswettbewerb der drei Werkzeuge behandelt.

Wenn Werkzeuge abweichen:

wird die Abweichung protokolliert;
wird die Quelle untersucht;
wird das Verhalten jedes Werkzeugs untersucht;
wird GitGalaxy korrigiert, wenn GitGalaxy falsch liegt;
wird der Vergleichs-/Adaptercode korrigiert, wenn der Vergleich falsch liegt;
werden echte Werkzeuglimits dokumentiert;
wird das Ergebnis neu gemessen.

24 von 45 Sprachen erhalten einen Vergleich aller drei Werkzeuge, 16 weitere erhalten zwei, und 5 nur-GitGalaxy-Sprachen (abap, dockerfile, jcl, livecode, yaml) erhalten stattdessen manuell geprüfte Verifikation statt werkzeugübergreifender Übereinstimmung. Von den bisher protokollierten 180 Abweichungsformen sind 87 validiert (48 %) — gelesen, untersucht und mit einem Urteil protokolliert, nicht nur gezählt.

Das Ziel ist, das Audit abzuschließen, verbleibende GitGalaxy-Fehler zu beheben, wo nötig unabhängige Grundwahrheit zu etablieren und dann finale Präzisions-/Recall-Messungen zu veröffentlichen. Siehe das Dokument zur Drei-Vergleichs-Methodik für die Funktionsweise von Abgleich, Ledger-Lebenszyklus und CI-Erzwingung.

Drei-Vergleich

Siehe:

tests/tools/tri_comparison_chart.py
docs/self_scan/tri_comparison_ledger.json — der vollständige, pro Form validierte Datensatz
docs/self_scan/tri_comparison_points_of_interest.md — dasselbe Ledger, gerendert und nach Signalstärke sortiert
docs/self_scan/how_to_investigate_a_discrepancy.md
docs/self_scan/manual_verification.json

Was der Benchmark tatsächlich fragt

Nicht:

„Ist GitGalaxy ein besserer Parser als Tree-sitter?"

Sondern:

„Wie genau kann gezielte strukturelle Extraktion die strukturellen Entitäten, die GitGalaxy für seinen Repository-Graphen benötigt, im Vergleich zu etablierten Parsing- und Indexierungssystemen wiederherstellen?"

Das ist die engere Behauptung, die das Experiment stützen kann.

Sprachen ohne geeignete Vergleichsabdeckung

Einige Sprachen haben derzeit keinen geeigneten unabhängigen Tree-sitter/Ctags-Vergleichspfad.

Diese werden in einer separaten Evidenzkategorie geführt und verwenden festgeschriebene manuelle Verifikation, statt vorzutäuschen, dass eine werkzeugübergreifende Übereinstimmung existiert.

Dazu gehören derzeit Sprachen wie:

ABAP
Dockerfile
JCL
LiveCode
YAML

Wo praktikabel, ist der nächste Schritt, unabhängige lexikalische, grammatikbasierte oder domänenspezifische Vergleiche hinzuzufügen. Wo kein glaubwürdiger unabhängiger Vergleich existiert, bleibt menschlich verifizierte Grundwahrheit die angemessene Kategorie.

Validierung ist eine Leiter

GitGalaxys Evidenz wird um zunehmend stärkere Fragen herum organisiert.

1. Strukturelle Validität

Identifiziert GitGalaxy Codestrukturen korrekt?

Tree-sitter + Ctags + unabhängig untersuchte Abweichungen. Siehe „Strukturelle Validierung" oben.

2. Regressionsvalidität

Bleibt die Implementierung auf echtem Code stabil?

Golden-Master-Tests gegen Language Crucible.

3. Skalenvalidität

Funktioniert es auf echten Repositorys?

Unbearbeitete Roh-Scan-Ausgabe von Hunderten von Repositorys.

4. Modellvalidität

Entsprechen strukturelle Signaturen den Expositionskategorien, die sie darstellen sollen?

Statistische Analyse gegen unabhängig beobachtbare Ergebnisse — nicht nur gegen GitGalaxys eigene Gleichungen.

5. Zeitliche Validität

Verhält sich Exposition sinnvoll, wenn sich Software ändert?

Git-Historie-Analyse, die Repository-Zustände vor und nach echten Änderungen vergleicht.

6. Externe Validität

Entsprechen Expositionsänderungen unabhängig dokumentierten Sicherheits- oder Wartungsergebnissen?

Zukünftige Arbeit: Sicherheitsfixes, Regressionen, Advisories, Fehler und andere Datensätze externer Ereignisse.

Diese Unterscheidung ist wichtig: Ein Score kann intern konsistent sein, ohne notwendigerweise extern bedeutsam zu sein.

Risikoexposition: Was GitGalaxy behauptet

GitGalaxy erzeugt Risikoexpositionsmessungen, keine Schwachstellenurteile.

Eine hohe Exposition bedeutet:

Dieser Ort verdient Aufmerksamkeit relativ zum Rest des Repositorys.

Es bedeutet nicht:

„Dieser Code ist definitiv verwundbar."

Das aktuelle System erzeugt normalisierte Expositionskategorien über das Repository und rollt Informationen von strukturellen Entitäten über Dateien, Ordner und Repository-Ebenen-Ansichten auf.

Die zugrunde liegenden Signaturen decken Muster in Bereichen wie:

Geheimnisse
Injection-Oberfläche
unsichere/Speicheroperationen
dynamische Ausführung
I/O
Nebenläufigkeit
Zustandsänderungen
Reflexion
APIs
Abhängigkeiten
Entropie
andere strukturelle/Sicherheitsmerkmale

Die wichtige Forschungsfrage ist, ob diese Signaturen empirisch mit bedeutsamen Klassen von Softwarerisiko assoziiert sind, statt lediglich mit einem Score zu korrelieren, den GitGalaxy selbst mathematisch konstruiert hat.

Diese Unterscheidung treibt die nächste Phase an.

Die nächste Validierung: Risiko über die Git-Historie

Das zentrale Experiment lautet:

> **Reduzieren Commits, die unabhängig als Sicherheitsfixes identifiziert wurden,
> typischerweise die entsprechende GitGalaxy-Exposition?**

Negativkontrollen sind ebenso wichtig:

> Zeigen gewöhnliche Entwicklungs-Commits dasselbe Verhalten?

Schließlich:

> Erhöhen Sicherheitsregressionen die Exposition?

Die geplante Testumgebung wird Commit-SHA, Elternzustand, geänderte
Dateien/Funktionen, Exposition vorher/nachher, Expositionsdeltas, strukturelle
Änderungen und Ereignisklassifikation bewahren.

Das testet:

**Struktur → Exposition → reale Softwareentwicklung**

anstatt lediglich die interne Mathematik des Expositionsmodells zu testen.

------------------------------------------------------------------------

# Belege, nicht nur Behauptungen

### Sprach-Schmelztiegel

Ein festgelegtes Korpus realer Quellcodes, einschließlich Projekten wie Godot,
Roslyn, curl, Kubernetes und Apollo-11-Flugsoftware.

[Language Crucible](https://github.com/squid-protocol/language-crucible)

### Golden-Master-Regression

Realer Quellcode wird erneut gescannt und mit eingecheckter erwarteter Ausgabe
verglichen, sodass Parseränderungen einen beobachtbaren Diff erzeugen. Regeneriert mit
[`tests/tools/update_golden_master.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/update_golden_master.py),
niemals manuell bearbeitet.

### Drei-Wege-Vergleich

Dasselbe Korpus wird gegen GitGalaxy, Tree-sitter und Ctags analysiert,
wo Abdeckung existiert — 24 von 45 Sprachen erhalten alle drei Tools, 87 von
180 protokollierten Abweichungen wurden bisher validiert. Siehe
[die Methodik](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) und den
[Abschnitt „Strukturvalidierung" oben](#structural-validation-gitgalaxy-vs-tree-sitter-vs-ctags)
für das vollständige Bild.

### Rohausgabe des Repositorys

Unbearbeitete GitGalaxy-Ausgabe wird für Hunderte unabhängig
ausgewählter Repositorys aufbewahrt.

[Raw Output](https://github.com/squid-protocol/gitgalaxy-raw-output)

### Regressionstestsuite

**7.043 Tests** in der Standard-Suite (`python -m pytest tests/`), davon
**6.165** Signatur-spezifische Tests über alle 45 strukturell signierten
Sprachen — positive Übereinstimmungen, explizite Ausschlüsse und adversariale/ReDoS-
Eingaben. Siehe [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) für die Aufschlüsselung und
[`docs/why_gitgalaxy_beats_ast_here.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/why_gitgalaxy_beats_ast_here.md)
für spezifische, belegte Fälle, in denen diese Extraktion eine AST-Auswertung übertrifft.

### Historische Validierung

Die nächste Forschungsebene wird testen, ob Expositionsmessungen
realen Sicherheits- und Wartungsereignissen über die Git-Historie entsprechen.

------------------------------------------------------------------------

# Was GitGalaxy ist — und was nicht

### GitGalaxy ist

-   strukturelle Intelligenz im Repository-Maßstab
-   sprachunabhängige Quellcode-Analyse
-   eine gemeinsame strukturelle Darstellung über heterogenen Code hinweg
-   Priorisierung von Risikoexposition
-   Architektur-Mapping
-   CI-native Belegegenerierung
-   nützlich für defekte/nicht kompilierte Repositorys
-   für lokalen/Offline-Betrieb konzipiert

### GitGalaxy ist nicht

-   ein Ersatz für CodeQLs tiefgehende Dataflow-Analyse
-   ein Ersatz für Semgrep-Regelökosystem
-   ein Ersatz für CVE-Datenbanken von Abhängigkeiten
-   ein Beweis für Ausnutzbarkeit
-   ein Laufzeit-Analysator
-   ein vollständiger Sprachparser
-   eine Garantie, dass hohe Exposition eine Schwachstelle ist

  -----------------------------------------------------------------------
  Tool                                Primäre Frage
  ----------------------------------- -----------------------------------
  **GitGalaxy**                       Wie sieht dieses gesamte Repository
                                      strukturell aus, und wohin sollte
                                      die Aufmerksamkeit zuerst gehen?

  Tree-sitter                         Welche syntaktische Struktur enthält
                                      dieser Quellcode?

  Ctags                               Wo befinden sich die navigierbaren
                                      Code-Entitäten?

  Semgrep                             Entspricht dieser Code einem
                                      bestimmten Muster?

  CodeQL                              Welche Daten-/Kontrollbeziehungen kann
                                      eine tiefere Analyse herstellen?

  SCA/CVE-Tools                       Ist diese Abhängigkeit/Version mit
                                      einem bekannten Advisory verbunden?
  -----------------------------------------------------------------------

------------------------------------------------------------------------

# Realer Maßstab

GitGalaxy ist für Repositorys gedacht, die zu heterogen oder defekt für einen
traditionellen einsprachigen Build-first-Workflow sind.

Beispiel: **Kubernetes**

~1,39 Mio. Zeilen über Go, YAML, JSON, Shell und Proto.

End-to-End-Scan: **50,83 Sekunden**.

![GitGalaxy-Scan-
Geschwindigkeit](https://assets.kitploit.com/production/public/readmes/7003/596585161af8eeb861f49e2968927d69059333f145c0e2b6e9bb0cb9c9d7bc36.png)

Siehe das [Rohausgabe-
Repository](https://github.com/squid-protocol/gitgalaxy-raw-output) für
unbearbeitete Artefakte.

------------------------------------------------------------------------

# Ausgaben

  Ausgabe                       Zweck
  ---------------------------- ----------------------------------------
  **SARIF**                     CI-/Sicherheits-Dashboard-Integration
  **CycloneDX-SBOM**            Bestandsaufnahme/Compliance von Abhängigkeiten
  **SQLite**                    Abfragbarer Repository-Wissensgraph
  **LLM-Architektur-Briefing**  Kompakter maschinen-/agentenorientierter Kontext
  **JSON-Auditdaten**           Forensik-/Automatisierungsworkflows
  **3D-Visualisierungsdaten**   Interaktive Repository-Topologie

Dies sind verschiedene Ansichten desselben deterministischen Scans und keine
unabhängigen Analyse-Engines.

------------------------------------------------------------------------

# Git-Historie und Architektur

GitGalaxy integriert die Git-Historie bereits in Signale wie:

-   Churn
-   Beitragenden-Konzentration
-   Bus-Factor-Exposition
-   Refactoring-Hotspots
-   Dateibesitz
-   zeitliche Aktivität

Die Forschungsrichtung besteht darin, dies von **Historie als kontextuellem
Signal** zu **Historie als externer Validierungsquelle für das Expositionsmodell**
zu erweitern.

------------------------------------------------------------------------

# Datenschutz und Bereitstellung

GitGalaxy ist für lokalen und Air-Gapped-Betrieb konzipiert.

-   Quellcode wird nicht an einen GitGalaxy-Clouddienst gesendet.
-   Scannen und Vektorisierung erfolgen lokal.
-   Der Scanner hat keine Laufzeit-Netzwerkanforderung.
-   CI/CD-Ausführung kann innerhalb der Umgebung des Benutzers bleiben.
-   Der Browser-Visualisierer arbeitet mit lokal bereitgestellten Daten.

------------------------------------------------------------------------

# Installation``` bash
pip install gitgalaxy

Siehe die Dokumentation für aktuelle Befehle und Konfiguration.

CI/CD

Vorlagen werden bereitgestellt für:

GitHub Actions
GitLab CI
Bitbucket Pipelines
Azure Pipelines
generische, per Shell aufrufbare CI-Umgebungen

Siehe templates/ und den CI-Integrationsleitfaden.

Die Belege erkunden

Ressource Was sie enthält

Dokumentation Architektur, Behauptungen und Methodik

Language Crucible Sprachübergreifender Benchmark und Goldstandard-Korpus

Rohausgabe Unbearbeitete Scans realer Repositorys

tests/README.md Regression und Goldstandard-Methodik

tri_comparison_ledger.json Validierungsprotokoll Abweichung-für-Abweichung

manual_verification.json Geprüfte Fälle, in denen die Abdeckung des Vergleichsprogramms nicht verfügbar ist

how_to_investigate_a_discrepancy.md Methodik bei Vergleichsprogramm-Abweichungen

Visualizer Lokale, browserbasierte Repository-Visualisierung

Aktuelle Forschungsrichtung

GitGalaxy durchläuft eine Abfolge zunehmend schwieriger Fragen:

Können wir heterogenen Quellcode scannen, ohne ihn zu kompilieren?

↓

Können wir zuverlässig die strukturellen Entitäten wiederherstellen, die zum Verständnis nötig sind?

↓

Entsprechen diese strukturellen Messungen einer bedeutsamen Risikoexposition?

↓

Verhält sich die gemessene Exposition korrekt, wenn sich reale Software weiterentwickelt?

Die Tree-sitter/Ctags-Validierung ist derzeit etwa zur Hälfte abgeschlossen. Die unmittelbare Priorität ist es, diese Prüfung abzuschließen, bevor vorläufige Messungen in stärkere Behauptungen umgewandelt werden.

Das nächste große Experiment ist:

Git-Historie → unabhängig identifizierte Änderungs-/Fix-Ereignisse → GitGalaxy-Vorher/Nachher-Scans → Expositionsdeltas → statistische Analyse.

Dort kann GitGalaxy beginnen, nicht nur zu testen, ob es Struktur erkennt, sondern ob sein Strukturmodell bedeutsame Änderungen in realer Software nachverfolgt.

Lizenz

GitGalaxy wird unter der PolyForm Noncommercial License 1.0.0 vertrieben.

Die vollständigen Bedingungen finden Sie in der Repository-Lizenz.