GitGalaxy

Документация · Визуализатор

1 сканирование · 97 структурных сигналов · 50+ языков · 0 необходимости в компиляции
19 оценок подверженности риску · 6 итоговых отчётов · 0 зависимостей · pip install gitgalaxy

Какую проблему это решает?

GitGalaxy создан для решения одной повторяющейся проблемы: понимания большой, реальной, мультиязычной кодовой базы, которая не компилируется чисто, — именно в таком состоянии находятся большинство production-репозиториев, а не в виде чистого ввода на одном языке, который предполагает большинство инструментов статического анализа.

• Полносистемное сканирование на 50+ языках за один проход. Не нужен ни отдельный инструментарий для каждого языка, ни успешная сборка. Полиглот-репозиторий, в котором смешаны Go, YAML, Shell и Python, сканируется как единая система, а не как пять отдельных вызовов инструментов.
• Никакой компиляции, никогда. Сломанные зависимости, отсутствующие пакеты, отсоединённый вендоренный код, наполовину мигрировавшие легаси-модули — всё сканируется так же, как и чистый репозиторий, потому что здесь ничто не должно сначала собираться.
• Достаточно быстрый, чтобы запускаться при каждом коммите. Большинство репозиториев сканируются значительно быстрее минуты — Kubernetes, 1,39 млн строк на Go, YAML, JSON, Shell и Proto, сканируется целиком за 50,83 секунды. Время сканирования аппроксимируется двумя режимами на пакете из 599 репозиториев: плоские накладные расходы ниже ~4258 LOC, затем time(s) ≈ 3.36e-05 × LOC^0.969 выше этого порога (R²=0.88, почти линейно, без деградации на больших входных данных) — график и вывод см. в разделе Доказательства, а не просто утверждения, а не только этот округлённый заголовок.
• Вывод, нативный для CI, а не отдельный отчёт. Каждое сканирование создаёт файл SARIF (попадает прямо в панели безопасности GitHub/GitLab), SBOM в формате CycloneDX (соответствие нормам по зависимостям) и оценку подверженности риску от 0 до 100 для каждого файла, папки и репозитория. Примеры каждого типа — в разделе Бенчмарки.

Это не сканер уязвимостей, конкурирующий с CodeQL, Semgrep или SonarQube. Эти инструменты выполняют глубокий и точный анализ после того, как ваш код компилируется, как правило, по одному языку за раз. GitGalaxy сначала отвечает на другой вопрос — как на самом деле выглядит вся эта система и где сосредоточен риск, — по всем языкам репозитория одновременно, ещё до того, как у этих более глубоких инструментов появится сборка для работы. То, где именно начинается и заканчивается работа каждого инструмента, описано ниже в разделе «Как это сравнивается архитектурно».

GitGalaxy может оценивать полные репозитории, состоящие из смесей 50+ различных языков, составлять карту архитектуры и выявлять подверженности риску вместе с приоритизированными целями рефакторинга — горячие точки, риск bus-factor и несущие файлы, — чтобы вы знали, на чём сосредоточиться в первую очередь. График ниже — это workflow одного сканирования GitGalaxy нашего золотого тестового репозитория, который содержит примеры кода от полётного ПО Apollo-11 1969 года до современных технологических стеков. Бенчмарк

Архитектурная аналитика — безопасность, навигация по коду и модернизация легаси на основе одного графа

Основной результат работы GitGalaxy — одна вещь: детерминированный структурный граф всего репозитория. Аудит безопасности, приоритизация рефакторинга и перевод легаси-кода на современные языки (см. раздел Инструменты для корпоративных кодовых баз и сценарии использования ниже) — всё это потребители одного и того же графа, а не отдельные продукты с отдельными движками, — поэтому этот инструмент читается скорее как платформа архитектурной аналитики, чем как узкоспециализированный сканер уязвимостей.

Большинство движков анализа кода используют AST, например tree-sitter, который даёт чрезмерно детализированное представление репозитория (как если бы вы попросили понять устройство дома и получили список каждого кирпича и каждого оконного стекла) и ограничивает языки и файлы, которые можно сканировать. Современные репозитории полиязычны. Во многих репозиториях есть старый код без качественного AST. Чтобы обойти это, GitGalaxy использует собственный regex/лексический движок структурного анализа со слоем статистики поверх него: он строит вектор признаков для каждого файла (из ~97 категорий regex-«сигналов», отмечающих границы функций, поток управления, ввод/вывод, мутацию состояния и десятки других структурных и связанных с безопасностью поведений) и для каждого репозитория (граф зависимостей через разрешение импортов + PageRank/центральность), затем преобразует эти сырые счётчики в нормализованные оценки риска от 0 до 100 с помощью сигмоидных функций и экспортирует результат в шесть форматов.

