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.
1 analyse · 97 signaux structurels · 50+ langages · 0 besoin de compilation
19 scores d'exposition au risque · 6 rapports finaux · 0 dépendance · pip install gitgalaxy
GitGalaxy existe pour un problème récurrent : comprendre une grande base de code réelle et multilingue qui ne compile pas proprement — l'état dans lequel se trouvent réellement la plupart des dépôts de production, et non l'entrée propre et monolingue que suppose la plupart des outils d'analyse statique.
time(s) ≈ 3.36e-05 × LOC^0.969 au-delà (R²=0,88, quasi linéaire, sans dégradation sur les gros volumes d'entrée) — voir Proof, Not Just Claims pour le graphique et la dérivation, et pas seulement ce chiffre arrondi.Ce n'est pas un scanner de vulnérabilités en concurrence avec CodeQL, Semgrep ou SonarQube. Ces outils réalisent une analyse profonde et précise une fois que votre code compile, généralement un langage à la fois. GitGalaxy répond d'abord à une question différente — à quoi ressemble réellement ce système dans son ensemble, et où le risque est-il concentré — sur tous les langages du dépôt simultanément, avant même que ces outils plus approfondis disposent d'une compilation avec laquelle travailler. Voir "How This Compares, Architecturally" ci-dessous pour savoir exactement où commence et où s'arrête le travail de chaque outil.
Gitgalaxy peut évaluer des dépôts complets, composés de mélanges de plus de 50 langages différents, cartographier l'architecture et faire remonter les expositions au risque ainsi que des cibles de refactoring priorisées — points chauds, risque de bus factor et fichiers porteurs — afin que vous sachiez par où commencer. Le graphique ci-dessous est un workflow issu d'une seule analyse gitgalaxy de notre dépôt de test golden, qui contient des exemples de code allant du logiciel de vol d'Apollo-11 de 1969 aux stacks technologiques modernes. Benchmark
Le cœur de la sortie de Gitgalaxy est une seule chose : un graphe structurel déterministe de l'ensemble du dépôt. L'audit de sécurité, la priorisation du refactoring et la traduction de langage legacy vers moderne (voir Outils et cas d'usage pour bases de code d'entreprise ci-dessous) sont tous des consommateurs de ce même graphe, et non des produits séparés avec des moteurs séparés — c'est pourquoi cette solution ressemble davantage à une plateforme d'intelligence d'architecture qu'à un scanner de vulnérabilités à usage unique.
La plupart des moteurs d'intelligence de code utilisent un AST, comme tree-sitter, qui offre une vue trop granulaire d'un dépôt (comme demander à comprendre une maison et recevoir la liste de chaque brique et de chaque vitre) et qui limite les langages et les fichiers pouvant être analysés. Les dépôts modernes sont polyglottes. De nombreux dépôts contiennent d'anciens codes sans AST exploitable. Pour contourner cela, Gitgalaxy utilise un moteur maison d'analyse structurelle regex/lexicale, surmonté d'une couche statistique — il construit un vecteur de caractéristiques par fichier (à partir d'environ 97 catégories de "signaux" regex - qui marquent les limites des fonctions, le flux de contrôle, les E/S, la mutation d'état et des dizaines d'autres comportements structurels et liés à la sécurité) et par dépôt (graphe de dépendances via résolution d'imports + PageRank/centralité), puis transforme ces comptages bruts en scores de risque normalisés de 0 à 100 via des fonctions sigmoïdes, et exporte le résultat dans six formats.
Gitgalaxy échange la précision au niveau AST contre une vitesse supérieure de plusieurs ordres de grandeur et une couverture universelle des langages, dans le même esprit que BLAST a échangé l'alignement exhaustif de Smith-Waterman pour une vitesse heuristique en génomique. La sortie comprend SARIF, un SBOM CycloneDX, un graphe de connaissances SQLite interrogeable, un résumé d'architecture optimisé pour LLM et des données de visualisation 3D issues d'une seule passe d'analyse — voir "Quel problème cet outil résout-il ?" ci-dessus pour des chiffres réels de temps d'analyse plutôt qu'un simple adjectif.
GitGalaxy produit deux types de sorties différents, et ils doivent être lus différemment.
Les scores d'exposition au risque sont un signal de 0 à 100, normalisé par densité, sur 19 catégories (secrets, surface d'injection, corruption mémoire, etc.), agrégé de la fonction jusqu'au dépôt, en passant par le fichier et le dossier. Un score élevé signifie que ce point mérite l'attention en premier — c'est un signal de priorisation, pas un verdict. Deux fichiers peuvent porter le même score pour des raisons complètement différentes : un vrai problème, ou un motif légitime qui semble identique en surface. Un malware chiffré et une routine cryptographique bien testée produisent tous deux une entropie élevée. GitGalaxy ne peut pas vous dire lequel il a trouvé — seulement qu'il y a là quelque chose qui mérite un deuxième coup d'œil.
Les constatations (findings) sont des signalements individuels au niveau de la ligne : une signature structurelle spécifique qui a franchi un seuil de risque. Ce sont des éléments de preuve à examiner, pas des vulnérabilités confirmées. GitGalaxy n'exécute jamais de code, ne trace pas les flux de données à l'exécution et ne vérifie pas l'exploitabilité — il vous indique qu'un motif existe dans le texte, à cette ligne précise, et vous fournit le contexte pour juger par vous-même.
C'est un choix assumé, pas une limite que nous cachons. GitGalaxy est conçu pour privilégier le rappel au détriment de la précision : signaler davantage, et laisser un humain ou un outil plus approfondi réduire la liste, plutôt que de risquer de rester silencieux sur quelque chose de réel. Les faux positifs sont le coût attendu de ce compromis, comme pour tout analyseur statique qui n'exécute pas le code qu'il lit.
Cela signifie aussi que GitGalaxy est le plus efficace face à une classe spécifique de problèmes — la négligence, pas l'évasion adverse. Une clé codée en dur que quelqu'un a oublié de supprimer, un registre non sécurisé, un appel eval() manifestement dangereux — personne de l'autre côté n'essaie de se cacher d'un scanner. Un attaquant spécifiquement motivé qui connaît le fonctionnement de la détection statique par signatures peut contourner des signaux individuels comme les seuils d'entropie sans grand effort. Traitez GitGalaxy comme la première passe rapide sur une base de code trop grande pour être lue à la main — pas comme le dernier mot sur la sécurité d'un élément.
La plupart des scanners de dépendances fonctionnent à partir d'une table de correspondance : ils savent qu'une vulnérabilité existe parce que quelqu'un l'a trouvée, l'a déclarée, et qu'elle a maintenant un numéro CVE dans un flux. C'est utile, mais c'est nécessairement réactif — un scanner construit de cette façon est aveugle à tout ce qui n'a pas encore été découvert et divulgué, y compris les variantes directes de motifs connus comme dangereux qui ressemblent simplement un peu différemment de l'instance déclarée.
GitGalaxy adopte une approche différente : au lieu de faire correspondre des instances connues, il fait correspondre des classes de faiblesses. Ses constatations sont étiquetées par CWE (Common Weakness Enumeration) — identifiants codés en dur, exécution dynamique de code, désérialisation non sécurisée — et non par ID CVE. Une signature structurelle pour "l'exécution dynamique d'une entrée non fiable" détecte ce motif où qu'il apparaisse, quels que soient les noms de variables, quelle que soit la disposition spécifique — pas seulement l'instance unique que quelqu'un a déjà signalée dans un rapport.
La même philosophie s'étend à la couche SBOM. Plutôt que de se demander "cette version de paquet apparaît-elle dans une base de données de vulnérabilités", GitGalaxy se demande si "le contenu réel de ce paquet sur disque correspond structurellement à ce à quoi devrait ressembler une version légitime" — entropie, empreinte structurelle, indicateurs d'anomalie comportementale. C'est ainsi qu'une dépendance falsifiée est détectée dès le premier jour, avant que quiconque ait découvert ou divulgué quoi que ce soit, car il n'y a pas de CVE à attendre.
C'est un complément aux outils de flux CVE (Snyk, Dependabot, OSV-Scanner), pas un remplaçant — ces outils sont la bonne réponse pour savoir si "ce bug connu précis est présent". GitGalaxy est la bonne réponse pour le filet plus large : les classes de faiblesses et les anomalies physiques qui n'exigent pas que quelqu'un ait d'abord trouvé et déclaré l'instance spécifique.
Il s'agit d'une comparaison autodéclarée de ce que chaque outil exige et détecte structurellement, et non d'un benchmark indépendant — à vérifier auprès de la documentation de chaque projet. Elle existe pour répondre clairement à une question : quelle lacune GitGalaxy est-il réellement conçu pour combler, par rapport à des outils qui font un travail connexe mais différent.
Là où les homologues de GitGalaxy dans la catégorie SAST ont besoin d'un AST ou d'une compilation fonctionnelle, et là où les outils de flux CVE ont besoin d'un manifeste de paquets, se trouve précisément la lacune que GitGalaxy est conçu pour combler — sans prétendre remplacer ce qu'ils font bien.
Chaque affirmation "signature structurelle" et "sans AST" ci-dessus est étayée par trois éléments que vous pouvez inspecter et ré-exécuter vous-même, et non pas accepter par simple confiance :
gitgalaxy/standards/language_standards.py définit chaque règle regex que le moteur utilise pour reconnaître une construction — un début de fonction, une frontière d'API, un contournement de sécurité — dans les 45 langages qui ont de véritables signatures structurelles (environ 1 970 motifs compilés au total). Chacune de ces règles est testée pour ce qu'elle doit faire correspondre, ce qu'elle doit explicitement exclure (le contrôle des faux positifs que la plupart des outils basés sur les regex omettent), et pour s'assurer qu'elle ne peut pas être bloquée par une entrée hostile. Voir tests/README.md pour l'index complet, et l'epic #518 pour l'audit qui l'a clôturé — des dizaines de vrais bugs de regex trouvés et corrigés en cours de route, pas seulement une couverture théorique.language-crucible est un instantané figé et tagué d'environ 120 sous-répertoires réels extraits de grands projets open source — le C++ de Godot, le compilateur C# Roslyn, curl, Kubernetes, le logiciel de vol AGC d'Apollo 11, et bien d'autres — délibérément laissés déconnectés et non compilables, le même état hostile que celui des vrais dépôts. Chaque pull request qui touche au moteur d'analyse re-scanne ce corpus entier et compare la sortie, champ par champ, avec un instantané archivé (tests/golden_master_audit.json) ; une différence signifie que la sortie a changé sur du code réel, et elle doit être expliquée avant d'être acceptée — pas un test de fumée, une véritable comparaison golden-master. Voir pour exactement comment cela est intégré à la CI, et pour comprendre pourquoi ce corpus est construit de cette façon.GitGalaxy est conçu pour s'exécuter dans la CI, pas seulement pour recevoir une étoile et être oublié — c'est pourquoi nous suivons l'intégration CI/production comme un signal d'adoption à part entière, en parallèle de la découverte humaine, au lieu de la filtrer comme du bruit.
À gauche : les étoiles et forks GitHub (cumulés — reconstruits à partir de l'horodatage de chaque étoile/fork, pas seulement d'un instantané à partir d'aujourd'hui) ainsi que les cloneurs uniques quotidiens et les vues de profil. À droite : l'utilisation du catalogue CI/CD GitLab (projets uniques exécutant GitGalaxy dans un pipeline au cours des 30 derniers jours) et l'adoption de l'Action GitHub (dépôts uniques référençant l'action dans un workflow, via la recherche de code — GitGalaxy n'est pas encore listé sur le Marketplace, c'est donc le meilleur signal passif disponible). Contrairement au panneau de gauche, GitHub et GitLab n'exposent aucun historique pour ces deux indicateurs — attendez-vous à ce que le panneau de droite se remplisse jour après jour plutôt que d'afficher une tendance rétroactive.
Volume de distribution combiné sur PyPI, GitHub et GitLab par rapport à nos dépôts de contrôle de référence — pas un comptage uniformément dédupliqué. Le comptage des cloneurs uniques de GitHub et celui des projets uniques de GitLab sont réellement dédupliqués ; les données publiques de téléchargement de PyPI n'ont aucune identité permettant la déduplication (mesurées sans miroirs, ce qui exclut les bots de synchronisation de miroirs connus mais pas les installations pilotées par la CI), cette composante est donc un comptage brut d'événements de téléchargement. Les lignes de répartition GitHub/PyPI commencent en cours de période parce que le suivi par source a été ajouté après le suivi du total ; la ligne totale avant ce point est une agrégation de toutes les sources.
Méthodologie complète, y compris exactement ce qui est et n'est pas dédupliqué par source : squid-protocol/squid-telemetry.
GitGalaxy effectue 100 % de son analyse et de sa vectorisation localement — le moteur fonctionne de la même manière totalement air-gapped que connecté.
Déposez directement le modèle de votre plateforme dans votre pipeline — chacun exécute une analyse GitGalaxy et peut faire échouer le build en cas de dépassement du seuil de risque ou de violation de signature de malware.
Le graphe structurel du moteur principal alimente un ensemble d'outils autonomes construits par-dessus, chacun
étant un module séparé sous gitgalaxy/tools/ qui consomme la même sortie d'analyse déterministe
plutôt que de ré-analyser le dépôt lui-même.
Un pipeline de traduction déterministe et haute-fidélité. Il convertit le COBOL legacy en architectures Spring Boot modernes et entièrement compilables, mappant la mémoire avec exactitude et échafaudant les entités JPA, les contrôleurs REST et les builds Maven avant d'utiliser l'IA pour traduire la logique métier isolée.
Une suite analytique pour assainir les monolithes mainframe. Elle neutralise en toute sécurité les pièges lexicaux legacy, extrait la mémoire d'exécution morte, cartographie les ordres d'exécution DAG topologiques et génère des configurations JCL Zero-Trust pour les déploiements cloud modernes.
Des pare-feu pré-commit qui scannent le contenu physique des fichiers plutôt que de se fier aux fichiers manifeste — conçus pour bloquer la stéganographie, les boucles de décryptage XOR au niveau octet, le typosquatting par homoglyphes et les coffres cryptographiques exposés avant qu'ils n'entrent dans votre pipeline CI/CD. Déployez directement via notre action GitHub.
Un générateur de Software Bill of Materials (SBOM) qui ne se fie pas aveuglément à package.json ou requirements.txt — il localise les dépendances physiques sur le disque, vérifie leur entropie et leur identité linguistique par rapport à ce à quoi une version légitime devrait ressembler, et génère des rapports JSON CycloneDX 1.4 stricts.
Un outil de cartographie déterministe des surfaces API non documentées et obsolètes. Il utilise des regex structurelles pour trouver la logique de routage physique active (Express, Spring Boot, FastAPI) et applique la théorie des ensembles par rapport à la documentation officielle OpenAPI/Swagger afin d'isoler les API Shadow (routes non documentées) et les API Ghost (routes documentées mais plus implémentées).
Analyse de logs fonctionnant à 0.07 GB/sec sans nécessiter d'index. Elle diffuse en continu d'énormes dumps de bases de données pour rechercher et masquer les PII (cartes bancaires, numéros de sécurité sociale, clés AWS) et utilise des cartes d'architecture statiques pour rapporter les fréquences d'exécution runtime sous forme d'histogrammes de séries temporelles ASCII.
Le capteur AppSec signale les agents IA connectés à une capacité brute de mutation d'état : un framework d'orchestration LLM (LangChain, LlamaIndex) importé parallèlement à des E/S réseau/disque directes, combiné à une densité de programmation défensive inférieure au seuil. C'est un signal d'identité de bibliothèque, pas une affirmation sur le comportement à l'exécution — un moteur à base de regex uniquement, sans suivi de flux de données, ne peut pas prouver que le code exécute réellement ce chemin, donc il ne prétend pas le faire (voir #1102 pour les vérifications qui ont été retirées pour avoir formulé cette affirmation non prouvable). Par ailleurs, le pare-feu Dev Agent évalue la masse de jetons et le rayon d'explosion afin de restreindre les agents de codage autonomes à la modification de fichiers dangereux ou drainant les jetons de contexte.
Si vous préférez l'analyse visuelle, nous avons construit un tableau de bord topologique où chaque fichier représente un nœud, dimensionné et coloré selon des métriques de risque spécifiques.
Glissez-déposez simplement votre fichier your_repo_GPU_galaxy.json généré (ou un .zip de votre dépôt brut) directement dans GitGalaxy.io. Tout le rendu et l'analyse se déroulent entièrement dans la mémoire locale de votre navigateur.
Cartographie de 3,2 millions de lignes de C++ en 11 secondes | OpenCV 
Copyright (c) 2026 Joe Esquibel
GitGalaxy est distribué sous la PolyForm Noncommercial License 1.0.0.
Nous sommes profondément engagés envers les communautés open-source et académiques. Si vous utilisez GitGalaxy pour des projets personnels, la recherche académique ou un développement non commercial, le moteur est 100 % gratuit à utiliser.
Pour supprimer les délais de licence commerciale dans votre terminal ou vos pipelines CI/CD personnels, définissez simplement la variable d'environnement suivante :```bash export GITGALAXY_LICENSE_KEY="COMMUNITY_FREE_TIER"
### Utilisation commerciale et en entreprise
Exécuter GitGalaxy dans des environnements d'entreprise, sur des bases de code propriétaires ou dans des pipelines CI/CD commerciaux nécessite une licence entreprise. Les pipelines d'entreprise non licenciés subiront une friction d'exécution intentionnelle, et toute tentative d'utiliser la clé Community Free Tier dans un environnement d'entreprise déclenchera des avertissements explicites de non-conformité dans vos journaux d'audit.
Pour obtenir une clé commerciale pour votre organisation et garantir des journaux de conformité irréprochables, veuillez contacter : **[email protected]**
Le résultat est un graphe de connaissances déterministe du dépôt, construit sans jamais exiger que le code compile. Il calcule le ratio entre code de test et logique métier, cartographie le "rayon d'impact" (blast radius) de chaque fichier en aval à travers le graphe de dépendances, et fait remonter des signaux de structure de projet que les linters ligne par ligne manquent totalement. L'extraction de signaux par fichier s'exécute en temps linéaire par rapport à la taille de la base de code ; les métriques de graphe au niveau du dépôt (centralité, détection de communautés) utilisent des algorithmes standards d'analyse de réseaux avec des bornes d'échantillonnage explicites sur les très grands graphes.
Le croisement de ce graphe structurel avec l'historique git fait également remonter deux signaux de refactoring spécifiques et priorisés : le risque de bus factor (fichiers porteurs détenus presque entièrement par un seul contributeur) et les points chauds de refactoring (fichiers à la fois très modifiés, très complexes et très endettés — le signal standard indiquant où l'effort de refactoring est réellement rentable). Les deux sont des cibles nommées au niveau du fichier, et non de simples scores.
| GitGalaxy | Semgrep | CodeQL | Snyk / Dependabot |
|---|
| Exige un AST ou une compilation | Non — signatures structurelles regex/lexicales | Oui — correspondance de motifs AST par langage | Oui — compile/extrait une base de données de code | Non — lit les manifestes de paquets |
| Base de détection | Classe de faiblesse (CWE) + anomalie physique/structurelle | Règles de correspondance de motifs (SAST) | Requêtes de flux de données/taint (SAST) | Recherche dans les bases de données CVE/avis de sécurité (SCA) |
| Fonctionne sur du code cassé/non compilé | Oui — c'est l'objectif de conception | Partiel, dépend de la règle/du parseur | Non — nécessite une compilation fonctionnelle | Oui — lit uniquement le manifeste |
| Hors ligne / air-gapped | Oui, entièrement local | Le moteur OSS s'exécute localement ; la plateforme cloud est hébergée | S'exécute localement ; souvent utilisé via les Actions hébergées par GitHub | Dépendant du cloud (Snyk) ; hébergé par GitHub (Dependabot) |
_galaxy_audit.json, _galaxy_master.db et _galaxy_llm.md produit par le scanner, conservé versionné avec chaque version du moteur. Le manifeste du corpus, qui fixe précisément quels dépôts et commits ont été analysés, couvre actuellement un sous-ensemble de 323 dépôts du lot plus large archivé là-bas — indiqué clairement dans le README de ce dépôt plutôt que laissé sous-entendu comme complet.Ce même lot de sorties brutes est ce sur quoi l'affirmation de vitesse ci-dessus est ajustée — chaque dépôt y est tracé, pas seulement l'exemple favorable de Kubernetes :
Toujours avec la version la plus récente du scanner — dérivation complète et méthodologie dans la section Speed Telemetry de gitgalaxy-raw-output.
| Plateforme | Modèle |
|---|
| GitHub Actions | gitgalaxy-pipeline.yml — voir le guide d'intégration complet |
| GitLab CI | scan.yml |
| Bitbucket Pipelines | bitbucket-pipelines.yml + bitbucket_insights.py (publie les résultats sous forme d'annotations Bitbucket Code Insights) |
| Azure Pipelines | azure-pipelines.yml |
| Tout autre (Jenkins, CircleCI, etc.) | scan.yml — modèle générique, invocable via shell |