1 scan · 97 structural signals · 50+ languages · 0 need for compilation
19 risk exposure scores · 6 final reports · 0 dependencies · pip install gitgalaxy
GitGalaxy exists for one recurring problem: understanding a large, real, multi-language codebase that doesn't compile cleanly — the state most production repositories are actually in, not the clean single-language input most static-analysis tooling assumes.
- Full-system scans across 50+ languages in one pass. No per-language toolchain, no successful build required. A polyglot repo with Go, YAML, Shell, and Python mixed together scans as one system, not five separate tool invocations.
- No compilation, ever. Broken dependencies, missing packages, disconnected vendored code, half-migrated legacy modules — all scan the same way a clean repo does, because nothing here has to build first.
- Fast enough to run on every commit. Most repositories scan in well under a minute —
Kubernetes,
1.39M lines across Go, YAML, JSON, Shell, and Proto, scans end to end in 50.83 seconds. Scan
time is fit as two regimes across a 599-repo batch — flat overhead below ~4,258 LOC, then
time(s) ≈ 3.36e-05 × LOC^0.969above it (R²=0.88, near-linear, not degrading on large inputs) — see Proof, Not Just Claims for the chart and derivation, not just this rounded headline. - CI-native output, not a standalone report. Every scan produces a SARIF file (drops straight into GitHub/GitLab security dashboards), a CycloneDX SBOM (dependency compliance), and a 0–100 risk-exposure score per file, folder, and repo. See Benchmarks for real, inspectable examples of each.
This is not a vulnerability scanner competing with CodeQL, Semgrep, or SonarQube. Those tools do deep, precise analysis once your code compiles, usually one language at a time. GitGalaxy answers a different question first — what does this whole system actually look like, and where is the risk concentrated — across every language in the repo simultaneously, before those deeper tools even have a build to work with. See "How This Compares, Architecturally" below for exactly where each tool's job starts and stops.
Gitgalaxy can assess full repos, comprised of mixes of 50+ different languages, map out the architecture, and surface risk exposures alongside prioritized refactoring targets — hotspots, bus-factor risk, and load-bearing files — so you know where to focus first. The graph below is a workflow from one gitgalaxy scan of our golden test repo, which contains sample code files from the Apollo-11 1969 flight software through the modern tech stacks. Benchmark
Gitgalaxy's core output is one thing: a deterministic structural graph of the whole repository. Security auditing, refactor prioritization, and legacy-to-modern language translation (see Enterprise Codebase Tools & Use Cases below) are all consumers of that same graph, not separate products with separate engines — which is why this reads closer to an architecture-intelligence platform than a single-purpose vulnerability scanner.
Most code intelligence engines use an AST, like tree-sitter, which offers an overly granular view of a repo (like asking to understand a house and getting a list of every brick and glass pane) and it limits the languages and files that can be scanned. Modern repos are poly-lingual. Many repos have old code without a good AST. To bypass this, Gitgalaxy uses a custom regex/lexical structural-analysis engine with a statistics layer on top — it builds a feature vector per file (from ~97 regex "signal" categories - that mark the boundaries of functions, control flow, I/O, state mutation, and dozens of other structural and security-relevant behaviors) and per repo (dependency graph via import resolution + PageRank/centrality), then transforms those raw counts into normalized 0–100 risk scores via sigmoid functions, and exports the result to six formats.
Gitgalaxy trades AST-level precision for orders-of-magnitude speed and universal language coverage, in the same spirit that BLAST traded Smith-Waterman's exhaustive alignment for heuristic speed in genomics. Output includes SARIF, CycloneDX SBOM, a queryable SQLite knowledge graph, an LLM-optimized architecture brief, and 3D visualization data from a single scan pass — see "What Pain Point Does This Solve?" above for real scan-time figures rather than a bare adjective.
The result is a deterministic knowledge graph of the repository, built without ever requiring the code to compile. It calculates the ratio of test code to core logic, maps each file's downstream "blast radius" through the dependency graph, and surfaces project-structure signal that line-by-line linters miss entirely. Per-file signal extraction runs in time linear to codebase size; repository-level graph metrics (centrality, community detection) use standard network-analysis algorithms with explicit sampling bounds on very large graphs.
Crossing that structural graph against git history also surfaces two specific, prioritized refactoring signals: bus-factor risk (load-bearing files owned almost entirely by one contributor) and refactoring hotspots (files that are simultaneously high-churn, high-complexity, and high-debt — the standard signal for where refactoring effort actually pays off). Both are named, file-level targets, not just a score.
GitGalaxy produces two different kinds of output, and they should be read differently.
Risk Exposure scores are a 0–100, density-normalized signal across 19 categories (secrets, injection surface, memory corruption, and more), rolled up from function to file to folder to repository. A high score means this deserves attention first — it is a prioritization signal, not a verdict. Two files can carry the same score for completely different reasons: a real problem, or a legitimate pattern that looks identical on the surface. Encrypted malware and a well-tested cryptography routine both produce high entropy. GitGalaxy can't tell you which one it found — only that something worth a second look is there.
Findings are individual, line-level flags: a specific Structural Signature that crossed a risk threshold. These are evidence to review, not confirmed vulnerabilities. GitGalaxy never executes code, traces runtime dataflow, or verifies exploitability — it tells you a pattern exists in the text, at this exact line, and hands you the context to judge it yourself.
This is intentional, not a limitation we're hiding. GitGalaxy is built to err toward recall over precision: flag more, and let a human or a deeper tool narrow the list, rather than risk staying silent on something real. False positives are the expected cost of that trade-off, the same way they are for every static analyzer that doesn't execute the code it reads.
That also means GitGalaxy is strongest against a specific class of problem —
negligence, not adversarial evasion. A hardcoded key someone forgot to remove, an
insecure registry, an obviously dangerous eval() call — nobody on the other end of
those is trying to hide from a scanner. A specifically motivated attacker who knows
how static, signature-based detection works can evade individual signals like entropy
thresholds without much effort. Treat GitGalaxy as the fast first pass across a
codebase too large to read by hand — not the last word on whether something is safe.
Most dependency scanners work from a lookup table: they know a vulnerability exists because someone found it, filed it, and it now has a CVE number in a feed. That's useful, but it's necessarily reactive — a scanner built this way is blind to anything that hasn't been discovered and disclosed yet, including straightforward variants of known-bad patterns that just look slightly different from the filed instance.
GitGalaxy takes a different approach: instead of matching known instances, it matches weakness classes. Its findings are tagged by CWE (Common Weakness Enumeration) — hardcoded credentials, dynamic code execution, unsafe deserialization — not by CVE ID. A structural signature for "dynamic execution of tainted input" catches that pattern wherever it appears, with whatever variable names, in whatever specific arrangement — not just the one instance someone already filed a report about.
The same philosophy extends to the SBOM layer. Rather than asking "does this package version appear in a vulnerability database," GitGalaxy asks "does this package's actual content on disk structurally match what a legitimate version should look like" — entropy, structural fingerprint, behavioral anomaly flags. That's how a tampered dependency gets caught on day one, before anyone has discovered or disclosed anything, because there's no CVE to wait for.
This is a complement to CVE-feed tools (Snyk, Dependabot, OSV-Scanner), not a replacement for them — those tools are the right answer for "is this exact known bug present." GitGalaxy is the right answer for the wider net: weakness classes and physical anomalies that don't require anyone to have found and filed the specific instance first.
This is a self-reported comparison of what each tool structurally requires and detects on, not an independent benchmark — verify against each project's own documentation. It exists to answer one question plainly: what gap is GitGalaxy actually built to cover, versus tools doing a related but different job.
| GitGalaxy | Semgrep | CodeQL | Snyk / Dependabot | |
|---|---|---|---|---|
| Requires an AST or a build | No — regex/lexical structural signatures | Yes — per-language AST pattern matching | Yes — compiles/extracts a code database | No — reads package manifests |
| Detection basis | Weakness-class (CWE) + physical/structural anomaly | Pattern-match rules (SAST) | Dataflow/taint queries (SAST) | CVE/advisory-database lookup (SCA) |
| Works on broken/uncompiled code | Yes — this is the design target | Partial, depends on the rule/parser | No — needs a working build | Yes — only reads the manifest |
| Offline / air-gapped | Yes, fully local | OSS engine runs locally; Cloud Platform is hosted | Runs locally; commonly used via GitHub-hosted Actions | Cloud-dependent (Snyk); GitHub-hosted (Dependabot) |
Where GitGalaxy's SAST-category peers need an AST or a compiling build, and where the CVE-feed tools need a package manifest, is precisely the gap GitGalaxy is built to cover — not a claim that it replaces what they do well.
Every "structural signature" and "AST-free" claim above is backed by three things you can inspect and re-run yourself, not just take on faith:
- 3,649 per-signature regression tests.
gitgalaxy/standards/language_standards.pydefines every regex rule the engine uses to recognize a construct — a function start, an API boundary, a safety bypass — across the 45 languages that have real structural signatures (~1,970 compiled patterns total). Every one of those rules is tested for what it should match, what it should explicitly exclude (the false-positive check most regex-based tools skip), and that it can't be hung by an adversarial input. Seetests/README.mdfor the full index, and epic #518 for the audit that closed it out — dozens of real regex bugs found and fixed along the way, not just theoretical coverage. - A true golden diff against real, unmodified production code.
language-crucibleis a pinned, tagged snapshot of ~120 real subdirectories pulled from major open-source projects — Godot's C++, the Roslyn C# compiler, curl, Kubernetes, Apollo 11's AGC flight software, and more — deliberately left disconnected and uncompilable, the same hostile state real repos are in. Every pull request that touches the parsing engine re-scans that entire corpus and diffs the output, field by field, against a checked-in snapshot (tests/golden_master_audit.json); a diff means the output changed on real code, and it has to be explained before it's accepted — not a smoke test, an actual golden-master comparison. Seetests/README.mdfor exactly how this is wired into CI, and language-crucible's own README for why that corpus is built the way it is. - Unedited raw scan output at real-world scale. Where the golden-master corpus above proves correctness on ~120 curated adversarial paradigms, this repo is the complementary evidence that the engine actually runs, unmodified, across hundreds of independently-chosen real repositories — every
_galaxy_audit.json,_galaxy_master.db, and_galaxy_llm.mdthe scanner produced, kept versioned per engine release. The corpus manifest pinning exactly which repos and commits were scanned currently covers a 323-repo subset of the larger batch archived there — stated plainly in that repo's own README rather than implied to be complete.
That same raw-output batch is what the speed claim above is fit from — every repo plotted, not just the favorable Kubernetes example:
Always the newest scanner version — full derivation and methodology in gitgalaxy-raw-output's Speed Telemetry section.
- 50+ Language Test Repo — also the golden-master corpus described above — and artifacts
- Raw Output at Real-World Scale — unedited scan output (audit JSON, SQLite, LLM briefs) from hundreds of independently-chosen repositories, kept versioned per engine release
- Speed Results from 104 Repos
- Cross-Language Comparisons of over 1000 repos: Deterministic 1:1 benchmarking of distinct syntax architectures.
- Universal File Archetypes by k-means clustering: ML isolation of files into K-means clusters.
- Mainframe Migration: 27/27 Compile Success Across Legacy COBOL Repos: 27 distinct legacy COBOL repositories (including IBM CICS benchmark apps) translated into compiling Java Spring Boot environments.
GitGalaxy is meant to run in CI, not just get starred and forgotten — so we track CI/production integration as its own adoption signal alongside human discovery, instead of filtering it out as noise.
Left: GitHub stars and forks (cumulative — reconstructed from each star's/fork's own timestamp, not just a snapshot going forward) alongside daily unique cloners and profile views. Right: GitLab CI/CD Catalog usage (unique projects running GitGalaxy in a pipeline in the last 30 days) and GitHub Action adoption (unique repos referencing the action in a workflow, via code search — GitGalaxy isn't Marketplace-listed yet, so this is the best passive signal available). Unlike the left panel, GitHub and GitLab don't expose any history for these two — expect the right panel to fill in day by day rather than show a backfilled trend.
Combined distribution volume across PyPI, GitHub, and GitLab against our baseline control repositories — not a uniformly deduplicated count. GitHub's unique-cloner count and GitLab's unique-project count are genuinely deduplicated; PyPI's public download data has no identity to deduplicate against (measured without mirrors, which excludes known mirror-sync bots but not CI-driven installs), so that component is a raw download-event count. The GitHub/PyPI breakdown lines begin partway through the window because per-source tracking was added after total-fetch tracking; the total line before that point is aggregate across all sources.
Full methodology, including exactly what is and isn't deduplicated per source: squid-protocol/squid-telemetry.
GitGalaxy performs 100% of its scanning and vectorization locally — the engine runs the same way fully air-gapped as it does connected.
- No Data Transmission: Source code is never transmitted to any API, cloud database, or third-party service.
- On-Premise / Air-Gapped Execution: No runtime network dependency — the engine runs identically in a fully disconnected environment.
- Ephemeral Memory Processing (web visualizer): Repositories are unpacked into a volatile memory buffer (RAM) and automatically purged when the browser tab is closed.
- Privacy-by-Design: Even when using the web-based viewer, the data remains behind the user's firewall at all times.
- Python-based:
pip install gitgalaxy - CLI execution
- How to add a new programming language in 1 prompt
- Outputs forensic JSONs (optimized for AI-agent summary reports) and a native SQLite3 database for robust querying and storage.
Drop the template for your platform straight into your pipeline — each one runs a GitGalaxy scan and can fail the build on risk-threshold or malware-signature breaches.
| Platform | Template |
|---|---|
| GitHub Actions | gitgalaxy-pipeline.yml — see the full integration guide |
| GitLab CI | scan.yml |
| Bitbucket Pipelines | bitbucket-pipelines.yml + bitbucket_insights.py (posts findings as Bitbucket Code Insights annotations) |
| Azure Pipelines | azure-pipelines.yml |
| Anything else (Jenkins, CircleCI, etc.) | scan.yml — generic, shell-invocable template |
The core engine's structural graph feeds a set of standalone tools built on top of it, each
one a separate module under gitgalaxy/tools/ that consumes the same deterministic scan
output rather than re-parsing the repo itself.
A deterministic, high-fidelity translation pipeline. It converts legacy COBOL into fully compiling, modern Spring Boot architectures, mapping memory exactly and scaffolding JPA entities, REST controllers, and Maven builds before utilizing AI to translate isolated business logic.
- Benchmark: Achieved a 27/27 Maven compile success rate across a batch test of distinct legacy repos. Compiling is a necessary but not sufficient signal of a correct translation — it confirms the generated code builds, not that the business logic is semantically equivalent to the original; a business logic review is still required.
- Verify for Yourself: Inspect the raw outputs of the IBM CICS Application Translation here.
An analytical suite for sanitizing mainframe monoliths. It safely neutralizes legacy lexical traps, extracts dead execution memory, maps topological DAG execution orders, and generates Zero-Trust JCL configurations for modern cloud deployments.
- Benchmark: The dead-code extraction engine removed over 6,700 lines of dead execution blocks and orphaned variables from the standard IBM CICS benchmark app in seconds.
Pre-commit firewalls that scan physical file internals rather than trusting manifest files — built to block steganography, byte-level XOR decryption loops, homoglyph typosquatting, and exposed cryptographic vaults before they enter your CI/CD pipeline. Deploy directly via our GitHub Action.
A Software Bill of Materials (SBOM) generator that doesn't blindly trust package.json or requirements.txt — it locates the physical dependencies on disk, checks their entropy and linguistic identity against what a legitimate version should look like, and generates strict CycloneDX 1.4 JSON reports.
- Benchmark: Mapped and verified the physical internals of 170 unique Go modules inside the local Kubernetes repository. A single-repo result, not a claim of coverage across the Go ecosystem.
A deterministic mapping tool for undocumented and outdated API surface. It uses structural regex to find active physical routing logic (Express, Spring Boot, FastAPI) and applies set theory against official OpenAPI/Swagger documentation to isolate Shadow APIs (undocumented routes) and Ghost APIs (documented routes no longer implemented).
Log analysis operating at 0.07 GB/sec without requiring an index. It streams massive database dumps to hunt and mask PII (credit cards, SSNs, AWS keys) and uses static architecture maps to report runtime execution frequencies as ASCII time-series histograms.
The AppSec Sensor flags AI agents wired to raw state-mutation capability: an LLM orchestration framework (LangChain, LlamaIndex) imported alongside direct network/disk I/O, combined with below-threshold defensive-programming density. That's a library-identity signal, not a claim about runtime behavior — a regex-only engine with no dataflow tracing can't prove code actually executes that path, so it doesn't claim to (see #1102 for the checks that were removed for making that unprovable claim). Separately, the Dev Agent Firewall evaluates token mass and blast radius to restrict autonomous coding agents from modifying dangerous or context-token-draining files.
If you prefer visual analytics, we've built a topological dashboard where each file represents a node, sized and colored according to specific risk metrics.
Simply drag and drop your generated your_repo_GPU_galaxy.json file (or a .zip of your raw repository) directly into GitGalaxy.io. All rendering and scanning happens entirely in your browser's local memory.
Mapping 3.2 Million Lines of C++ in 11 Seconds | OpenCV
Copyright (c) 2026 Joe Esquibel
GitGalaxy is distributed under the PolyForm Noncommercial License 1.0.0.
We are deeply committed to the open-source and academic communities. If you are using GitGalaxy for personal projects, academic research, or non-commercial development, the engine is 100% free to use.
To suppress the commercial licensing delays in your terminal or personal CI/CD pipelines, simply set the following environment variable:
export GITGALAXY_LICENSE_KEY="COMMUNITY_FREE_TIER"Running GitGalaxy in corporate environments, proprietary codebases, or commercial CI/CD pipelines requires an enterprise license. Unlicensed corporate pipelines will experience intentional execution friction, and attempting to use the Community Free Tier key in a corporate environment will trigger explicit non-compliance warnings in your audit logs.
To acquire a commercial key for your organization and ensure clean compliance logs, please contact: joe@gitgalaxy.io