GitGalaxy обменивает точность уровня AST на скорость на порядки выше и универсальное покрытие языков — в том же духе, в котором BLAST обменял исчерпывающее выравнивание Смита–Уотермана на эвристическую скорость в геномике. Вывод включает SARIF, SBOM в формате CycloneDX, запрашиваемый граф знаний SQLite, оптимизированную для LLM сводку по архитектуре и данные 3D-визуализации за один проход сканирования — реальные цифры времени сканирования, а не голые прилагательные, см. в разделе «Какую проблему это решает?» выше.

Результат — детерминированный граф знаний репозитория, построенный без единого требования к компиляции кода. Он вычисляет соотношение тестового кода к основной логике, отображает «радиус поражения» каждого файла вниз по графу зависимостей и выявляет сигналы структуры проекта, которые построчные линтеры полностью пропускают. Извлечение сигналов для каждого файла выполняется за время, линейно зависящее от размера кодовой базы; метрики графа на уровне репозитория (центральность, обнаружение сообществ) используют стандартные алгоритмы сетевого анализа с явными ограничениями выборки на очень больших графах.

Сканирование Apollo-11 с помощью движка blAST

Что находит GitGalaxy — и чего он не утверждает

GitGalaxy создаёт два разных типа выходных данных, и их следует читать по-разному.

Оценки подверженности риску — это нормированный по плотности сигнал в диапазоне 0–100 по 19 категориям (секреты, поверхность инъекций, повреждение памяти и другие), агрегируемый от функции к файлу, к папке и к репозиторию. Высокий показатель означает этому стоит уделить внимание в первую очередь — это сигнал приоритизации, а не вердикт. Два файла могут иметь одинаковый показатель по совершенно разным причинам: реальная проблема или легитимный паттерн, который на поверхности выглядит идентично. Зашифрованное вредоносное ПО и хорошо протестированная криптографическая процедура оба создают высокую энтропию. GitGalaxy не может сказать, какой из случаев он нашёл, — только то, что там есть что-то, заслуживающее второго взгляда.

Находки — это отдельные флаги на уровне строк: конкретная структурная сигнатура, пересекшая порог риска. Это доказательства для проверки, а не подтверждённые уязвимости. GitGalaxy никогда не выполняет код, не трассирует потоки данных во время выполнения и не проверяет эксплуатируемость, — он сообщает, что паттерн существует в тексте, на этой конкретной строке, и передаёт вам контекст, чтобы вы вынесли суждение самостоятельно.

Это сделано намеренно, а не является скрываемым ограничением. GitGalaxy спроектирован так, чтобы ошибаться в сторону полноты, а не точности: помечать больше и позволять человеку или более глубокому инструменту сузить список, а не рисковать промолчать о чём-то реальном. Ложные срабатывания — ожидаемая цена такого компромисса, как и для любого статического анализатора, который не исполняет читаемый код.

Это также означает, что GitGalaxy наиболее силён против конкретного класса проблем — халатности, а не злонамеренного обхода. Захардкоженный ключ, который кто-то забыл удалить, небезопасный реестр, явно опасный вызов eval() — никто на той стороне не пытается спрятаться от сканера. Целенаправленно мотивированный злоумышленник, знающий, как работает статическое сигнатурное обнаружение, может без особых усилий обойти отдельные сигналы, такие как пороги энтропии. Относитесь к GitGalaxy как к быстрому первому проходу по кодовой базе, слишком большой для ручного чтения, — а не как к последнему слову о том, безопасно ли что-то.

Доказательства, а не просто утверждения

Каждое утверждение о «структурных сигнатурах» и «отсутствии AST» выше подкреплено тремя вещами, которые вы можете проверить и перезапустить сами, а не просто принять на веру:

