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

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

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?

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:

1. wird die Abweichung protokolliert;
2. wird die Quelle untersucht;
3. wird das Verhalten jedes Werkzeugs untersucht;
4. wird GitGalaxy korrigiert, wenn GitGalaxy falsch liegt;
5. wird der Vergleichs-/Adaptercode korrigiert, wenn der Vergleich falsch liegt;
6. werden echte Werkzeuglimits dokumentiert;
7. 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.

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

Sobald die strukturelle Validierung ausreichend ausgereift ist, kann GitGalaxy sein Expositionsmodell longitudinal testen.``` 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

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

Copyright (c) 2026 Joe Esquibel

GitGalaxy wird unter der PolyForm Noncommercial License 1.0.0 vertrieben.

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