GitGalaxy

Intelligence structurelle à l'échelle du dépôt, sans compilation.

Docs · Visualiseur · Language Crucible · Sortie brute

1 analyse · 97 signaux structurels · 50+ langages · aucune compilation · 19 catégories d'exposition au risque · 6 sorties

La version courte

GitGalaxy construit un graphe structurel indépendant du langage d'un dépôt entier directement à partir du texte source.

Il est conçu pour les dépôts polyglottes, partiellement cassés, hérités, fortement dépendants de bibliothèques tierces, ou autrement difficiles à analyser via un flux de travail basé sur la compilation.

Au lieu d'exiger une compilation réussie et un analyseur/chaîne d'outils séparé pour chaque langage, GitGalaxy extrait un vocabulaire commun de signatures structurelles---fonctions, classes, arguments, flux de contrôle, mutation d'état, E/S, API, dépendances et autres signaux---et normalise ces observations en un modèle de dépôt unique.

Le même graphe peut ensuite alimenter :

l'analyse d'architecture
la priorisation de l'exposition au risque
l'analyse des dépendances/SBOM
l'analyse de refactorisation et de propriété
l'analyse de code hérité
le contexte de codebase orienté IA
les flux de travail CI/CD
l'analyse de risque historique

Thèse centrale : l'analyse complète du langage n'est pas toujours nécessaire pour récupérer des informations structurelles très utiles à l'échelle du dépôt.

Le problème

Les grands dépôts contiennent régulièrement :``` text Go + C++ + Python + Java + Bash + YAML

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

Les outils de développement traditionnels peuvent être excellents dans leur domaine d'application
tout en laissant le dépôt fragmenté entre des représentations spécifiques à chaque langage.

GitGalaxy fait un choix différent :``` 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

L'objectif n'est pas de reproduire chaque détail syntaxique de chaque langage.

L'objectif est de récupérer l'information structurelle dont l'intelligence en aval des dépôts a réellement besoin.

Un graphe, de nombreux consommateurs

La sortie centrale de GitGalaxy est une représentation structurelle déterministe du dépôt.

Consommateur Question

Architecture De quoi ce dépôt est-il fait ?

Analyse structurelle Où se trouvent les fonctions, les classes, les API, les dépendances et les structures de contrôle ?

Exposition au risque Où se concentrent les motifs de risque potentiellement importants ?

Refactorisation Quels fichiers sont complexes, très modifiés ou porteurs de charge ?

Chaîne d'approvisionnement Quelles dépendances existent physiquement sur le disque ?

Contexte IA Quelle architecture et quelles relations un agent devrait-il connaître ?

Migration héritée Où se trouvent les unités structurelles à transformer ?

Analyse historique Comment l'exposition mesurée évolue-t-elle à mesure que le dépôt évolue ?

Pipeline d'architecture GitGalaxy

La thèse de l'extraction structurelle

GitGalaxy ne commence délibérément pas par construire un AST complet pour chaque langage.

Il utilise environ 97 catégories de signaux structurels pour identifier des éléments tels que :

les limites de fonctions et de méthodes
les classes et les déclarations
les arguments
les branches et le flux de contrôle
la mutation d'état
les E/S
les API et les routes
les imports et les dépendances
les opérations non sûres
la réflexion et l'exécution dynamique
la concurrence
les fermetures (closures)
les globales
l'entropie et les anomalies de fichiers physiques

Cela crée une hypothèse spécifique et testable :

Pour une intelligence à l'échelle du dépôt, une extraction structurelle ciblée peut récupérer les entités requises pour une intelligence de code utile sans nécessiter un analyseur de langage complet pour chaque fichier.

Cette hypothèse est testée empiriquement.

Validation structurelle : GitGalaxy vs Tree-sitter vs Ctags

C'est actuellement l'un des programmes de validation les plus importants du projet.

GitGalaxy est évalué contre Tree-sitter et Universal Ctags sur le même corpus Language Crucible.

Les premières cibles structurelles sont :

les fonctions
les classes
les arguments

Le benchmark n'est délibérément pas traité comme un concours de popularité entre trois outils.

Lorsque les outils divergent :

le désaccord est enregistré ;
la source est inspectée ;
le comportement de chaque outil est étudié ;
GitGalaxy est corrigé lorsque GitGalaxy a tort ;
le code comparateur/adaptateur est corrigé lorsque le comparateur a tort ;
les véritables limites des outils sont documentées ;
le résultat est re-mesuré.

