GitGalaxy

ドキュメント · ビジュアライザー

1 スキャン · 97 の構造シグナル · 50+ 言語 · コンパイル不要
19 のリスク曝露スコア · 6 の最終レポート · 0 依存関係 · pip install gitgalaxy

どのような課題を解決するのか?

GitGalaxy は、繰り返し発生する 1 つの問題のために存在します: 大規模で現実的なマルチ言語コードベースを きれいにコンパイルできない状態で理解すること — ほとんどの本番リポジトリが実際に置かれている状態。 これは、ほとんどの静的解析ツールが想定するクリーンな単一言語入力ではありません。

• 50 以上の言語を 1 回でスキャンする全システム対応。 言語ごとのツールチェーンは不要、 ビルドの成功も不要です。Go、YAML、Shell、Python が混在する多言語混在リポジトリは、 5 つの別々のツール呼び出しではなく、1 つのシステムとしてスキャンされます。
• コンパイルは一切不要。 壊れた依存関係、欠落したパッケージ、切り離されたベンダリングされたコード、 移行途中のレガシーモジュール — これらはすべて、クリーンなリポジトリと同じ方法でスキャンされます。 ここでは何も先にビルドする必要がないからです。
• すべてのコミットで実行できる十分な速さ。 ほとんどのリポジトリは 1 分未満でスキャンされます — Kubernetes、 Go、YAML、JSON、Shell、Proto にわたる 1.39M 行をエンドツーエンドで 50.83 秒でスキャンします。スキャン 時間は 599 リポジトリのバッチで 2 つの領域にフィットします — 約 4,258 LOC まではフラットなオーバーヘッド、 それ以上では time(s) ≈ 3.36e-05 × LOC^0.969 です (R²=0.88、ほぼ線形、 大きな入力でも劣化しません) — チャートと導出は 証明であって主張ではない を参照、 単なる四捨五入された見出しではありません。
• スタンドアロンのレポートではなく、CI ネイティブな出力。 すべてのスキャンは SARIF ファイルを生成します ( GitHub/GitLab のセキュリティダッシュボードに直接取り込める)、CycloneDX SBOM (依存関係のコンプライアンス)、 ファイル・フォルダ・リポジトリごとの 0 〜 100 のリスク曝露スコアも生成します。それぞれの実例は、 ベンチマーク で確認できます。

これは CodeQL、Semgrep、SonarQube と競合する脆弱性スキャナーではありません。 これらの ツールは、コードがコンパイルできた後に、通常は一度に 1 言語ずつ、深く正確な分析を行います。 GitGalaxy は最初に異なる質問に答えます — このシステム全体は実際にどのような姿をしているのか、 リスクはどこに集中しているのか — リポジトリ内のすべての言語を同時に、 これらのより深いツールが扱えるビルドができる前に。正確には 「アーキテクチャ的比較」 を下で参照して、 各ツールの役割がどこで始まりどこで終わるかを確認してください。

Gitgalaxy は、50 以上の異なる言語が混在する完全なリポジトリを評価し、アーキテクチャをマッピングし、優先順位付けされたリファクタリングターゲット (ホットスポット、バス因子リスク、基幹ファイル) とともにリスク曝露を表面化することができるため、どこに最初に焦点を当てるべきかがわかります。下のグラフは、Apollo-11 1969 年のフライトソフトウェアから最新のテックスタックまでのサンプルコードファイルを含む、当社のゴールデンテストリポジトリに対する 1 回の gitgalaxy スキャンからのワークフローです。ベンチマーク

アーキテクチャインテリジェンス — 1 つのグラフ上に構築されたセキュリティ、コードナビゲーション、レガシーモダナイゼーション

Gitgalaxy のコア出力は 1 つだけです: リポジトリ全体の決定論的な構造グラフです。 セキュリティ監査、リファクタリングの優先順位付け、レガシーからモダンへの言語 翻訳 (下記の エンタープライズコードベースツールとユースケース を参照) は、 すべて同じグラフのコンシューマーであり、別々のエンジンを備えた別々の製品ではありません — このため、単一目的の脆弱性スキャナーというよりは、アーキテクチャインテリジェンスプラットフォームに近い ものになっています。

ほとんどのコードインテリジェンスエンジンは tree-sitter のような AST を使用しており、これはリポジトリを過度に細かい粒度で表示します (家を理解しようとして、すべてのレンガとガラス板のリストを渡されるようなもの) そのため、スキャンできる言語とファイルが制限されます。現代のリポジトリは多言語です。多くのリポジトリには、適切な AST のない古いコードがあります。これを回避するために、Gitgalaxy はカスタムの regex / レキシカル構造解析エンジンとその上の統計レイヤーを使用します — ファイルごとに特徴ベクトルを構築し (~97 の regex「シグナル」カテゴリから。関数、制御フロー、I/O、状態変更、その他多数の構造的およびセキュリティ関連の動作の境界をマークします)、リポジトリごとにも (インポート解決 + PageRank / 中心性による依存関係グラフ) 構築し、その生のカウントをシグモイド関数で正規化された 0 〜 100 のリスクスコアに変換し、結果を 6 つの形式にエクスポートします。

