squid-protocol1/gitgalaxy
Moteur heuristique à base de graphe de connaissances sans AST pour une intelligence approfondie des dépôts et une analyse de sécurité zero-trust. S'intègre en tant que composant GitLab CI/CD, bloque le code hostile et exporte la télémétrie SARIF vers le tableau de bord de sécurité GitLab.
Intelligence structurelle à l'échelle du dépôt sans compilation.
Docs · Visualiseur · Language Crucible · Keyword Rosetta · Sortie brute
1 analyse · 97 signaux structurels · 50+ langages · aucune compilation · 17 catégories d'exposition au risque · 6 sorties
GitGalaxy construit un graphe structurel agnostique au langage d'un dépôt entier directement à partir du texte source — sans build, sans chaîne d'outils par langage.
Il est conçu pour les dépôts polyglottes, partiellement cassés, legacy, surchargés de dépendances externes, ou autrement difficiles à analyser via un workflow orienté build :
Go + C++ + Python + Java + Bash + YAML
+ generated code + vendored code + legacy code
+ half-migrated modules + broken dependencies
Au lieu d'un analyseur distinct par 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 les normalise en un modèle de dépôt déterministe unique qui alimente l'analyse d'architecture, la priorisation de l'exposition aux risques, la génération de SBOM, l'analyse de refactoring et de propriété, le contexte de base de code orienté IA, et les portes CI/CD.
Thèse centrale : l'analyse complète d'un langage n'est pas toujours nécessaire pour récupérer des informations structurelles hautement utiles à l'échelle d'un dépôt.
Comment cette thèse est testée — face à Tree-sitter et Ctags, face à un corpus de contrôle implanté, et ensuite face à l'historique Git — est résumé dans Précision, mesurée ci-dessous et détaillé dans le programme de validation.
Une seule commande :
pip install gitgalaxy
galaxyscope path/to/repo
Six vues coordonnées du même scan déterministe :
| Sortie | Objectif |
|---|---|
| Brief d'architecture LLM | Contexte compact orienté machine/agent (ci-dessous) |
| SARIF | Intégration CI/tableau de bord de sécurité |
| CycloneDX SBOM | Inventaire des dépendances/conformité |
| SQLite | Graphe de connaissances du dépôt interrogeable |
| Données d'audit JSON | Flux de travail forensiques/automatisés |
| Données de visualisation 3D | Topologie interactive du dépôt |
Le rapport phare est un brief Markdown unique conçu pour transmettre à un ingénieur — ou à un agent IA — un modèle mental opérationnel d'un dépôt qu'il n'a jamais vu. C'est un paquet autonome : les équations de risque sont imprimées dans le rapport lui-même, et un prompt d'interprétation intégré permet à n'importe quel LLM de le narrer sans halluciner sur la signification des chiffres. Les sections couvrent l'état macro et la composition linguistique, la topologie du réseau (modularité, points d'articulation, densité cyclique), les points d'étranglement des dépendances, les fonctions et fichiers les plus lourds, les signatures structurelles par fichier avec le rayon d'impact PageRank, les listes de cibles de risque ciblées et cumulatives, les audits de chaîne d'approvisionnement, et les cibles de refactoring classées par volatilité et centralisation de la paternité — plus une liste détaillée de chaque fichier qu'il a refusé de scanner, et pourquoi.
Deux exemples, scannés le 2026-08-31 avec le moteur actuel. Les deux dépôts
sont publics — clonez l'un ou l'autre et exécutez galaxyscope --llm-only <path> pour reproduire
le brief complet :
curl — 4 250 artefacts, 696 scannés, 112 653 LOC réparties entre C, Perl, Python,
Shell, M4 et Makefile. Le brief classe src/tool_setup.h comme le principal
pilier structurel (80 connexions entrantes) et place une fonction Perl —
APPEND_imap dans tests/ftpserver.pl, Impact 2135, 1 672 LOC — en tête de
la liste des fonctions à l'échelle du dépôt, dans le même classement que le code C. Ce
graphe multi-langages est le produit : un ensemble de signaux comparables à travers chaque
langage du dépôt. La réserve honnête dans le même brief : seulement 16,4 % des
artefacts ont été scannés — le filtre d'ingestion écarte agressivement les binaires, le code généré
et les données de test, et la §5 du brief détaille chaque exclusion par
extension et par raison.
cics-genapp (l'échantillon CICS COBOL/DB2 d'IBM) — 92,1 % scanné : 44 programmes
COBOL, 29 jobs JCL. La liste cumulative des surfaces structurelles en tête est
base/src/lgupdb01.cbl (surface de mutation ~100 %, charge de complexité 92 %), et le
paragraphe le plus lourd du dépôt est UPDATE-POLICY-DB2-INFO — la logique de verrouillage de ligne
SELECT FOR UPDATE, qui est exactement là où un mainteneur de ce programme
voudrait regarder en premier. Le même brief montre aussi clairement une limitation : sur une
architecture plate sans véritable graphe d'import, la liste des « piliers structurels »
dégénère en fichiers à zéro connexion, et le rapport indique de vérifier les
compteurs de connexions avant de lui faire confiance.
Des centaines de briefs non édités pour des dépôts sélectionnés indépendamment sont
committés sur
gitgalaxy-raw-output ;
le brief d'auto-scan toujours à jour de ce dépôt lui-même se trouve à
docs/gitgalaxy_architecture_brief.md.
| Consommateur | Question |
|---|---|
| Architecture | De quoi ce dépôt est-il fait ? |
| Analyse structurelle | Où sont les fonctions, classes, API, dépendances et structures de contrôle ? |
| Profil de surface structurelle (anciennement exposition au risque) | Où un motif structurel/de contenu donné est-il concentré ? |
| Refactoring | Quels fichiers sont complexes, à fort churn 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 legacy | Où sont les unités structurelles à transformer ? |
| Analyse historique | Comment l'exposition mesurée évolue-t-elle à mesure que le dépôt évolue ? |
Deux programmes de mesure permanents étayent les affirmations ci-dessus, et un troisième, pour les graphes de dépendances et d'appels, est en cours. Le récit complet — méthodologie, verdicts, limites et ce qui vient ensuite — se trouve dans le programme de validation ; voici le résumé.