24 des 45 langages voient les trois outils comparés, 16 de plus en voient deux, et 5 langages propres à GitGalaxy (abap, dockerfile, jcl, livecode, yaml) reçoivent une vérification manuelle examinée à la main au lieu d'un accord inter-outils. Sur les 180 formes d'écart journalisées jusqu'à présent, 87 sont validées (48 %) — lues, étudiées et enregistrées avec un verdict, pas seulement comptées.

L'objectif est de terminer l'audit, de combler les défauts restants de GitGalaxy, d'établir une vérité terrain indépendante là où c'est nécessaire, puis de publier les mesures finales de précision/rappel. Voir le document de méthodologie de tri-comparaison pour comprendre comment fonctionnent la mise en correspondance, le cycle de vie du registre et l'application en CI.

Tri-comparaison

Voir :

tests/tools/tri_comparison_chart.py
docs/self_scan/tri_comparison_ledger.json — l'enregistrement complet et validé par forme
docs/self_scan/tri_comparison_points_of_interest.md — le même registre, rendu et classé par force du signal
docs/self_scan/how_to_investigate_a_discrepancy.md
docs/self_scan/manual_verification.json

Ce que le benchmark demande réellement

Pas :

« GitGalaxy est-il un meilleur analyseur que Tree-sitter ? »

Mais :

« Pour les entités structurelles dont GitGalaxy a besoin pour construire son graphe de dépôt, avec quelle précision une extraction structurelle ciblée peut-elle les récupérer par rapport aux systèmes d'analyse et d'indexation établis ? »

C'est l'affirmation plus étroite que l'expérience peut étayer.

Langages sans couverture de comparateur adaptée

Certains langages ne disposent actuellement pas d'un chemin de comparaison indépendant adapté avec Tree-sitter/Ctags.

Ceux-ci sont conservés dans une catégorie probante distincte et utilisent une vérification manuelle engagée plutôt que de prétendre qu'un accord inter-outils existe.

Cela inclut actuellement des langages tels que :

ABAP
Dockerfile
JCL
LiveCode
YAML

Lorsque c'est réalisable, l'étape suivante consiste à ajouter des comparateurs lexicaux, basés sur la grammaire ou spécifiques au domaine indépendants. Lorsqu'aucun comparateur indépendant crédible n'existe, la vérité terrain vérifiée par un humain reste la catégorie appropriée.

La validation est une échelle

Les preuves de GitGalaxy sont organisées autour de questions de plus en plus solides.

1. Validité structurelle

GitGalaxy identifie-t-il correctement les structures de code ?

Tree-sitter + Ctags + désaccords étudiés indépendamment. Voir « Validation structurelle » ci-dessus.

2. Validité de régression

L'implémentation reste-t-elle stable sur du code réel ?

Tests golden-master contre Language Crucible.

3. Validité d'échelle

Cela fonctionne-t-il sur de vrais dépôts ?

Sortie d'analyse brute non éditée provenant de centaines de dépôts.

4. Validité du modèle

Les signatures structurelles correspondent-elles aux catégories d'exposition qu'elles sont censées représenter ?

Analyse statistique contre des résultats observables de manière indépendante — pas seulement contre les propres équations de GitGalaxy.

5. Validité temporelle

L'exposition se comporte-t-elle de manière sensée à mesure que le logiciel change ?

Analyse de l'historique Git comparant les états du dépôt avant et après de vrais changements.

6. Validité externe

Les changements d'exposition correspondent-ils à des résultats de sécurité ou de maintenance documentés indépendamment ?

Travaux futurs : correctifs de sécurité, régressions, avis, défauts et autres ensembles de données d'événements externes.

Cette distinction importe : un score peut être cohérent en interne sans être nécessairement significatif en externe.

Exposition au risque : ce que GitGalaxy prétend

GitGalaxy produit des mesures d'exposition au risque, pas des verdicts de vulnérabilité.

Une exposition élevée signifie :

Cet emplacement mérite l'attention par rapport au reste du dépôt.

Cela ne signifie pas :

« Ce code est définitivement vulnérable. »

Le système actuel produit des catégories d'exposition normalisées à travers le dépôt et fait remonter l'information des entités structurelles à travers les fichiers, les dossiers et les vues au niveau du dépôt.

Les signatures sous-jacentes couvrent des motifs impliquant des domaines tels que :

les secrets
la surface d'injection
les opérations non sûres/mémoire
l'exécution dynamique
les E/S
la concurrence
la mutation d'état
la réflexion
les API
les dépendances
l'entropie
d'autres caractéristiques structurelles/de sécurité