1. 3 649 регрессионных тестов на каждую сигнатуру. gitgalaxy/standards/language_standards.py определяет каждое regex-правило, которое движок использует для распознавания конструкции — начало функции, граница API, обход защиты, — на 45 языках, имеющих реальные структурные сигнатуры (всего ~1970 скомпилированных паттернов). Каждое из этих правил проверяется на то, что оно должно сопоставлять, что должно явно исключать (проверка ложных срабатываний, которую пропускает большинство regex-инструментов), и что его нельзя повесить враждебным вводом. Полный индекс — в tests/README.md, а аудит, который его завершил, — в epic #518: по ходу дела были найдены и исправлены десятки реальных regex-багов, а не только теоретическое покрытие.
2. Настоящий golden diff против реального, неизменённого production-кода. language-crucible — это закреплённый, тегированный снимок ~120 реальных подкаталогов, взятых из крупных open-source проектов: C++ Godot, компилятор Roslyn на C#, curl, Kubernetes, полётное ПО AGC Apollo 11 и другие, — намеренно оставленных отсоединёнными и некомпилируемыми, в том же враждебном состоянии, в котором находятся реальные репозитории. Каждый pull request, затрагивающий парсинг-движок, пересканирует весь корпус и сравнивает вывод поле за полем с закоммиченным снимком (tests/golden_master_audit.json); отличие означает, что вывод изменился на реальном коде, и его нужно объяснить до того, как изменение будет принято, — это не smoke-тест, а настоящее сравнение с golden master. О том, как именно это подключено к CI, см. , а о том, почему корпус устроен именно так, — .

Бенчмарки

• Тестовый репозиторий на 50+ языках — он же корпус golden master, описанный выше, — и артефакты
• Необработанные выходные данные в реальном масштабе — неотредактированные результаты сканирования (аудит JSON, SQLite, LLM-сводки) сотен независимо выбранных репозиториев, сохраняемые с версионированием под каждый релиз движка
• Результаты скорости на 104 репозиториях
• Сравнение более 1000 репозиториев на разных языках: детерминированное бенчмаркинг-сравнение 1:1 различных синтаксических архитектур.
• Универсальные архетипы файлов с помощью k-means кластеризации: ML-изоляция файлов в кластеры K-means.
• Миграция с мейнфреймов: успех компиляции 27/27 в легаси-репозиториях COBOL: 27 различных легаси-репозиториев COBOL (включая бенчмарк-приложения IBM CICS) переведены в компилируемые окружения Java Spring Boot.

Реальное внедрение

GitGalaxy предназначен для запуска в CI, а не только для получения звёзд и забвения, — поэтому мы отслеживаем интеграцию в CI/production как отдельный сигнал внедрения наряду с человеческим обнаружением, а не отфильтровываем его как шум.

Слева: звёзды и форки GitHub (кумулятивно — восстановлено по собственной временной метке каждой звезды и каждого форка, а не просто снимок на будущее) наряду с ежедневными уникальными клонировавшими и просмотрами профилей. Справа: использование GitLab CI/CD Catalog (уникальные проекты, запускающие GitGalaxy в пайплайне за последние 30 дней) и внедрение GitHub Action (уникальные репозитории, ссылающиеся на action в workflow, через поиск по коду — GitGalaxy ещё нет в Marketplace, так что это лучший доступный пассивный сигнал). В отличие от левой панели, GitHub и GitLab не раскрывают никакой истории по этим двум — ожидайте, что правая панель будет заполняться день за днём, а не покажет ретроспективный тренд.

Совокупный объём распространения через PyPI, GitHub и GitLab относительно наших базовых контрольных репозиториев — не единообразно дедуплицированный подсчёт. Количество уникальных клонировавших на GitHub и уникальных проектов на GitLab действительно дедуплицировано; публичные данные о загрузках PyPI не имеют идентичности, по которой можно было бы дедуплицировать (измерено без зеркал, что исключает известных зеркальных синхронизирующих ботов, но не установки из CI), так что этот компонент — сырой подсчёт событий загрузки. Линии разбивки GitHub/PyPI начинаются не с начала окна, потому что отслеживание по источникам было добавлено после отслеживания общего объёма; линия общего объёма до этого момента агрегирует все источники.

Полная методология, включая то, что именно дедуплицируется, а что нет по каждому источнику: squid-protocol/squid-telemetry.

Конфиденциальность данных и развёртывание on-premise

GitGalaxy выполняет 100% своего сканирования и векторизации локально — движок работает одинаково как в полностью изолированной среде (air-gapped), так и при наличии подключения.

• Никакой передачи данных: исходный код никогда не передаётся ни в какой API, облачную базу данных или сторонний сервис.
• Выполнение on-premise / air-gapped: отсутствие сетевых зависимостей во время выполнения — движок работает идентично в полностью изолированной среде.
• Эфемерная обработка в памяти (веб-визуализатор): репозитории распаковываются в энергозависимый буфер памяти (RAM) и автоматически удаляются при закрытии вкладки браузера.
• Конфиденциальность по замыслу (Privacy-by-Design): даже при использовании веб-просмотрщика данные всё время остаются за файрволом пользователя.