
AST-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.
# GitGalaxy
**Repository-weite strukturelle Intelligenz ohne Kompilierung.**
[Docs](https://squid-protocol.github.io/gitgalaxy/) ·
[Visualizer](https://gitgalaxy.io/) ·
[Language Crucible](https://github.com/squid-protocol/language-crucible) ·
[Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta) ·
[Raw Output](https://github.com/squid-protocol/gitgalaxy-raw-output)
**1 Scan · 97 strukturelle Signale · 50+ Sprachen · keine Kompilierung · 17
Risikoexpositionskategorien · 6 Ausgaben**
## Die Kurzfassung
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:
``` text
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](#accuracy-measured) zusammengefasst und
vollständig im [Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) dargelegt.
------------------------------------------------------------------------
## Was ein Scan liefert
Ein Befehl:
``` bash
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 Architektur-Brief
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](https://github.com/squid-protocol/gitgalaxy-raw-output);
der stets aktuelle Self-Scan-Brief dieses Repositorys selbst befindet sich unter
[`docs/gitgalaxy_architecture_brief.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/gitgalaxy_architecture_brief.md).
### Ein Graph, viele Konsumenten
| 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? |

------------------------------------------------------------------------
## Genauigkeit, gemessen
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](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md); dies ist die Zusammenfassung.
### Strukturelle Validierung: GitGalaxy vs. Tree-sitter vs. Ctags
GitGalaxy wird gegen **Tree-sitter und Universal Ctags** auf dem gepinnten
[Language Crucible](https://github.com/squid-protocol/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.

### Graph-Validierung: Importe und Aufrufe (in Arbeit)
Blast-Radius, PageRank und die „strukturellen Säulen" stammen aus dem
**Import-Graphen**. Die Rankings auf Funktionsebene stammen aus dem
**Aufrufgraphen**. Keiner der beiden Graphen ist bisher in jeder Sprache
gemessen, und das folgende Diagramm zeigt, welche:
- Gemessene Sprachen zeigen Präzision und Recall mit n.
- Jede noch nicht gemessene Sprache wird namentlich aufgeführt.
Stand 2026-09-26, von 59 Sprachen:
- **Der Import-Graph ist in 20 gemessen.** Engine-Kanten werden gegen die
eigenen Import-Anweisungen jeder Sprache auf gepinnten echten Repositorys
geprüft
([`import_graph_accuracy.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/import_graph_accuracy.py)).
- **Callee-Namen sind in 11 gemessen**, gegen Tree-sitter.
- **Aufrufauflösung ist in 3 gemessen**, gegen einen Referenzanalysator:
- Python, gegen pyan3: 99,8 % Präzision bei 1.806 beurteilten Links, 51,6 % Recall;
- TypeScript, gegen den TypeScript-6.0.2-Typprüfer: 99,9 % Präzision bei 1.520 beurteilten Links,
57,1 % Recall;
- Java, gegen scip-java (javacs eigene Auflösung): 92,7 % Präzision bei 3.474 beurteilten Links,
41,0 % Recall. Ein Aufruf einer überladenen Methode wird nur verlinkt, wenn seine Argumentanzahl
eine Überladung auswählt ([#3835](https://github.com/squid-protocol/gitgalaxy/issues/3835)).
Ein Aufruf-Link ist, wenn er hergestellt wird, meistens richtig, aber etwa die Hälfte oder mehr der Aufrufe
bleiben unverlinkt. Daher sind Fan-in und PageRank auf Funktionsebene eine untere Schranke.
Die Grenzen:
- Die Graphen der anderen 38 Sprachen werden auf dieselbe Weise aufgebaut, sind aber **nicht gemessen**.
- Mehrere gemessene Sprachen stützen sich auf ein Repository mit weniger als 100 Importen. Das Diagramm
blendet diese aus.
- Ein `*` markiert eine Zahl mit Abweichungen, die noch auf ein Urteil gegen den Quellcode warten.
Der Plan, diese Lücken zu schließen, ist
[Epic #3772](https://github.com/squid-protocol/gitgalaxy/issues/3772).

### Sprachübergreifende Konsistenz: der Keyword-Rosetta-Kontrollkorpus
Das neuere Programm stellt die entgegengesetzte Frage: **Misst GitGalaxy
identische Absicht in jeder Sprache identisch?** Der
[keyword-rosetta](https://github.com/squid-protocol/keyword-rosetta)-Korpus
pflanzt dasselbe 12-Sonden-Programm in alle 50 unterstützten Sprachen mit
exakt bekannten Signalzahlen — sodass jede Divergenz konstruktionsbedingt
gemessene Sprachverzerrung ist. Das Diagramm färbt jede Abweichung nach
*Ursache*, nicht nach Größe: Rot ist ein offener Engine-Defekt (eine Regel,
die auf das falsche Konstrukt passt, oder ein Scoring-Gewicht innerhalb einer
Zählung); Grau ist eine dokumentierte Variation, die das Ledger validiert hat —
die Sprache kann das Konstrukt nicht ausdrücken, eine bewusste Scoring-
Entscheidung oder ein Echo einer anderen Zeile. Aktuelle Antwort: Im
Durchschnitt liegen 94 % der Sprachen pro gated Metrik innerhalb von ±25 %
des sprachübergreifenden Medians (56 darstellbare Metriken, 54 halten ≥80 %),
und **der Anteil offener Defekte beträgt 0,0 % (1 von 2.844 vergleichbaren
Zellen über 59 gated Metriken)** — eine einzige unerklärte Zelle,
`classes_found` im neu gepflanzten `bms`-Korpus (CICS Basic Mapping Support);
jede andere außerhalb des Bandes liegende Zelle ist eine vom Ledger validierte
Variation (eine Strenge-Schicht, ein Konstrukt, das die Sprache nicht
ausdrücken kann, ein Echo einer anderen Zeile oder eine bewusste Scoring-
Entscheidung), kein offener Engine-Defekt. Die schwächsten Metriken werden
benannt statt versteckt — `cog_raw` hält 74 % der Sprachen im Band,
`raw_arch_api` 78 %, `avg_func_args` 80 % — aber ihre Sub-Band-Zellen sind
dokumentiert, keine Defekte. Die Aussage übersteht auch eine Erweiterung: Als
der Korpus seine erste Security-Lens-Sonde pflanzte — ein identisches
hartcodiertes Secret in jeder Sprache —, las `credential_material` (früher
`risk_secrets_risk`; der `risk_*`-Name bleibt die DB-Spalte — siehe
[`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md)) einen **einheitlichen Score über alle
50 Sprachen** (ein identisches 25.000 pro Spalte). Die beiden
Inert-Format-Ausnahmen, die die Lens ursprünglich übersprang, und die
gemessene Längenabhängigkeit der Formel wurden noch am selben Tag ins Ledger
aufgenommen und gemeldet
([#2978](https://github.com/squid-protocol/gitgalaxy/issues/2978),
[#2979](https://github.com/squid-protocol/gitgalaxy/issues/2979)). #2978 ist
geschlossen: Die Lens läuft jetzt auf allen fünf inerten Formaten
(plaintext/markdown/json/yaml/csv), mit einem `SECURITY_SCAN_INERT_FORMATS`-
Config-Opt-out für Repositorys, bei denen das zu viel Doc-/Config-Rauschen
gegen die Abdeckung eintauscht, und die erneute Verifikation des
keyword-rosetta-Korpus gegen den gemergten Fix landet nun vollständig im Band
(der `secrets-lens-inert-formats`-Eintrag des Ledgers). Jede Abweichung wird
in einem validierten Ledger festgehalten, die Arbeit wird nach
Ursachenfamilie unter der [Contract-Roadmap](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/contract_roadmap.md)
verfolgt, und die so gefundenen Defektklassen werden
[als GitGalaxy-Issues gemeldet](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/findings_by_language.md).

Ein Kontrollkorpus beweist Messungleichheit bei identischer Absicht; er sagt
nichts über Genauigkeit bei echtem Code aus (die Aufgabe des Tri-Vergleichs
oben) — und eine konstante Verzerrung pro Datei erhält weiterhin das Ranking
*innerhalb* einer Sprache. Der
[Inzidenzbericht](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/incidence_report.md)
bemisst jede bestätigte Form gegen echten lizenzierten Code.
------------------------------------------------------------------------
## Realweltliche Größenordnung
Beispiel: **Kubernetes** — ~1,39 Mio. Zeilen über Go, YAML, JSON, Shell und Proto.
End-to-End-Scan: **50,83 Sekunden**. Die Scan-Zeit folgt einem angepassten
Zwei-Regime-Modell (flach ~0,11 s unter ~4,3K LOC, dann
`time(s) ≈ 3.36e-05 × LOC^0.969`, R²=0,88 über 599 Repositorys) — daher
brauchen einige Ausreißer mit 20 Mio.+ LOC immer noch Minuten, und ein
schneller Scan beweist Durchsatz, nicht Erkenntnisqualität; die
Genauigkeitsfrage wird unten separat behandelt.

Siehe das [Raw-Output-
Repository](https://github.com/squid-protocol/gitgalaxy-raw-output) für
unedited Artefakte.
------------------------------------------------------------------------
# Structural Surface Profile: Was GitGalaxy behauptet (früher „Risk exposure")
GitGalaxys 13 Vektoren pro Datei hießen ursprünglich `risk_*` und wurden als
**Risikoexpositions-Messungen** beschrieben. Die Frage, die dieser Abschnitt
früher offenließ — „sind diese Signaturen empirisch mit bedeutsamen Klassen
von Softwarerisiko verbunden?" —, wurde inzwischen getestet, nicht nur
gestellt. Das Temporal-Crucible-Validierungsprogramm (Epic
[#2982](https://github.com/squid-protocol/gitgalaxy/issues/2982), ~3.550
gescannte Snapshots, zwei Repositorys, drei Label-Familien, jeder Test
vorregistriert, bevor die Daten betrachtet wurden) führte dieses Experiment
bis zur Erschöpfung durch, und das ehrliche Ergebnis trieb eine Umbenennung
voran
([#2991](https://github.com/squid-protocol/gitgalaxy/issues/2991)): Die
Vektoren heißen jetzt **Structural Surface Profile**. `risk_*` bleibt aus
Kompatibilitätsgründen der DB-Spalten-/JSON-Schlüsselname (siehe
[`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) für die vollständige Namenstabelle und
den Deprecation-Hinweis).
**Was die Aufzeichnung ergab, ehrlich wiedergegeben:**
- **Bestandsrisiko pro Datei, falsifiziert.** Die Gründungshypothese — dass
das `risk_*`-Niveau einer Datei oder seine Veränderung nach einem Fix die
Defektwahrscheinlichkeit abbildet — hielt nicht stand. Der mediane
strukturelle Delta nach einem Security-Fix betrug +0,000
(äquivalenzbestätigt nahe null auf einem zweiten, unabhängigen Repository,
nicht nur nicht signifikant); die summierte strukturelle Exposition
rangierte *zuletzt* von sechs Merkmalen zur Vorhersage fix-berührter
Dateien; ein multivariater struktureller Vektor mit 26 Signalen erreichte
unter einem temporalen Split Zufallsniveau (AUC 0,479), unter einer
einfachen Zeilenzahl (0,531). Das vollständige Ledger befindet sich in
temporal-crucibles `docs/HYPOTHESES.md` und ist von
[#2982](https://github.com/squid-protocol/gitgalaxy/issues/2982) verlinkt.
- **Wofür die Vektoren tatsächlich validiert wurden:** die Beschreibung von
**Aktivität und Inhalt**, nicht von Defektwahrscheinlichkeit. Das
fix-förmige Komposit bildet zuverlässig einen Gradienten von Security-Fix →
gewöhnlicher Fix → Kontrolle → Revert ab; Deltas entsprechen echten
Code-Ereignissen (Guard-Code hinzugefügt, Threading eingeführt,
Debt-Marker verdünnt). Das ist das Röntgenbild, das dieses Dokument nun
akkurat benennt — siehe [`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) Vektor für
Vektor.
- **Systemweites / historisches Signal, neu formuliert als der tatsächliche
prädiktive Befund.** Zwei Merkmale *überlebten* die Validierung:
**Rückfälligkeit** (die Datei, die den letzten Fix hatte, bekommt den
nächsten — das am häufigsten replizierte Ergebnis des Programms, p<1e-4 auf
beiden Repositorys) und **Änderungsentropie / Hassan HCM**, validiert
außerhalb der Auswahl auf frischen Bug-Labels (AUC 0,868 gegenüber 0,830
einer Zeilenzahl). Beide sind **Historien**-Metriken, keine strukturellen
Inhaltsmetriken — und beide sind derzeit in jedem Scan auf null gesetzt
(`GITGALAXY_DISABLE_GIT_HISTORY`, verfolgt in
[temporal-crucible#29](https://github.com/squid-protocol/temporal-crucible/issues/29)).
Dies ist der Keim einer separaten, ehrlich benannten **prädiktiven
Schicht** — die Vektoren `hist_stability`/`hist_churn` sind so benannt, um
diesen Status explizit zu markieren —, die daran geknüpft ist, den
historienfähigen Modus auszuliefern und dann den Defekt-Lift-
Promotionsvertrag von
[#2987](https://github.com/squid-protocol/gitgalaxy/issues/2987) zu
erfüllen.
Ein hoher Structural-Surface-Profile-Wert bedeutet:
> **Diese Stelle weist mehr eines gegebenen strukturellen/inhaltlichen
> Musters auf, relativ zum Rest des Repositorys.**
Er bedeutet nicht:
> „Dieser Code enthält wahrscheinlicher einen Defekt" — die Version dieser
> Aussage pro Datei wurde getestet und hielt nicht stand.
Die zugrunde liegenden Signaturen decken Muster in Bereichen ab wie:
- Secrets
- Injektionsoberfläche
- unsichere/Speicher-Operationen
- dynamische Ausführung
- I/O
- Nebenläufigkeit
- Zustandsmutation
- Reflexion
- APIs
- Abhängigkeiten
- Entropie
- weitere strukturelle/Sicherheits-Eigenschaften
Siehe [`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) für die Umbenennungstabelle pro
Vektor, Belege und geeignete/ungeeignete Verwendungen sowie
[temporal-crucible](https://github.com/squid-protocol/temporal-crucible)s
`docs/HYPOTHESES.md` für das vollständige Validierungs-Ledger, das dieser
Abschnitt zusammenfasst.
------------------------------------------------------------------------
# Belege, nicht nur Behauptungen
### Language Crucible
Ein gepinnter Korpus aus realweltlichem Quellcode, einschließlich Projekten
wie Godot, Roslyn, curl, Kubernetes und Apollo-11-Flugsoftware.
[Language Crucible](https://github.com/squid-protocol/language-crucible)
### Golden-Master-Regression
Echter Quellcode wird erneut gescannt und mit eingecheckter erwarteter Ausgabe
verglichen, sodass Parser-Änderungen einen beobachtbaren Diff haben.
Regeneriert mit
[`tests/tools/update_golden_master.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/update_golden_master.py),
niemals von Hand bearbeitet.
### Tri-Vergleich
Derselbe Korpus wird gegen GitGalaxy, Tree-sitter und Ctags analysiert, wo
Abdeckung existiert — 24 von 45 Sprachen erhalten alle drei Tools, 200 von 201
protokollierten Diskrepanzen validiert. Auf dem gepinnten Korpus ist GitGalaxy
nie das Tool, das bei einer validierten Funktionspräzisions-, Klassen- oder
Argument-Diskrepanz als falsch befunden wird, und erreicht Tree-sitters
Funktions-Recall überall außer bei einer verschachtelten Shell-Definition, die
es konstruktionsbedingt überspringt. Siehe
[die Methodik](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) und
[das Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) für das vollständige Bild und
seine Grenzen.
### Keyword-Rosetta-Kontrollkorpus
Dasselbe 12-Sonden-Programm in alle 50 unterstützten Sprachen gepflanzt, mit
exakt bekannten Signalzahlen, das die sprachübergreifende Konsistenz jeder
Metrik misst — mit einem validierten Abweichungs-Ledger und den daraus
resultierenden Engine-Defekten, die
[als Issues gemeldet wurden](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/findings_by_language.md).
[Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta)
### Rohausgabe des Repositorys
Uneditierte GitGalaxy-Ausgabe wird für Hunderte unabhängig ausgewählte
Repositorys aufbewahrt.
[Raw Output](https://github.com/squid-protocol/gitgalaxy-raw-output)
### Regressionssuite
**7.043 Tests** in der Standard-Suite (`python -m pytest tests/`), davon
**6.165** Tests pro Signatur über alle 45 Sprachen mit strukturellen
Signaturen — positive Treffer, explizite Ausschlüsse und adversarial/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 konkrete, belegte Fälle, in denen diese Extraktion einen AST-Lesevorgang
übertrifft.
### Temporal Crucible (historische Validierung)
Ob das Structural Surface Profile realen Sicherheits- und Wartungsereignissen
über die Git-Historie entspricht, ist keine offene Frage mehr — es wurde
getestet. Das
[Temporal Crucible](https://github.com/squid-protocol/temporal-crucible)-
Programm scannte ~3.550 Repository-Snapshots über zwei Repositorys (curl,
nDPI) und drei Label-Familien (CVE-Fix-/Introduce-Commits, Bug-Labels,
CWE-Familien), wobei jeder bestätigende Test vorregistriert wurde, bevor die
Daten betrachtet wurden. Was es fand, ehrlich dargestellt:
- **Bestandsrisiko pro Datei sagt keine Defekte voraus** — es reduziert sich
auf eine Zeilenzahl, eine Null, die durch Äquivalenztestung auf einem
zweiten, unabhängigen Repository bestätigt wurde (nicht bloß „nicht
signifikant").
- **Zwei *Historien*-Metriken sagen voraus**: Rückfälligkeit (die Datei, die
den letzten Fix hatte, bekommt den nächsten — p<1e-4 auf beiden
Repositorys, das am häufigsten replizierte Ergebnis des Programms) und
Änderungsentropie (Hassan HCM), validiert außerhalb der Auswahl auf
frischen Bug-Labels.
- **Struktur beschreibt; Historie sagt voraus.** Mehr Vorhersagen starben im
Ledger, als es überlebten — das ist die Disziplin der Vorregistrierung,
die funktioniert, keine Enttäuschung.
Die vollständige Aufzeichnung ist öffentlich und reproduzierbar: das
vorregistrierte
[Hypothesen-Ledger](https://github.com/squid-protocol/temporal-crucible/blob/main/docs/HYPOTHESES.md)
und ein [Prädiktor-×-Ergebnis-Index](https://github.com/squid-protocol/temporal-crucible/blob/main/docs/EXPERIMENTS.md)
von allem, was das Programm zu korrelieren versucht hat. Design und Methode:
[das Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md#the-next-validation-risk-over-git-history).
[Temporal Crucible](https://github.com/squid-protocol/temporal-crucible)
------------------------------------------------------------------------
# Was GitGalaxy ist --- und was nicht
### GitGalaxy ist
- strukturelle Intelligenz auf Repository-Ebene
- sprachunabhängige Quellcodeanalyse
- eine gemeinsame strukturelle Repräsentation über heterogenen Code hinweg
- Priorisierung von Risikoexposition
- Architektur-Mapping
- CI-native Evidenzgenerierung
- nützlich bei defekten/nicht kompilierten Repositorys
- für lokalen/Offline-Betrieb ausgelegt
### GitGalaxy ist nicht
- ein Ersatz für CodeQLs tiefe Datenflussanalyse
- ein Ersatz für Semgreps Regel-Ökosystem
- ein Ersatz für Dependency-CVE-Datenbanken
- ein Beweis der Ausnutzbarkeit
- ein Laufzeitanalysator
- ein vollständiger Sprachparser
- eine Garantie, dass eine hohe Exposition eine Schwachstelle ist
| Tool | Primäre Frage |
|---|---|
| **GitGalaxy** | Wie sieht dieses gesamte Repository strukturell aus, und worauf sollte zuerst geachtet werden? |
| Tree-sitter | Welche syntaktische Struktur enthält dieser Quellcode? |
| Ctags | Wo befinden sich die navigierbaren Code-Entitäten? |
| Semgrep | Entspricht dieser Code einem angegebenen Muster? |
| CodeQL | Welche Daten-/Kontrollbeziehungen kann eine tiefergehende Analyse feststellen? |
| SCA/CVE-Tools | Ist diese Abhängigkeit/diese Version mit einem bekannten Advisory verknüpft? |
------------------------------------------------------------------------
# Git-Historie und Architektur
GitGalaxy integriert die Git-Historie bereits in Signale wie Churn,
Contributor-Konzentration, Bus-Faktor-Exposition, Refactoring-Hotspots, Datei-
Eigentümerschaft und zeitliche Aktivität. Die Forschungsrichtung besteht darin,
dies von **Historie als kontextuelles Signal** zu **Historie als externe
Validierungsquelle für das Expositionsmodell** zu erweitern — das
Versuchsdesign befindet sich in
[dem Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md#the-next-validation-risk-over-git-history).
------------------------------------------------------------------------
# Datenschutz und Bereitstellung
GitGalaxy ist für den lokalen Betrieb und den Betrieb in abgeschotteten Umgebungen konzipiert.
- Quellcode wird nicht an einen GitGalaxy-Cloud-Dienst gesendet.
- Scannen und Vektorisierung erfolgen lokal.
- Der Scanner hat keine Laufzeit-Netzwerkanforderung.
- Die CI/CD-Ausführung kann innerhalb der Umgebung des Benutzers verbleiben.
- Der Browser-Visualizer arbeitet mit lokal bereitgestellten Daten.
------------------------------------------------------------------------
# Installation
``` bash
pip install gitgalaxy # zero install dependencies
pip install "gitgalaxy[full]" # + tiktoken, xgboost, pandas, numpy, pyyaml
```
Siehe die [Dokumentation](https://squid-protocol.github.io/gitgalaxy/) für
aktuelle Befehle und Konfiguration.
### Zero-Dependency-Modus
Ein einfaches `pip install gitgalaxy` zieht nichts weiter hinein, für Umgebungen, in denen
jedes Drittanbieter-Paket eine Supply-Chain-Frage ist. Scans laufen trotzdem: jedes
strukturelle Signal, jede Dependency-Kante, In-/Out-Degree-Zählung, PageRank / Blast
Radius, Betweenness, Closeness, durchschnittliche Pfadlänge, Modularität, zyklische
Dichte, Artikulationspunkte und Assortativität werden exakt wie in voller
Präzision gemessen (diese werden nativ berechnet). Was die optionalen Engines benötigt, ist
Token-Masse und Lesekosten (`tiktoken`), ML-Bedrohungs-
klassifikation (`xgboost`/`pandas`/`numpy`) und YAML-Konfigurations-/OpenAPI-Parsing
(`pyyaml`). Eine Metrik, die nicht berechnet wurde, wird als fehlend gemeldet (`n/a` /
NULL), niemals als Null. Jede Ausgabe sagt, wann ein Scan in diesem Modus lief, und
[`docs/zero_dependency_mode.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/zero_dependency_mode.md) listet Feld für
Feld auf, was identisch ist und was nicht verfügbar ist.
### CI/CD
Vorlagen werden für GitHub Actions, GitLab CI, Bitbucket Pipelines,
Azure Pipelines und generische shell-aufrufbare CI-Umgebungen bereitgestellt. Siehe
[`templates/`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/templates) und den [CI-Integrations-
leitfaden](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/github-action-readme.md).
------------------------------------------------------------------------
# Die Belege erkunden
| Ressource | Was sie enthält |
|---|---|
| [Dokumentation](https://squid-protocol.github.io/gitgalaxy/) | Architektur, Behauptungen und Methodik |
| [Das Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) | Die vollständige Beweiserzählung: These, Benchmarks, Validitätsleiter, nächste Experimente |
| [Vektorreferenz](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) | Die 13 Vektoren pro Datei: Namen, Bedeutung, Belege und der `risk_*`-Deprecation-Hinweis |
| [Vektorformel-Fakten](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vector_formulas.md) | Mechanisches Formel-Audit pro Rechner (Eingaben, Arithmetik, Konstanten) |
| [Language Crucible](https://github.com/squid-protocol/language-crucible) | Sprachübergreifender Benchmark und Goldkorpus |
| [Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta) | Gepflanzter Kontrollkorpus in 50 Sprachen und Bias-Berichte |
| [Rohausgabe](https://github.com/squid-protocol/gitgalaxy-raw-output) | Unbearbeitete Scans realer Repositories |
| [COBOL → Java-Beispiele](https://github.com/squid-protocol/cobol_to_java_examples) | 10 COBOL-Repos, automatisch in kompilierende Spring-Boot-Architekturen übersetzt (`mvn clean compile` funktioniert sofort) |
| [Populationsanalysen](https://github.com/squid-protocol/gitgalaxy-population-analyses) | Statistische Analysen über die Rohausgabe-Scanpopulation: Archetyp-Clustering, Risikoverteilungen, Bedrohungsklassifikator-Studien |
| [Museum of Code](https://squid-protocol.github.io/gitgalaxy/museum-of-code/) | Vollständige architektonische Zerlegungen realer Codebasen (Apollo 11, IBM CICS-Benchmarks) |
| [Verteilungs-Telemetrie](https://github.com/squid-protocol/squid-telemetry) | Öffentliche Abrufmetriken über GitHub/GitLab/[PyPI](https://pypi.org/project/gitgalaxy/), täglich neu generiert |
| [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) | Regressions- und Golden-Master-Methodik |
| [`tri_comparison_ledger.json`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_ledger.json) | Validierungsprotokoll Abweichung für Abweichung |
| [`manual_verification.json`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/manual_verification.json) | Überprüfte Fälle, in denen Vergleichsabdeckung nicht verfügbar ist |
| [`how_to_investigate_a_discrepancy.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/how_to_investigate_a_discrepancy.md) | Methodik für Vergleichsabweichungen |
| [Visualizer](https://gitgalaxy.io/) | Lokale browserbasierte Repository-Visualisierung |
------------------------------------------------------------------------
# Lizenz
Copyright (c) 2026 Joe Esquibel
GitGalaxy wird unter der **PolyForm Noncommercial License 1.0.0** vertrieben.
Siehe die Repository-Lizenz für die vollständigen Bedingungen.