La question de recherche importante est de savoir si ces signatures sont empiriquement associées à des classes significatives de risque logiciel, plutôt que simplement corrélées à un score que GitGalaxy lui-même a mathématiquement construit.

Cette distinction pilote la phase suivante.

La prochaine validation : le risque sur l'historique Git

L'expérience centrale est :

> **Les commits identifiés indépendamment comme correctifs de sécurité
> réduisent-ils généralement l'exposition GitGalaxy correspondante ?**

Les contrôles négatifs sont tout aussi importants :

> Les commits de développement ordinaires présentent-ils le même comportement ?

Enfin :

> Les régressions de sécurité augmentent-elles l'exposition ?

Le harnais prévu préservera le SHA du commit, l'état parent, les
fichiers/fonctions modifiés, l'exposition avant/après, les deltas
d'exposition, les changements structurels et la classification des
événements.

Cela teste :

**structure → exposition → évolution logicielle réelle**

plutôt que de simplement tester les mathématiques internes du modèle
d'exposition.

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

# Des preuves, pas seulement des affirmations

### Creuset linguistique

Un corpus figé de code source réel incluant des projets tels que Godot,
Roslyn, curl, Kubernetes et le logiciel de vol Apollo 11.

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

### Régression golden-master

Le code source réel est ré-analysé et comparé à la sortie attendue
vérifiée afin que les changements de parseur produisent un diff
observable. Régénéré avec
[`tests/tools/update_golden_master.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/update_golden_master.py),
jamais édité à la main.

### Tri-comparaison

Le même corpus est analysé avec GitGalaxy, Tree-sitter et Ctags là où
la couverture existe — 24 des 45 langages disposent des trois outils, 87 des
180 divergences enregistrées validées à ce jour. Voir
[la méthodologie](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) et la
[« section validation structurelle ci-dessus »](#structural-validation-gitgalaxy-vs-tree-sitter-vs-ctags)
pour le tableau complet.

### Sortie brute des dépôts

La sortie GitGalaxy non éditée est conservée pour des centaines de
dépôts sélectionnés indépendamment.

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

### Suite de régression

**7 043 tests** dans la suite par défaut (`python -m pytest tests/`), dont
**6 165** sont des tests par signature couvrant les 45 langages à signature
structurelle — correspondances positives, exclusions explicites et entrées
adverses/ReDoS. Voir [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) pour le détail, et
[`docs/why_gitgalaxy_beats_ast_here.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/why_gitgalaxy_beats_ast_here.md)
pour des cas spécifiques et documentés où cette extraction surpasse une
lecture AST.

### Validation historique

La prochaine couche de recherche testera si les mesures d'exposition
correspondent à des événements réels de sécurité et de maintenance sur
l'historique Git.

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

# Ce que GitGalaxy est — et n'est pas

### GitGalaxy est

-   une intelligence structurelle à l'échelle du dépôt
-   une analyse de code source indépendante du langage
-   une représentation structurelle commune à travers du code hétérogène
-   une priorisation de l'exposition au risque
-   une cartographie de l'architecture
-   une génération de preuves native CI
-   utile sur les dépôts cassés/non compilés
-   conçu pour un fonctionnement local/hors ligne

### GitGalaxy n'est pas

-   un remplaçant de l'analyse approfondie de flux de données de CodeQL
-   un remplaçant de l'écosystème de règles de Semgrep
-   un remplaçant des bases de données CVE de dépendances
-   une preuve d'exploitabilité
-   un analyseur d'exécution
-   un parseur de langage complet
-   une garantie qu'une exposition élevée est une vulnérabilité

  -----------------------------------------------------------------------
  Outil                               Question principale
  ----------------------------------- -----------------------------------
  **GitGalaxy**                       À quoi ressemble l'ensemble de ce
                                      dépôt, structurellement, et où
                                      l'attention doit-elle se porter en
                                      premier ?

  Tree-sitter                         Quelle structure syntaxique ce
                                      code source contient-il ?

  Ctags                               Où se trouvent les entités de code
                                      navigables ?

  Semgrep                             Ce code correspond-il à un motif
                                      spécifié ?

  CodeQL                              Quelles relations données/contrôle
                                      une analyse plus approfondie
                                      peut-elle établir ?

  Outils SCA/CVE                      Cette dépendance/version est-elle
                                      associée à un avis connu ?
  -----------------------------------------------------------------------

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