Gitgalaxy は、AST レベルの精度を、桁違いの速度と普遍的な言語カバレッジと引き換えにしています。これは、BLAST が Smith-Waterman の 網羅的アラインメントをゲノミクスにおけるヒューリスティックな速度と引き換えたのと同じ精神です。出力には、SARIF、CycloneDX SBOM、クエリ可能な SQLite 知識グラフ、LLM 最適化アーキテクチャブリーフ、および 1 回のスキャンパスからの 3D 可視化データが含まれます — 実際のスキャン時間の数値については、上記の「どのような課題を解決するのか?」を参照してください。単なる形容詞ではなく。

その結果は、コードをコンパイルすることを一切必要とせずに構築された、リポジトリの決定論的知識グラフです。テストコードとコアロジックの比率を計算し、依存関係グラフを通じて各ファイルの下流の「ブラスト半径」をマッピングし、行ごとのリンターが見逃すプロジェクト構造シグナルを表面化します。ファイルごとのシグナル抽出はコードベースサイズに線形の時間で実行されます。リポジトリレベルのグラフメトリクス (中心性、コミュニティ検出) は、非常に大きなグラフでは明示的なサンプリング境界を持つ標準的なネットワーク解析アルゴリズムを使用します。

その構造グラフを git 履歴と交差させると、2 つの具体的で優先順位付けされたリファクタリングシグナルも表面化します: バス因子リスク (ほぼ 1 人のコントリビューターだけが所有する基幹ファイル) と リファクタリングホットスポット (高チャーン、高複雑性、高負債を同時に抱えるファイル — リファクタリングの努力が実際に報われる場所を示す標準的なシグナル)。どちらも名前付きのファイルレベルのターゲットであり、単なるスコアではありません。

blAST エンジンで Apollo-11 をスキャン

GitGalaxy が見つけるもの — そして主張しないこと

GitGalaxy は 2 種類の異なる出力を生成します。これらは異なる方法で読む必要があります。

リスク曝露スコア は、19 カテゴリにわたる 0–100 の密度正規化シグナルです (秘密情報、インジェクション面、メモリ破壊など)、関数から ファイル、フォルダ、リポジトリへとロールアップされます。高いスコアは これが最初に注目に値する ことを意味します — それは優先順位付けのシグナルであり、判定ではありません。2 つのファイルが同じスコアを持つ理由は まったく異なる可能性があります: 実際の問題か、表面上は同じに見える正当なパターンか。 暗号化マルウェアと十分にテストされた暗号ルーチンはどちらも高いエントロピーを生成します。 GitGalaxy はどちらを見つけたかを教えることはできません — ただ もう一度見る価値がある何かがあるということだけです。

ファインディング は個々の行レベルのフラグです: リスクしきい値を超えた特定の構造シグネチャ。 これらはレビューするための証拠であり、確認された脆弱性ではありません。 GitGalaxy はコードを実行したり、ランタイムのデータフローを追跡したり、悪用可能性を検証したりすることは決してありません — 特定の行にパターンが存在することをテキスト上で示し、 それを自分で判断するための文脈を提供します。

これは意図的であり、隠している制限ではありません。 GitGalaxy は精度よりも再現率を優先するように作られています: より多くフラグを立て、人間やより深いツールにリストを絞り込ませることで、 実際の問題に対して沈黙するリスクを避けます。偽陽性はそのトレードオフの予想されるコストであり、 これは、読み取ったコードを実行しないすべての静的アナライザーにとって 同じです。

これはまた、GitGalaxy が特定のクラスの問題に対して最も強いことを意味します — 敵対的回避ではなく、過失。 誰かが削除し忘れたハードコードされたキー、安全でないレジストリ、 明らかに危険な eval() 呼び出し — これらの相手は誰もスキャナーから隠れようとはしていません。 静的でシグネチャベースの検出がどのように機能するかを知っている動機のある攻撃者は、 エントロピーしきい値のような個々のシグナルをほとんど労力なく回避できます。 GitGalaxy を、手で読むには大きすぎるコードベースに対する高速な最初のパスとして扱ってください — 何かが安全かどうかの最終的な判断としてではなく。

証明であって、単なる主張ではない

上記の「構造シグネチャ」と「AST 不要」の主張はすべて、信頼するだけでなく、自分で検査して再実行できる 3 つのものに裏付けられています。

