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.
# GitGalaxy
**Intelligence structurelle à l'échelle du dépôt sans compilation.**
[Docs](https://squid-protocol.github.io/gitgalaxy/) ·
[Visualiseur](https://gitgalaxy.io/) ·
[Language Crucible](https://github.com/squid-protocol/language-crucible) ·
[Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta) ·
[Sortie brute](https://github.com/squid-protocol/gitgalaxy-raw-output)
**1 analyse · 97 signaux structurels · 50+ langages · aucune compilation · 17
catégories d'exposition au risque · 6 sorties**
## La version courte
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 :
``` text
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](#accuracy-measured) ci-dessous et détaillé dans
[le programme de validation](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md).
------------------------------------------------------------------------
## Ce qu'un scan vous apporte
Une seule commande :
``` bash
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 brief d'architecture
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](https://github.com/squid-protocol/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`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/gitgalaxy_architecture_brief.md).
### Un graphe, de nombreux consommateurs
| 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 ? |
------------------------------------------------------------------------
## Précision, mesurée
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](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) ; voici le résumé.
### Validation structurelle : GitGalaxy vs Tree-sitter vs Ctags
GitGalaxy est benchmarké contre **Tree-sitter et Universal Ctags** sur le
corpus épinglé [Language Crucible](https://github.com/squid-protocol/language-crucible)
— 24 des 45 langages disposent des trois outils, 13 de plus en ont deux, et chaque
désaccord est investigué contre le code source réel et consigné avec un verdict
(200 des 201 formes de divergence enregistrées validées). Sur ce corpus, la précision
validée des fonctions de GitGalaxy est de 100 % sur les 31 langages comparables à tree-sitter,
et il n'est jamais l'outil trouvé en tort dans un désaccord validé de classe ou
d'argument. La limite : trois cibles structurelles, un corpus fixe —
pas « analyse aussi précisément qu'un AST » en général.
### Validation des graphes : imports et appels (en cours)
Le rayon d'impact, le PageRank et les « piliers structurels » proviennent du **graphe d'import**.
Les classements au niveau des fonctions proviennent du **graphe d'appels**. Aucun des deux graphes n'est mesuré dans tous les
langages pour l'instant, et le graphique ci-dessous indique lesquels le sont :
- Les langages mesurés affichent la précision et le rappel avec n.
- Chaque langage non encore mesuré est listé par son nom.
Au 2026-09-26, sur 59 langages :
- **Le graphe d'import est mesuré dans 20.** Les arêtes du moteur sont vérifiées contre les propres
instructions d'import de chaque langage sur des dépôts réels épinglés
([`import_graph_accuracy.py`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/tools/import_graph_accuracy.py)).
- **Les noms de cibles d'appel sont mesurés dans 11**, contre tree-sitter.
- **La résolution d'appels est mesurée dans 3**, contre un analyseur de référence :
- Python, vs pyan3 : 99,8 % de précision sur 1 806 liens jugés, 51,6 % de rappel ;
- TypeScript, vs le vérificateur de types TypeScript 6.0.2 : 99,9 % de précision sur 1 520 liens jugés,
57,1 % de rappel ;
- Java, vs scip-java (la propre résolution de javac) : 92,7 % de précision sur 3 474 liens jugés,
41,0 % de rappel. Un appel à une méthode surchargée n'est lié que lorsque son nombre d'arguments sélectionne
une surcharge ([#3835](https://github.com/squid-protocol/gitgalaxy/issues/3835)).
Un lien d'appel, lorsqu'il est établi, est généralement correct, mais environ la moitié ou plus des appels restent
non liés. Ainsi le fan-in et le PageRank au niveau des fonctions sont une borne inférieure.
Les limites :
- Les graphes des 38 autres langages sont construits de la même manière mais ne sont **pas mesurés**.
- Plusieurs langages mesurés reposent sur un seul dépôt avec moins de 100 imports. Le graphique estompe
ceux-ci.
- Un `*` marque un nombre dont les désaccords attendent encore un verdict contre le code source.
Le plan pour combler ces lacunes est
[l'epic #3772](https://github.com/squid-protocol/gitgalaxy/issues/3772).
### Cohérence inter-langages : le corpus de contrôle Keyword Rosetta
Le programme plus récent pose la question inverse : **GitGalaxy mesure-t-il
une intention identique de manière identique dans chaque langage ?** Le
corpus [keyword-rosetta](https://github.com/squid-protocol/keyword-rosetta)
implante le même programme à 12 sondes dans les 50 langages supportés avec des
nombres de signaux connus exacts — ainsi toute divergence est un biais de langage mesuré, par construction.
Le graphique colore chaque écart par *cause*, non par taille : le rouge est un défaut
moteur ouvert (une règle correspondant à la mauvaise construction, ou un poids de score situé à l'intérieur
d'un comptage) ; le gris est une variation documentée que le registre a validée — le langage
ne peut pas exprimer la construction, un choix de score délibéré, ou un écho d'une autre
ligne. Réponse actuelle : en moyenne 94 % des langages se situent à ±25 % de la
médiane inter-langages par métrique contrôlée (56 métriques représentables, 54 en maintenant ≥80 %),
et **la part de défauts ouverts est de 0,0 % (1 des 2 844 cellules comparables sur 59 métriques
contrôlées)** — une seule cellule inexpliquée, `classes_found` dans le corpus
`bms` (CICS Basic Mapping Support) récemment implanté ; toutes les autres cellules hors bande sont des
variations que le registre a validées (une strate de rigueur, une construction que le
langage ne peut pas exprimer, un écho d'une autre ligne, ou un choix de score
délibéré), et non un défaut moteur ouvert. Les métriques les plus faibles sont nommées plutôt que
cachées — `cog_raw` maintient 74 % des langages dans la bande, `raw_arch_api` 78 %,
`avg_func_args` 80 % — mais leurs cellules sous-bande sont documentées, pas des défauts.
L'affirmation survit aussi à l'expansion : lorsque le corpus a implanté sa première
sonde de lentille de sécurité — un secret codé en dur identique dans chaque langage —
`credential_material` (anciennement `risk_secrets_risk` ; le nom `risk_*` reste
la colonne DB — voir [`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md)) a lu un **score uniforme
sur les 50 langages** (un identique 25.000 par colonne). Les deux exceptions de format
inerte que la lentille ignorait à l'origine, et la dépendance à la longueur mesurée de la formule, ont été
consignées et déposées le jour même
([#2978](https://github.com/squid-protocol/gitgalaxy/issues/2978),
[#2979](https://github.com/squid-protocol/gitgalaxy/issues/2979)). #2978 est
fermé : la lentille s'exécute désormais sur les cinq formats inertes
(plaintext/markdown/json/yaml/csv), avec une option de configuration `SECURITY_SCAN_INERT_FORMATS`
pour les dépôts où cela échange trop de bruit doc/config contre la
couverture, et la re-vérification du corpus de keyword-rosetta contre le correctif fusionné
se situe désormais entièrement dans la bande (l'entrée `secrets-lens-inert-formats` du registre).
Chaque déviation est enregistrée dans un registre validé, le travail est suivi par famille de causes
sous la [feuille de route du contrat](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/contract_roadmap.md), et
les classes de défauts trouvées de cette manière sont
[déposées comme issues GitGalaxy](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/findings_by_language.md).
Un corpus de contrôle prouve l'inégalité de mesure sur une intention identique ; il ne dit
rien sur la précision sur du code réel (le travail de tri-comparaison ci-dessus) — et un
biais constant par fichier préserve encore le classement *au sein* d'un langage. Le
[rapport d'incidence](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/incidence_report.md)
dimensionne chaque forme confirmée contre du code réel sous licence.
------------------------------------------------------------------------
## Échelle réelle
Exemple : **Kubernetes** — ~1,39 M de lignes réparties entre Go, YAML, JSON, Shell et Proto.
Scan de bout en bout : **50,83 secondes**. Le temps de scan suit un modèle ajusté à deux régimes
(plat ~0,11 s en dessous de ~4,3 K LOC, puis `time(s) ≈ 3.36e-05 × LOC^0.969`, R²=0,88
sur 599 dépôts) — donc une poignée de valeurs aberrantes de plus de 20 M de LOC prend encore quelques minutes, et un
scan rapide prouve le débit, pas la qualité de l'analyse ; la question de la précision est
traitée séparément ci-dessous.
Voir le [dépôt de sortie
brute](https://github.com/squid-protocol/gitgalaxy-raw-output) pour
les artefacts non édités.
------------------------------------------------------------------------
# Profil de surface structurelle : ce que GitGalaxy affirme (anciennement « exposition au risque »)
Les 13 vecteurs par fichier de GitGalaxy étaient à l'origine nommés `risk_*` et décrits comme
des **mesures d'exposition au risque**. La question que cette section laissait ouverte —
« ces signatures sont-elles empiriquement associées à des classes significatives de
risque logiciel ? » — a depuis été testée, pas seulement posée. Le
programme de validation temporal-crucible (epic
[#2982](https://github.com/squid-protocol/gitgalaxy/issues/2982), ~3 550
snapshots scannés, deux dépôts, trois familles d'étiquettes, chaque test pré-enregistré avant que les données ne soient examinées) a mené cette expérience jusqu'à
épuisement, et le résultat honnête a conduit à un renommage
([#2991](https://github.com/squid-protocol/gitgalaxy/issues/2991)) : les
vecteurs sont maintenant appelés le **Profil de surface structurelle**. `risk_*` reste
le nom de colonne DB / clé JSON pour compatibilité (voir
[`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) pour la table complète des noms et la note de dépréciation).
**Ce que le registre a trouvé, reformulé honnêtement :**
- **Risque permanent par fichier, falsifié.** L'hypothèse fondatrice — que le niveau `risk_*` d'un
fichier, ou son changement après un correctif, suit la probabilité de défaut —
ne tient pas. Le delta structurel médian après un correctif de sécurité
était de +0,000 (équivalence confirmée proche de zéro sur un second dépôt
indépendant, pas seulement non significatif) ; l'exposition structurelle sommée se classait
*dernière* de six caractéristiques pour prédire les fichiers touchés par un correctif ; un vecteur structurel multivarié à 26 signaux
obtenait un score au niveau du hasard (AUC 0,479) sous une séparation
temporelle, en dessous d'un simple comptage de lignes (0,531). Le registre complet se trouve dans
`docs/HYPOTHESES.md` de temporal-crucible et est lié depuis
[#2982](https://github.com/squid-protocol/gitgalaxy/issues/2982).
- **Ce que les vecteurs ont réellement validé :** décrire **l'activité et
le contenu**, pas la probabilité de défaut. Le composite en forme de correctif suit de manière fiable
un gradient correctif de sécurité → correctif ordinaire → contrôle → revert ; les deltas
correspondent à de vrais événements de code (code de garde ajouté, threading introduit, marqueurs de
dette dilués). C'est la radiographie que ce document nomme désormais
précisément — voir [`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) vecteur par vecteur.
- **Signal au niveau système / historique, reformulé comme la véritable découverte
prédictive.** Deux caractéristiques *ont* survécu à la validation : la **récidive** (le fichier
qui a eu le dernier correctif reçoit le suivant — le résultat le plus répliqué du programme, p<1e-4 sur les deux dépôts) et l'**entropie de changement /
Hassan HCM**, validée hors sélection sur de nouvelles étiquettes de bugs (AUC 0,868 vs
0,830 pour un comptage de lignes). Les deux sont des métriques d'**historique**, pas des métriques de
contenu structurel — et les deux sont actuellement mises à zéro dans chaque scan
(`GITGALAXY_DISABLE_GIT_HISTORY`, suivi dans
[temporal-crucible#29](https://github.com/squid-protocol/temporal-crucible/issues/29)).
C'est la graine d'une **couche prédictive** distincte et honnêtement nommée — les
vecteurs `hist_stability`/`hist_churn` sont nommés pour marquer explicitement ce statut —
conditionnée à la livraison du mode avec historique activé puis à la validation du
contrat de promotion du lift de défauts de
[#2987](https://github.com/squid-protocol/gitgalaxy/issues/2987).
Une lecture élevée du Profil de surface structurelle signifie :
> **Cet emplacement présente davantage d'un motif structurel/de contenu donné,
> par rapport au reste du dépôt.**
Cela ne signifie pas :
> « Ce code est plus susceptible de contenir un défaut » — la version par fichier de
> cette affirmation a été testée et ne tient pas.
Les signatures sous-jacentes couvrent des motifs impliquant des domaines tels que :
- secrets
- surface d'injection
- opérations non sûres/mémoire
- exécution dynamique
- E/S
- concurrence
- mutation d'état
- réflexion
- API
- dépendances
- entropie
- autres caractéristiques structurelles/de sécurité
Voir [`docs/vectors.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) pour la table de renommage par vecteur,
les preuves, et les usages appropriés/inappropriés, et
`docs/HYPOTHESES.md` de
[temporal-crucible](https://github.com/squid-protocol/temporal-crucible) pour le registre de validation complet que cette section résume.
------------------------------------------------------------------------
# Des preuves, pas seulement des affirmations
### Language Crucible
Un corpus épinglé de code source réel incluant des projets tels que Godot, Roslyn,
curl, Kubernetes et le logiciel de vol d'Apollo 11.
[Language Crucible](https://github.com/squid-protocol/language-crucible)
### Régression golden-master
Le code source réel est re-scanné et comparé à la sortie attendue versionnée afin que
les changements de parseur aient 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é manuellement.
### Tri-comparaison
Le même corpus est analysé contre GitGalaxy, Tree-sitter et Ctags là où
la couverture existe — 24 des 45 langages disposent des trois outils, 200 des 201 divergences
enregistrées validées. Sur le corpus épinglé, GitGalaxy n'est jamais l'outil
trouvé en tort dans un désaccord validé de précision de fonction, de classe ou d'argument,
et égale le rappel de fonctions de tree-sitter partout sauf une définition shell imbriquée
qu'il ignore par conception. Voir
[la méthodologie](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_README.md) et
[le programme de validation](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) pour le tableau complet et ses
limites.
### Corpus de contrôle Keyword Rosetta
Le même programme à 12 sondes implanté dans les 50 langages supportés avec des
nombres de signaux connus exacts, mesurant la cohérence inter-langages de chaque métrique —
avec un registre de déviations validé et les défauts moteur résultants
[déposés comme issues](https://github.com/squid-protocol/keyword-rosetta/blob/main/docs/findings_by_language.md).
[Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta)
### Sortie brute de dépôt
La sortie GitGalaxy non éditée est conservée pour des centaines de dépôts
sélectionnés indépendamment.
[Sortie brute](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 sur les 45 langages à signature
structurelle — correspondances positives, exclusions explicites, et entrées
adversariales/ReDoS. Voir [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) pour la répartition, 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 étayés où cette extraction surpasse une lecture AST.
### Temporal Crucible (validation historique)
Savoir si le Profil de surface structurelle correspond à de vrais événements de sécurité et de
maintenance au fil de l'historique Git n'est plus une question ouverte — cela a été
testé. Le programme [Temporal Crucible](https://github.com/squid-protocol/temporal-crucible)
a scanné ~3 550 snapshots de dépôts sur deux dépôts (curl, nDPI)
et trois familles d'étiquettes (commits de correction/introduction de CVE, étiquettes de bugs, familles CWE),
avec chaque test confirmatoire pré-enregistré avant que les données ne soient examinées. Ce
qu'il a trouvé, dit honnêtement :
- **Le risque structurel permanent par fichier ne prédit pas les défauts** — il se réduit
à un comptage de lignes, un nul confirmé par test d'équivalence sur un second
dépôt indépendant (pas simplement « non significatif »).
- **Deux métriques d'*historique* prédisent** : la récidive (le fichier qui a eu le dernier
correctif reçoit le suivant — p<1e-4 sur les deux dépôts, le résultat le plus répliqué
du programme) et l'entropie de changement (Hassan HCM), validée
hors sélection sur de nouvelles étiquettes de bugs.
- **La structure décrit ; l'historique prédit.** Plus de prédictions sont mortes dans le
registre qu'elles n'y ont survécu — c'est la discipline de pré-enregistrement qui fonctionne,
pas une déception.
Le registre complet est public et reproductible : le
[registre d'hypothèses](https://github.com/squid-protocol/temporal-crucible/blob/main/docs/HYPOTHESES.md)
pré-enregistré et un [index prédicteur × résultat](https://github.com/squid-protocol/temporal-crucible/blob/main/docs/EXPERIMENTS.md)
de tout ce que le programme a tenté de corréler. Conception et méthode :
[le programme de validation](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)
------------------------------------------------------------------------
# Ce que GitGalaxy est --- et n'est pas
### GitGalaxy est
- de l'intelligence structurelle à l'échelle du dépôt
- une analyse de code source agnostique au langage
- une représentation structurelle commune à travers du code hétérogène
- une priorisation de l'exposition au risque
- une cartographie d'architecture
- une génération de preuves native pour la CI
- utile sur des dépôts cassés/non compilés
- conçu pour un fonctionnement local/hors ligne
### GitGalaxy n'est pas
- un remplacement de l'analyse approfondie de flux de données de CodeQL
- un remplacement de l'écosystème de règles de Semgrep
- un remplacement des bases de données de 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'intégralité de ce dépôt, structurellement, et où faut-il porter son attention 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 de données/contrôle une analyse plus poussée peut-elle établir ? |
| Outils SCA/CVE | Cette dépendance/version est-elle associée à un avis connu ? |
------------------------------------------------------------------------
# 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 de bus, les points
chauds de refactoring, la propriété des fichiers et l'activité temporelle. La
direction de recherche consiste à étendre cela d'un **historique comme signal
contextuel** à un **historique comme source de validation externe pour le
modèle d'exposition** — la conception de l'expérience se trouve dans
[le programme de validation](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md#the-next-validation-risk-over-git-history).
------------------------------------------------------------------------
# Confidentialité et déploiement
GitGalaxy est conçu pour un fonctionnement local et en environnement isolé.
- Le code source n'est pas envoyé à un service cloud GitGalaxy.
- L'analyse et la vectorisation s'effectuent 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 dans le navigateur fonctionne sur des données fournies localement.
------------------------------------------------------------------------
# Installation
``` bash
pip install gitgalaxy # zero install dependencies
pip install "gitgalaxy[full]" # + tiktoken, xgboost, pandas, numpy, pyyaml
```
Consultez la [documentation](https://squid-protocol.github.io/gitgalaxy/) pour
les commandes et la configuration actuelles.
### Mode sans dépendance
Un simple `pip install gitgalaxy` n'installe rien d'autre, pour les environnements où
chaque paquet tiers est une question de chaîne d'approvisionnement. Les analyses s'exécutent toujours : chaque
signal structurel, arête de dépendance, comptage de degré entrant/sortant, PageRank / rayon d'impact,
intermédiarité, proximité, longueur moyenne des chemins, modularité, densité cyclique, points
d'articulation et assortativité sont mesurés exactement comme en pleine
précision (ceux-ci sont calculés nativement). Ce qui nécessite les moteurs optionnels, c'est
la masse de tokens et le coût de lecture (`tiktoken`), la classification ML des menaces
(`xgboost`/`pandas`/`numpy`) et l'analyse de configuration YAML/OpenAPI
(`pyyaml`). Une métrique qui n'a pas été calculée est signalée comme absente (`n/a` /
NULL), jamais comme un zéro. Chaque sortie indique quand une analyse s'est exécutée dans ce mode, et
[`docs/zero_dependency_mode.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/zero_dependency_mode.md) liste, champ par
champ, ce qui est identique et ce qui est indisponible.
### CI/CD
Des modèles sont fournis pour GitHub Actions, GitLab CI, Bitbucket Pipelines,
Azure Pipelines, et les environnements CI génériques invocables en shell. Voir
[`templates/`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/templates) et le [guide d'intégration
CI](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/github-action-readme.md).
------------------------------------------------------------------------
# Explorer les preuves
| Ressource | Ce qu'elle contient |
|---|---|
| [Documentation](https://squid-protocol.github.io/gitgalaxy/) | Architecture, affirmations et méthodologie |
| [Le programme de validation](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) | Le récit complet de la preuve : thèse, benchmarks, échelle de validité, prochaines expériences |
| [Référence des vecteurs](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vectors.md) | Les 13 vecteurs par fichier : noms, signification, preuves, et la note de dépréciation `risk_*` |
| [Faits sur les formules des vecteurs](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/vector_formulas.md) | Audit mécanique des formules par calculateur (entrées, arithmétique, constantes) |
| [Language Crucible](https://github.com/squid-protocol/language-crucible) | Benchmark inter-langages et corpus de référence |
| [Keyword Rosetta](https://github.com/squid-protocol/keyword-rosetta) | Corpus de contrôle planté en 50 langues et rapports de biais |
| [Sortie brute](https://github.com/squid-protocol/gitgalaxy-raw-output) | Analyses non éditées de dépôts réels |
| [Exemples COBOL → Java](https://github.com/squid-protocol/cobol_to_java_examples) | 10 dépôts COBOL auto-traduits en architectures Spring Boot compilables (`mvn clean compile` fonctionne immédiatement) |
| [Analyses de population](https://github.com/squid-protocol/gitgalaxy-population-analyses) | Analyses statistiques sur la population de scans en sortie brute : regroupement d'archétypes, distributions de risque, études de classification des menaces |
| [Musée du code](https://squid-protocol.github.io/gitgalaxy/museum-of-code/) | Démontages architecturaux complets de bases de code réelles (Apollo 11, benchmarks IBM CICS) |
| [Télémétrie de distribution](https://github.com/squid-protocol/squid-telemetry) | Métriques de téléchargement publiques sur GitHub/GitLab/[PyPI](https://pypi.org/project/gitgalaxy/), régénérées quotidiennement |
| [`tests/README.md`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/tests/README.md) | Méthodologie de régression et de golden-master |
| [`tri_comparison_ledger.json`](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/self_scan/tri_comparison_ledger.json) | Registre de validation désaccord par désaccord |
---
[Read more](https://gitlab.com/squid-protocol1/gitgalaxy)