# Échelle réelle

GitGalaxy est destiné aux dépôts trop hétérogènes ou cassés pour un
flux de travail traditionnel monolangage basé sur la compilation.

Exemple : **Kubernetes**

\~1,39 M de lignes en Go, YAML, JSON, Shell et Proto.

Analyse de bout en bout : **50,83 secondes**.

![Vitesse d'analyse
GitGalaxy](https://assets.kitploit.com/production/public/readmes/7003/596585161af8eeb861f49e2968927d69059333f145c0e2b6e9bb0cb9c9d7bc36.png)

Voir le [dépôt de sortie
brute](https://github.com/squid-protocol/gitgalaxy-raw-output) pour les
artefacts non édités.

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

# Sorties

  Sortie                         Objectif
  ------------------------------ ----------------------------------------
  **SARIF**                      Intégration CI/tableaux de bord sécurité
  **SBOM CycloneDX**             Inventaire/conformité des dépendances
  **SQLite**                     Graphe de connaissances du dépôt
                                 interrogeable
  **Brief d'architecture LLM**   Contexte compact orienté machine/agent
  **Données d'audit JSON**       Flux de travail forensiques/automatisés
  **Données de visualisation 3D** Topologie interactive du dépôt

Ce sont différentes vues de la même analyse déterministe, plutôt que des
moteurs d'analyse indépendants.

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

# Historique Git et architecture

GitGalaxy intègre déjà l'historique Git dans des signaux tels que :

-   le churn
-   la concentration des contributeurs
-   l'exposition au facteur bus
-   les points chauds de refactorisation
-   la propriété des fichiers
-   l'activité temporelle

La direction de recherche consiste à étendre cela de **l'historique comme
signal contextuel** à **l'historique comme source de validation externe
pour le modèle d'exposition**.

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

# Confidentialité et déploiement

GitGalaxy est conçu pour un fonctionnement local et en environnement
isolé (air-gapped).

-   Le code source n'est pas envoyé à un service cloud GitGalaxy.
-   L'analyse et la vectorisation se déroulent localement.
-   Le scanner n'a aucune exigence réseau à l'exécution.
-   L'exécution CI/CD peut rester dans l'environnement de l'utilisateur.
-   Le visualiseur navigateur fonctionne sur des données fournies
    localement.

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

# Installation``` bash
pip install gitgalaxy

Voir la documentation pour les commandes et la configuration actuelles.

CI/CD

Des modèles sont fournis pour :

GitHub Actions
GitLab CI
Bitbucket Pipelines
Azure Pipelines
les environnements CI génériques invocables par script shell

Voir templates/ et le guide d'intégration CI.

Explorer les preuves

Ressource Contenu

Documentation Architecture, affirmations et méthodologie

Language Crucible Benchmark et corpus de référence multilingues

Sortie brute Analyses non éditées de dépôts réels

tests/README.md Méthodologie de régression et de maître de référence

tri_comparison_ledger.json Registre de validation désaccord par désaccord

manual_verification.json Cas examinés où la couverture du comparateur est indisponible

how_to_investigate_a_discrepancy.md Méthodologie de désaccord avec le comparateur

Visualiseur Visualisation de dépôt locale basée sur le navigateur

Direction de recherche actuelle

GitGalaxy progresse à travers une séquence de questions de difficulté croissante :

Pouvons-nous analyser du code source hétérogène sans le compiler ?

↓

Pouvons-nous récupérer de manière fiable les entités structurelles nécessaires pour le comprendre ?

↓

Ces mesures structurelles correspondent-elles à une exposition réelle au risque ?

↓

L'exposition mesurée se comporte-t-elle correctement à mesure que le logiciel réel évolue ?

La validation Tree-sitter/Ctags est actuellement environ à moitié terminée. La priorité immédiate est de terminer cet audit avant de transformer les mesures préliminaires en affirmations plus solides.

La prochaine expérience majeure est :

Historique Git → événements de modification/correction identifiés indépendamment → analyses GitGalaxy avant/après → deltas d'exposition → analyse statistique.

C'est là que GitGalaxy peut commencer à tester non seulement s'il voit la structure, mais aussi si son modèle structurel suit les changements significatifs dans le logiciel réel.

Licence

GitGalaxy est distribué sous la Licence Noncommerciale PolyForm 1.0.0.

Voir la licence du dépôt pour les conditions complètes.

Lire plus

gitgalaxy — Mis à jour !

Catégories