1. 3,649 件のシグネチャごとの回帰テスト。 gitgalaxy/standards/language_standards.py は、エンジンが構造を認識するために使用するすべての regex ルールを定義しています — 関数の開始、API 境界、安全バイパス — 実際の構造シグネチャを持つ 45 言語にわたって (合計約 1,970 のコンパイル済みパターン)。これらのルールはそれぞれ、一致すべきもの、明示的に 除外 すべきもの (ほとんどの regex ベースのツールがスキップする偽陽性チェック)、および敵対的な入力によってハングしないことについてテストされています。完全なインデックスについては tests/README.md を、それを完了させた監査については epic #518 を参照してください — その過程で理論上のカバレッジだけでなく、数十の実際の regex バグが発見され修正されました。
2. 実際の未変更の本番コードに対する真のゴールデンディフ。 language-crucible は、主要なオープンソースプロジェクトから取得した約 120 の実在するサブディレクトリの、固定・タグ付けされたスナップショットです — Godot の C++、Roslyn C# コンパイラ、curl、Kubernetes、Apollo 11 の AGC フライトソフトウェアなど — これらは意図的に切断され、コンパイル不能な状態、つまり実際のリポジトリと同じ敵対的状態に置かれています。パースエンジンに触れるすべてのプルリクエストは、そのコーパス全体を再スキャンし、出力をフィールドごとにチェックインされたスナップショット (tests/golden_master_audit.json) と差分を取ります。差分があるということは、実際のコードで出力が変更されたことを意味し、受け入れられる前に説明する必要があります — スモークテストではなく、実際のゴールデンマスター比較です。これが CI にどのように組み込まれているかは tests/README.md を、そのコーパスがなぜそのように構築されているかは language-crucible 自身の README を参照してください。

ベンチマーク

• 50+ 言語テストリポジトリ — 上記で説明したゴールデンマスターコーパスでもあり、アーティファクト も含む
• 現実世界規模での生出力 — 独立して選ばれた数百のリポジトリからの未編集のスキャン出力 (監査 JSON、SQLite、LLM ブリーフ) を、エンジンリリースごとにバージョン管理して保持
• 104 リポジトリからの速度結果
• 1000 を超えるリポジトリの言語間比較: 異なる構文アーキテクチャの決定論的 1:1 ベンチマーク。
• k-means クラスタリングによるユニバーサルファイルアーキタイプ: ファイルを K-means クラスタに分離する ML。
• メインフレーム移行: レガシー COBOL リポジトリ全体で 27/27 のコンパイル成功: 27 の異なるレガシー COBOL リポジトリ (IBM CICS ベンチマークアプリを含む) が、コンパイル可能な Java Spring Boot 環境に翻訳されました。

実世界での採用

GitGalaxy は CI 内 で実行されることを意図しており、スターをもらって忘れられるだけではありません。そのため、私たちは CI/本番統合を、人による発見と並ぶ独自の採用シグナルとして追跡し、ノイズとして除外しません。

左: GitHub のスターとフォーク (累積 — 各スター/フォーク自身のタイムスタンプから再構築されたもので、前方のスナップショットだけではありません) に加え、1 日あたりのユニーククローナー数とプロフィールビュー数。右: GitLab CI/CD カタログの使用状況 (過去 30 日間にパイプラインで GitGalaxy を実行しているユニークプロジェクト) と GitHub Action の採用状況 (ワークフローでアクションを参照しているユニークリポジトリ、コード検索による — GitGalaxy はまだ Marketplace に掲載されていないため、これが利用可能な最良のパッシブシグナルです)。左のパネルとは異なり、GitHub と GitLab はこれら 2 つの履歴を公開していないため、右のパネルはバックフィルされたトレンドではなく、日々埋まっていくことが期待されます。

PyPI、GitHub、GitLab にわたる複合配布量を、ベースラインとなるコントロールリポジトリと比較したもの — 均一に重複排除された数値ではありません。GitHub のユニーククローナー数と GitLab のユニークプロジェクト数は実際に重複排除されていますが、PyPI の公開ダウンロードデータには重複排除するための ID がありません (ミラーなしで測定されており、既知のミラー同期ボットは除外されますが、CI 駆動のインストールは除外されません)。そのため、そのコンポーネントは生のダウンロードイベント数です。GitHub/PyPI の内訳の線がウィンドウの途中から始まるのは、ソースごとの追跡が総フェッチ追跡の後に追加されたためです。その前の合計線はすべてのソースを合算したものです。

ソースごとに何が重複排除され、何がされていないかを含む完全な方法論: squid-protocol/squid-telemetry。

データプライバシーとオンプレミス展開

GitGalaxy は、スキャンとベクトル化の 100% をローカルで実行します — エンジンは同じように動作します 完全にエアギャップされた環境でも、接続された環境でも同じです。

• データ送信なし: ソースコードが API、クラウドデータベース、またはサードパーティサービスに送信されることは決してありません。
• オンプレミス / エアギャップ実行: ランタイムのネットワーク依存はありません — エンジンは完全に切断された環境でも同様に動作します。
• 一時メモリ処理 (ウェブビジュアライザー): リポジトリは揮発性メモリバッファ (RAM) に展開され、ブラウザタブが閉じられると自動的に消去されます。
• プライバシーバイデザイン: ウェブベースのビューアを使用する場合でも、データは常にユーザーのファイアウォールの背後に留まります。