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.
1 Scan · 97 strukturelle Signale · 50+ Sprachen · 0 Kompilierungsbedarf
19 Risiko-Expositionswerte · 6 Endberichte · 0 Abhängigkeiten · pip install gitgalaxy
GitGalaxy existiert für ein wiederkehrendes Problem: das Verständnis einer großen, realen, mehrsprachigen Codebasis, die nicht sauber kompiliert — der Zustand, in dem sich die meisten Produktions-Repositories tatsächlich befinden, nicht die saubere einsprachige Eingabe, die die meisten Static-Analysis-Tools voraussetzen.
time(s) ≈ 3.36e-05 × LOC^0.969 darüber (R²=0,88, nahezu linear, ohne Verschlechterung bei großen Eingaben) — siehe Beweis, nicht nur Behauptungen für das Diagramm und die Herleitung, nicht nur diese gerundete Überschrift.Dies ist kein Schwachstellen-Scanner, der mit CodeQL, Semgrep oder SonarQube konkurriert. Diese Tools führen eine tiefe, präzise Analyse durch, sobald Ihr Code kompiliert, normalerweise eine Sprache nach der anderen. GitGalaxy beantwortet zuerst eine andere Frage — wie sieht dieses gesamte System tatsächlich aus und wo konzentriert sich das Risiko — gleichzeitig über alle Sprachen im Repo, bevor diese tieferen Tools überhaupt einen Build haben, mit dem sie arbeiten können. Siehe „Wie sich das architektonisch vergleicht" unten, um genau zu erfahren, wo die Aufgabe jedes Tools beginnt und endet.
Gitgalaxy kann vollständige Repos bewerten, die aus Mischungen von über 50 verschiedenen Sprachen bestehen, die Architektur abbilden und Risiko-Expositionen zusammen mit priorisierten Refactoring-Zielen aufzeigen — Hotspots, Bus-Faktor-Risiko und tragende Dateien — damit Sie wissen, worauf Sie sich zuerst konzentrieren sollten. Das folgende Diagramm ist ein Workflow aus einem Gitgalaxy-Scan unseres Golden-Test-Repos, das Beispielcode-Dateien von der Apollo-11-Flugsoftware von 1969 bis zu den modernen Tech-Stacks enthält. Benchmark
Das Kern-Ergebnis von Gitgalaxy ist eine Sache: ein deterministischer struktureller Graph des gesamten Repositories. Sicherheitsaudits, Refactoring-Priorisierung und Legacy-zu-Modern-Sprachübersetzung (siehe Enterprise-Codebase-Tools & Anwendungsfälle unten) sind alle Konsumenten desselben Graphen, keine separaten Produkte mit separaten Engines — weshalb sich das eher wie eine Architektur-Intelligenz-Plattform liest als wie ein zweckgebundener Schwachstellen-Scanner.
Die meisten Code-Intelligence-Engines verwenden einen AST, wie tree-sitter, der eine übermäßig granulare Sicht auf ein Repo bietet (wie wenn man ein Haus verstehen will und eine Liste jedes Ziegels und jeder Glasscheibe bekommt) und die Sprachen und Dateien begrenzt, die gescannt werden können. Moderne Repos sind polyglott. Viele Repos haben alten Code ohne einen guten AST. Um das zu umgehen, verwendet Gitgalaxy eine eigene Regex-/lexikalische Strukturanalyse-Engine mit einer Statistikschicht darüber — sie baut einen Feature-Vektor pro Datei (aus ~97 Regex-„Signal"-Kategorien, die die Grenzen von Funktionen, Kontrollfluss, I/O, Zustandsänderung und Dutzende andere strukturelle und sicherheitsrelevante Verhaltensweisen markieren) und pro Repo (Abhängigkeitsgraph durch Importauflösung + PageRank/Zentralität), transformiert dann diese Rohzählungen über Sigmoid-Funktionen in normalisierte Risiko-Scores von 0–100 und exportiert das Ergebnis in sechs Formate.
Gitgalaxy tauscht AST-Präzision gegen Geschwindigkeit um Größenordnungen und universelle Sprachabdeckung — im gleichen Geist, in dem BLAST Smith-Watermans erschöpfende Ausrichtung gegen heuristische Geschwindigkeit in der Genomik eingetauscht hat. Der Output umfasst SARIF, CycloneDX-SBOM, einen abfragbaren SQLite-Wissensgraphen, einen LLM-optimierten Architektur-Brief und 3D-Visualisierungsdaten aus einem einzigen Scan-Durchgang — siehe „Welches Problem löst das?" oben für reale Scan-Zeit-Zahlen statt eines bloßen Adjektivs.
Das Ergebnis ist ein deterministischer Wissensgraph des Repositories, der erstellt wird, ohne dass der Code jemals kompilieren muss. Er berechnet das Verhältnis von Testcode zu Kernlogik, bildet den nachgelagerten „Blast Radius" jeder Datei über den Abhängigkeitsgraphen ab und zeigt Projektstruktur-Signale auf, die zeilenweise Linter vollständig übersehen. Die Signalextraktion pro Datei läuft in linearer Zeit zur Codebasisgröße; Graphmetriken auf Repository-Ebene (Zentralität, Community-Erkennung) verwenden Standard-Netzwerkanalyse-Algorithmen mit expliziten Stichprobengrenzen bei sehr großen Graphen.
GitGalaxy erzeugt zwei verschiedene Arten von Ausgaben, und sie sollten unterschiedlich gelesen werden.
Risiko-Expositionswerte sind ein 0–100, dichtenormalisiertes Signal über 19 Kategorien (Geheimnisse, Injection-Oberfläche, Speicherkorruption und mehr), das von Funktion zu Datei zu Ordner zu Repository aggregiert wird. Ein hoher Wert bedeutet das verdient zuerst Aufmerksamkeit — es ist ein Priorisierungssignal, kein Urteil. Zwei Dateien können denselben Wert aus völlig unterschiedlichen Gründen tragen: ein echtes Problem oder ein legitimes Muster, das an der Oberfläche identisch aussieht. Verschlüsselte Malware und eine gut getestete Kryptographie-Routine erzeugen beide hohe Entropie. GitGalaxy kann Ihnen nicht sagen, welche davon es gefunden hat — nur dass dort etwas ist, das einen zweiten Blick wert ist.
Findings sind einzelne Flags auf Zeilenebene: eine spezifische strukturelle Signatur, die eine Risikoschwelle überschritten hat. Das sind Belege zur Prüfung, keine bestätigten Schwachstellen. GitGalaxy führt niemals Code aus, verfolgt keinen Laufzeit-Datenfluss und verifiziert keine Ausnutzbarkeit — es sagt Ihnen, dass ein Muster im Text existiert, an genau dieser Zeile, und gibt Ihnen den Kontext, um es selbst zu beurteilen.
Das ist beabsichtigt, keine Einschränkung, die wir verstecken. GitGalaxy ist darauf ausgelegt, eher in Richtung Recall als Präzision zu irren: mehr flaggen und einen Menschen oder ein tieferes Tool die Liste eingrenzen lassen, anstatt zu riskieren, über etwas Reales zu schweigen. Falschpositive sind die erwarteten Kosten dieses Abwägens, genauso wie bei jedem statischen Analyzer, der den gelesenen Code nicht ausführt.
Das bedeutet auch, dass GitGalaxy gegen eine bestimmte Klasse von Problemen am stärksten ist — Fahrlässigkeit, nicht gegnerische Umgehung. Ein hartkodierter Schlüssel, den jemand vergessen hat zu entfernen, eine unsichere Registry, ein offensichtlich gefährlicher eval()-Aufruf — niemand auf der anderen Seite dieser Dinge versucht, sich vor einem Scanner zu verstecken. Ein gezielt motivierter Angreifer, der weiß, wie statische, signaturbasierte Erkennung funktioniert, kann einzelne Signale wie Entropieschwellen ohne großen Aufwand umgehen. Behandeln Sie GitGalaxy als den schnellen ersten Durchlauf über eine Codebasis, die zu groß zum manuellen Lesen ist — nicht als das letzte Wort darüber, ob etwas sicher ist.
Die meisten Dependency-Scanner arbeiten mit einer Nachschlagetabelle: Sie wissen, dass eine Schwachstelle existiert, weil jemand sie gefunden, gemeldet hat und sie nun eine CVE-Nummer in einem Feed hat. Das ist nützlich, aber notwendigerweise reaktiv — ein so aufgebauter Scanner ist blind für alles, was noch nicht entdeckt und offengelegt wurde, einschließlich einfacher Varianten bekannter schlechter Muster, die nur leicht anders aussehen als der gemeldete Fall.
GitGalaxy verfolgt einen anderen Ansatz: Statt bekannter Instanzen abzugleichen, gleicht es Schwachstellen-Klassen ab. Seine Findings sind nach CWE (Common Weakness Enumeration) getaggt — hartkodierte Anmeldeinformationen, dynamische Codeausführung, unsichere Deserialisierung — nicht nach CVE-ID. Eine strukturelle Signatur für „dynamische Ausführung von kontaminiertem Input" erkennt dieses Muster, wo immer es auftritt, mit welchen Variablennamen auch immer, in welcher spezifischen Anordnung auch immer — nicht nur die eine Instanz, über die bereits jemand einen Bericht eingereicht hat.
Die gleiche Philosophie erstreckt sich auf die SBOM-Ebene. Anstatt zu fragen „erscheint diese Paketversion in einer Schwachstellendatenbank", fragt GitGalaxy „entspricht der tatsächliche Inhalt dieses Pakets auf der Platte strukturell dem, wie eine legitime Version aussehen sollte" — Entropie, struktureller Fingerabdruck, Flags für Verhaltensanomalien. So wird eine manipulierte Abhängigkeit am ersten Tag erwischt, bevor irgendjemand etwas entdeckt oder offengelegt hat, weil es keine CVE gibt, auf die man warten müsste.
Das ist eine Ergänzung zu CVE-Feed-Tools (Snyk, Dependabot, OSV-Scanner), kein Ersatz für sie — diese Tools sind die richtige Antwort auf „ist dieser exakte bekannte Fehler vorhanden". GitGalaxy ist die richtige Antwort für das weitere Netz: Schwachstellenklassen und physische Anomalien, die nicht erfordern, dass jemand zuerst die spezifische Instanz gefunden und gemeldet hat.
Dies ist ein eigenberichteter Vergleich dessen, was jedes Tool strukturell erfordert und erkennt, kein unabhängiger Benchmark — bitte anhand der eigenen Dokumentation jedes Projekts verifizieren. Er existiert, um eine Frage klar zu beantworten: Welche Lücke ist GitGalaxy tatsächlich gebaut, um sie zu schließen, gegenüber Tools, die eine verwandte, aber andere Aufgabe erfüllen?
Genau dort, wo GitGalaxys Mitbewerber in der SAST-Kategorie einen AST oder einen kompilierenden Build benötigen und wo die CVE-Feed-Tools ein Paket-Manifest benötigen, genau dort ist die Lücke, die GitGalaxy abdecken soll — keine Behauptung, dass es das ersetzt, was sie gut machen.
Jede „strukturelle Signatur"- und „AST-frei"-Behauptung oben wird durch drei Dinge gestützt, die Sie selbst prüfen und erneut ausführen können, nicht nur auf Treu und Glauben akzeptieren müssen:
gitgalaxy/standards/language_standards.py definiert jede Regex-Regel, die die Engine verwendet, um ein Konstrukt zu erkennen — einen Funktionsanfang, eine API-Grenze, eine Sicherheitsumgehung — über die 45 Sprachen, die echte strukturelle Signaturen haben (~1.970 kompilierte Muster insgesamt). Jede dieser Regeln wird darauf getestet, was sie matchen soll, was sie explizit ausschließen soll (der Falschpositiv-Check, den die meisten regexbasierten Tools überspringen), und dass sie durch eine adversarielle Eingabe nicht zum Hängen gebracht werden kann. Siehe tests/README.md für den vollständigen Index und Epic #518 für das Audit, das es abgeschlossen hat — Dutzende echte Regex-Bugs wurden dabei gefunden und behoben, nicht nur theoretische Abdeckung.language-crucible ist ein gepinnter, getaggter Snapshot von ~120 echten Unterverzeichnissen aus großen Open-Source-Projekten — Godots C++, der Roslyn-C#-Compiler, curl, Kubernetes, Apollo 11s AGC-Flugsoftware und mehr — absichtlich getrennt und nicht kompilierbar gelassen, derselbe feindselige Zustand, in dem echte Repos sind. Jeder Pull Request, der die Parsing-Engine berührt, scannt diesen gesamten Korpus erneut und vergleicht die Ausgabe Feld für Feld mit einem eingecheckten Snapshot (tests/golden_master_audit.json); ein Diff bedeutet, dass sich die Ausgabe bei echtem Code geändert hat, und es muss erklärt werden, bevor es akzeptiert wird — kein Smoke-Test, sondern ein echter Golden-Master-Vergleich. Siehe für genau, wie das in CI verdrahtet ist, und dafür, warum der Korpus so aufgebaut ist, wie er ist.GitGalaxy soll in CI laufen, nicht nur gestarnt und vergessen werden — deshalb erfassen wir CI-/Produktionsintegration als eigenes Adoptionssignal neben der menschlichen Entdeckung, statt es als Rauschen herauszufiltern.
Links: GitHub-Sterne und Forks (kumulativ — rekonstruiert aus dem eigenen Zeitstempel jedes Sterns/Forks, nicht nur ein Snapshot in die Zukunft) zusammen mit täglich eindeutigen Klonern und Profilaufrufen. Rechts: GitLab-CI/CD-Katalog-Nutzung (eindeutige Projekte, die GitGalaxy in den letzten 30 Tagen in einer Pipeline ausführen) und GitHub-Action-Adoption (eindeutige Repos, die die Action in einem Workflow referenzieren, per Codesuche — GitGalaxy ist noch nicht im Marketplace gelistet, also ist das das beste verfügbare passive Signal). Anders als beim linken Panel legen GitHub und GitLab für diese beiden keine Historie offen — erwarten Sie, dass sich das rechte Panel Tag für Tag füllt, statt einen nachträglich aufgefüllten Trend zu zeigen.
Kombiniertes Verteilungsvolumen über PyPI, GitHub und GitLab gegenüber unseren Basis-Kontroll-Repositories — kein gleichmäßig deduplizierter Zähler. Die eindeutige Kloner-Zählung von GitHub und die eindeutige Projekt-Zählung von GitLab sind wirklich dedupliziert; PyPIs öffentliche Download-Daten haben keine Identität, gegen die dedupliziert werden kann (ohne Mirrors gemessen, was bekannte Mirror-Sync-Bots ausschließt, aber nicht CI-getriebene Installationen), daher ist diese Komponente eine rohe Download-Ereignis-Zählung. Die GitHub-/PyPI-Aufschlüsselungslinien beginnen mitten im Zeitfenster, weil die Verfolgung pro Quelle nach der Gesamt-Fetch-Verfolgung hinzugefügt wurde; die Gesamtlinie vor diesem Punkt ist über alle Quellen aggregiert.
Vollständige Methodik, einschließlich genau, was pro Quelle dedupliziert wird und was nicht: squid-protocol/squid-telemetry.
GitGalaxy führt 100 % seines Scannings und seiner Vektorisierung lokal durch — die Engine läuft vollständig air-gapped genauso wie verbunden.
Fügen Sie die Vorlage für Ihre Plattform direkt in Ihre Pipeline ein — jede einzelne führt einen GitGalaxy-Scan aus und kann den Build bei Verstößen gegen Risikoschwellen oder Malware-Signaturen fehlschlagen lassen.
Der Strukturgraph der Kern-Engine speist eine Reihe eigenständiger Werkzeuge, die darauf aufbauen. Jedes ist ein separates Modul unter gitgalaxy/tools/, das dieselbe deterministische Scan-Ausgabe verwendet, anstatt das Repository selbst erneut zu parsen.
Eine deterministische, hochpräzise Übersetzungspipeline. Sie konvertiert Legacy-COBOL in vollständig kompilierende, moderne Spring-Boot-Architekturen, bildet den Speicher exakt ab und erzeugt JPA-Entities, REST-Controller und Maven-Builds, bevor KI zum Übersetzen isolierter Geschäftslogik eingesetzt wird.
Eine analytische Suite zur Bereinigung von Mainframe-Monolithen. Sie neutralisiert sicher lexikalische Fallen der Legacy-Systeme, extrahiert toten Ausführungsspeicher, bildet topologische DAG-Ausführungsreihenfolgen ab und generiert Zero-Trust-JCL-Konfigurationen für moderne Cloud-Bereitstellungen.
Pre-Commit-Firewalls, die die physischen Dateiinhalte scannen, anstatt Manifestdateien zu vertrauen — entwickelt, um Steganografie, Byte-Level-XOR-Entschlüsselungsschleifen, Homoglyph-Typosquatting und offengelegte kryptografische Tresore zu blockieren, bevor sie in Ihre CI/CD-Pipeline gelangen. Direkt über unsere GitHub Action bereitstellen.
Ein Generator für Software-Stücklisten (SBOM), der package.json oder requirements.txt nicht blind vertraut — er lokalisiert die physischen Abhängigkeiten auf der Festplatte, prüft ihre Entropie und sprachliche Identität gegen das, was eine legitime Version ausmachen sollte, und erzeugt strenge CycloneDX-1.4-JSON-Berichte.
Ein deterministisches Mapping-Werkzeug für undokumentierte und veraltete API-Oberflächen. Es nutzt strukturelle Regex, um aktive physische Routing-Logik zu finden (Express, Spring Boot, FastAPI), und wendet Mengenlehre gegen die offizielle OpenAPI/Swagger-Dokumentation an, um Shadow-APIs (undokumentierte Routen) und Ghost-APIs (dokumentierte, aber nicht mehr implementierte Routen) zu isolieren.
Log-Analyse mit 0,07 GB/s ohne Indexanforderung. Sie streamt massive Datenbank-Dumps, um personenbezogene Daten (PII) aufzuspüren und zu maskieren (Kreditkarten, SSNs, AWS-Keys), und verwendet statische Architekturzuordnungen, um Laufzeit-Ausführungshäufigkeiten als ASCII-Zeitreihen-Histogramme zu melden.
Der AppSec-Sensor kennzeichnet KI-Agenten, die an direkte Zustandsänderungsfähigkeiten angebunden sind: ein LLM-Orchestrierungsframework (LangChain, LlamaIndex), das zusammen mit direktem Netzwerk-/Datenträger-I/O importiert wurde, kombiniert mit einer unter dem Schwellenwert liegenden Dichte defensiver Programmierung. Das ist ein Signal über die Identität der Bibliothek, keine Aussage über das Laufzeitverhalten — eine reine Regex-Engine ohne Datenflussverfolgung kann nicht beweisen, dass Code diesen Pfad tatsächlich ausführt, und beansprucht das daher auch nicht (siehe #1102 für die Prüfungen, die entfernt wurden, weil sie diese unbeweisbare Behauptung aufstellten). Darüber hinaus bewertet die Dev-Agent-Firewall Token-Masse und Sprengradius, um autonome Codierungsagenten daran zu hindern, gefährliche oder kontext-Token-zehrende Dateien zu verändern.
Wenn Sie visuelle Analysen bevorzugen, haben wir ein topologisches Dashboard entwickelt, in dem jede Datei einen Knoten darstellt, der entsprechend bestimmter Risikometriken skaliert und eingefärbt wird.
Ziehen Sie einfach Ihre generierte Datei your_repo_GPU_galaxy.json (oder ein .zip Ihres rohen Repositorys) direkt per Drag & Drop in GitGalaxy.io. Das gesamte Rendering und Scannen findet vollständig im lokalen Speicher Ihres Browsers statt.
3,2 Millionen Zeilen C++ in 11 Sekunden abbilden | OpenCV 
Copyright (c) 2026 Joe Esquibel
GitGalaxy wird unter der PolyForm-Noncommercial-Lizenz 1.0.0 vertrieben.
Wir fühlen uns der Open-Source- und akademischen Gemeinschaft zutiefst verpflichtet. Wenn Sie GitGalaxy für persönliche Projekte, akademische Forschung oder nicht-kommerzielle Entwicklung nutzen, ist die Engine zu 100 % kostenlos nutzbar.
Um die Verzögerungen durch die kommerzielle Lizenzierung in Ihrem Terminal oder in persönlichen CI/CD-Pipelines zu unterdrücken, setzen Sie einfach die folgende Umgebungsvariable:```bash export GITGALAXY_LICENSE_KEY="COMMUNITY_FREE_TIER"
### Kommerzielle & Unternehmensnutzung
Der Betrieb von GitGalaxy in Unternehmensumgebungen, proprietären Codebasen oder kommerziellen CI/CD-Pipelines erfordert eine Unternehmenslizenz. Nicht lizenzierte Unternehmens-Pipelines werden absichtlich mit Ausführungshemmnissen konfrontiert, und der Versuch, den Community-Free-Tier-Schlüssel in einer Unternehmensumgebung zu verwenden, führt zu expliziten Compliance-Warnungen in Ihren Audit-Logs.
Um einen kommerziellen Schlüssel für Ihr Unternehmen zu erwerben und saubere Compliance-Protokolle zu gewährleisten, kontaktieren Sie bitte: **[email protected]**
Die Kreuzung dieses strukturellen Graphen mit der Git-Historie bringt außerdem zwei spezifische, priorisierte Refactoring-Signale hervor: Bus-Faktor-Risiko (tragende Dateien, die fast vollständig einem einzigen Contributor gehören) und Refactoring-Hotspots (Dateien, die gleichzeitig hohe Änderungsrate, hohe Komplexität und hohe technische Schuld aufweisen — das Standard-Signal dafür, wo sich Refactoring-Aufwand tatsächlich auszahlt). Beides sind benannte Ziele auf Dateiebene, nicht nur ein Score.
| GitGalaxy | Semgrep | CodeQL | Snyk / Dependabot |
|---|
| Benötigt einen AST oder einen Build | Nein — regex-/lexikalische strukturelle Signaturen | Ja — sprachspezifisches AST-Pattern-Matching | Ja — kompiliert/extrahiert eine Code-Datenbank | Nein — liest Paket-Manifeste |
| Erkennungsbasis | Schwachstellenklasse (CWE) + physische/strukturelle Anomalie | Pattern-Matching-Regeln (SAST) | Dataflow-/Taint-Abfragen (SAST) | CVE-/Advisory-Datenbank-Lookup (SCA) |
| Funktioniert mit kaputtem/nicht kompiliertem Code | Ja — das ist das Designziel | Teilweise, abhängig von Regel/Parser | Nein — benötigt einen funktionierenden Build | Ja — liest nur das Manifest |
| Offline / Air-Gapped | Ja, vollständig lokal | OSS-Engine läuft lokal; Cloud-Plattform ist gehostet | Läuft lokal; üblicherweise über GitHub-gehostete Actions genutzt | Cloud-abhängig (Snyk); GitHub-gehostet (Dependabot) |
_galaxy_audit.json, _galaxy_master.db und _galaxy_llm.md, die der Scanner erzeugt hat, versioniert pro Engine-Release aufbewahrt. Das Korpus-Manifest, das genau festlegt, welche Repos und Commits gescannt wurden, deckt derzeit eine Teilmenge von 323 Repos des größeren dort archivierten Batches ab — im eigenen README dieses Repos klar angegeben, nicht als vollständig impliziert.Derselbe Roh-Output-Batch ist die Grundlage, aus der die obige Geschwindigkeitsbehauptung angepasst wurde — jedes Repo eingezeichnet, nicht nur das günstige Kubernetes-Beispiel:
Immer die neueste Scanner-Version — vollständige Herleitung und Methodik im Speed-Telemetrie-Abschnitt von gitgalaxy-raw-output.
| Plattform | Vorlage |
|---|
| GitHub Actions | gitgalaxy-pipeline.yml — siehe die vollständige Integrationsanleitung |
| GitLab CI | scan.yml |
| Bitbucket Pipelines | bitbucket-pipelines.yml + bitbucket_insights.py (veröffentlicht Ergebnisse als Bitbucket-Code-Insights-Anmerkungen) |
| Azure Pipelines | azure-pipelines.yml |
| Alles andere (Jenkins, CircleCI, etc.) | scan.yml — generische, über die Shell aufrufbare Vorlage |