GitHubやGitLabの設定、放置してない？「Legitify」でSCMのセキュリティリスクをサクッと診断してみた
はじめに
こんにちは。
SAST（静的解析）やDAST（動的解析）、コンテナイメージスキャン、依存関係の脆弱性チェックなど、「コードやコンテナのセキュリティ」については普段から耳にする機会が多いかと思います。
ですが、「SCM（ソースコード管理ツール）そのものの設定」 については、皆さん意識できているでしょうか？
- リポジトリのパブリック/プライベート設定くらいしか意識していない…
- そもそも設定画面（Settings）をまともに見たことがない…
- 組織の権限設定の都合で見られない人もいれば、個人開発で一度も設定を開かずに終わる人もいるかも…？
コードやイメージをどれだけ頑丈に固めていても、GitHub/GitLabの設定がガバガバ（例: デフォルトブランチに誰でも直接Push可能、コードレビューの強制なしなど）であれば、そこが致命的な弱点になってしまいます。
そこで「SCM設定周りをサクッと診断できるツールはないかな？」と探してみたところ、良さそうなツールを見つけたので検証してみました。
その名も……「Legitify」！！
「…初耳？」と思った方、安心してください。私も初耳でした。
Legitifyは、Legit Security社が公開しているオープンソースのCLIツールで、GitHub/GitLabの組織・リポジトリ・メンバー・Actions・Runner Groupの設定ミスを検出し、対処手順を提示してくれます。
ASPMとLegitifyの位置付け
また新しいアルファベットの羅列かよ！と突っ込みたくなりますが、この分野では ASPM という言葉が使われているようです。
ASPMとは？
ASPM（Application Security Posture Management：アプリケーションセキュリティポスチャマネジメント） とは、コード、CI/CDパイプライン、SCMの設定、依存関係など、アプリケーション開発におけるセキュリティリスクを総合的に可視化・管理する仕組みやツールを指します。
Legitifyはどこに当てはまる？
Legitifyを開発しているLegit Security社は、自社をASPMおよびソフトウェアサプライチェーンセキュリティのソリューションと位置付けています。一方、オープンソース版のLegitifyが検出対象とするのは SCMの設定ミスのみ です（公式READMEより）。
つまりLegitifyは、ASPMが扱う領域のうち「SCMのセキュリティポスチャマネジメント」を手軽に診断できるツール、と捉えれば良いかと思います。CI/CD、シークレット、IaCなどまで横断的に管理したい場合は、有償のLegit Security Platformなど、より包括的な製品の出番になります。
似たようなツール
今回検証したLegitifyのほかにも、以下のようなツールが存在します。
- Chain-bench（Aqua Security）: CIS Software Supply Chain ベンチマークに基づき、SCMを含むソフトウェアサプライチェーン全体のセキュリティ準拠状況を監査するツール
- Steampipe: SQLを使ってクラウドやGitHubなどの設定をクエリ・監査できるツール
Legitify のよくある疑問
実際に使ってみる前に、気になるポイントを調べてみました。
Q. チェックリスト（ポリシー）のソースは何？
Legitifyは OPA（Open Policy Agent） をベースに構築されており、ポリシーは Rego という言語で書かれています。ポリシーはLegit Security社が実運用の経験と業界のベストプラクティスをもとに作成したもので、公式READMEでは準拠先のコンプライアンス基準として OpenSSF の SCM Best Practices が挙げられています。各ポリシーの説明・重要度・想定される脅威・対処手順は legitify.dev で確認できます。
Q. 独自ポリシーは追加できる？
追加可能です。 Rego形式で書いたポリシーを格納したディレクトリを --policies-path（-p）オプションで指定すると、組織独自のセキュリティルール（「特定のトピックのタグ付けを必須にする」など）を追加できます。
※ このフラグは現行READMEには記載がないため、お使いのバージョンで legitify analyze --help を実行してフラグ名を確認してください。
逆に、特定のポリシーを対象外にしたい場合は --ignore-policies-path で除外リスト（1行に1ポリシー名）を渡せます。
Q. スキャン時に外部へデータが送信されたりする？
Legitifyは手元の環境で動作するCLIで、GitHub/GitLabのAPIから設定情報を取得し、ポリシーの評価も手元で行います。筆者が確認した範囲では、通常の analyze でLegit Security社のサーバへ解析結果を送るような仕組みは見当たりませんでした。
ただし gpt-analysis コマンドを使う場合は、リポジトリ/組織のメタデータがOpenAIのサーバに送信される と公式READMEに明記されています。社内リポジトリで使う際は注意しましょう。
インストール方法
インストール方法はいくつかあります。今回はバイナリを直接配置する方法で進めます。
リリースページからバイナリを取得
Legitifyのリリースページ から、環境に合ったパッケージをダウンロードします。執筆時点の最新版は v1.0.11 です。アーカイブにはバイナリと組み込みポリシーが含まれています。
パッケージのダウンロード（Linux / amd64 の例）
curl -LO https://legitify.legitsecurity.com/1.0.11/linux/amd64.tar.gz
パッケージの解凍
tar -zxvf amd64.tar.gz
パスの通った場所へ移動
mv legitify /usr/local/bin/
動作確認
ヘルプコマンドを実行して、アスキーアートとともに以下のような出力が得られれば準備完了です！
事前準備：Personal Access Token（PAT）を用意する
LegitifyはGitHubのAPI経由で設定情報を取得するため、GitHubのPersonal Access Token（PAT）が必要 です。トークンは -t オプションか、環境変数 SCM_TOKEN で渡します。
必要なスコープ
フル解析には、Classic PAT で以下のスコープが必要です。
admin:org, read:enterprise, admin:org_hook, read:org, repo, read:repo_hook
- 組織の設定まで診断するには、少なくとも1つのGitHub組織のオーナー権限が必要です。リポジトリの管理者権限だけの場合は、リポジトリ関連のポリシー結果のみが表示されます。
トークンの取り扱いに注意
admin:org などの強い権限を含むトークンになるため、以下を意識しておくと安心です。
- 有効期限を短めに設定し、診断が終わったら失効させる
- シェル履歴にトークンを残さないよう、環境変数で渡す
read -s SCM_TOKEN && export SCM_TOKEN
テスト用リポジトリのセキュリティチェックをしてみる
今回はテスト対象として、個人のサンプルリポジトリをスキャンしてみました。--repo で対象リポジトリを絞り込めます（複数ある場合はカンマ区切り）。
$ legitify analyze --repo k-magruder/chat-app-demo
違反のみを表示したい場合は --failed-only、結果をファイルに保存したい場合は --output-format json --output-file result.json のように指定できます。SARIF形式での出力にも対応しています。
検出結果のピックアップ（一部抜粋）
スキャンを実行すると、検出されたセキュリティ課題（Violations）と具体的な対処手順（Remediation Steps）がずらりと出力されます。
1. コードレビューが必須化されていない（Severity: HIGH）
Default Branch Should Require Code Review 誰でもコードレビューなしでメインブランチにマージできてしまう状態です。 対策: リポジトリの
Settings > Branchesでブランチ保護ルールを作成し、「Require a pull request before merging」を有効化して承認人数を1以上に設定します（Settings > Rules > Rulesetsのルールセットでも同様の設定が可能です）。
2. リポジトリの長期未更新（Severity: HIGH）
Repository Should Be Updated At Least Quarterly 長期間更新されていないため、依存ライブラリに未修正の脆弱性が残っている可能性があります。 対策: メンテナンスしない場合はアーカイブ化するか削除を検討します。
3. GitHub Advanced Security の依存関係レビューが無効（Severity: MEDIUM）
GitHub Advanced Security – Dependency Review Should Be Enabled For A Repository 対策: リポジトリの Settings にあるセキュリティ設定のタブ（Legitifyのドキュメントでは「Code security and analysis」）で Dependency graph を有効化します。
※ GitHubのUI変更により、タブ名が異なる場合があります。
診断結果サマリー
診断の最後には、以下のようなテーブル形式でサマリーが出力されます。Skipped は、今回スキャンしたレポジトリがパーソナルアカウント配下にあるレポジトリであったり、フリープランを使用していた等のため評価できなかったポリシーです。
Legitify Findings Summary: +----+------------+--------------------------------+----------+--------+--------+---------+ | # | Namespace | Policy | Severity | Passed | Failed | Skipped | +----+------------+--------------------------------+----------+--------+--------+---------+ | 1 | repository | Workflows Should Not Be | HIGH | 0 | 0 | 1 | | | | Allowed To Approve Pull | | | | | | | | Requests | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ | 2 | repository | Default Branch Should Require | HIGH | 0 | 1 | 0 | | | | Code Review | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ | 3 | repository | Repository Should Be Updated | HIGH | 0 | 1 | 0 | | | | At Least Quarterly | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ | 4 | repository | Default Branch Should Require | MEDIUM | 0 | 1 | 0 | | | | Code Review By At Least Two | | | | | | | | Reviewers | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ | 5 | repository | GitHub Advanced Security – | MEDIUM | 0 | 1 | 0 | | | | Dependency Review Should Be | | | | | | | | Enabled For A Repository | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ | 6 | repository | Default Branch Should Be | MEDIUM | 0 | 1 | 0 | | | | Protected | | | | | +----+------------+--------------------------------+----------+--------+--------+---------+ （以下略）
個人用のサンプルプロジェクトということもあり、ブランチ保護ルールを一切作っていなかったため、見事に多くの項目で Failed（違反）判定となりました！
まとめ
今回「Legitify」を試してみて感じたポイントは以下の通りです。
- PATを用意すれば、CLIコマンド1つでSCMのセキュリティ状態が丸裸になる
- 「どこをどう設定し直せばいいか」のRemediation Stepsが明確に出る
- 手元の環境で動くCLIなので、会社のリポジトリでも試しやすい（
gpt-analysisを使う場合を除く） - GitHub Actionsに組み込めば、定期的な設定ドリフトの検知にも使える
一方で、導入前に知っておきたい注意点もあります。
- 強い権限（
admin:orgなど）を持つ Classic PAT が必要で、Fine-grained PAT は非対応 - 最新リリース（v1.0.11）は2024年7月、最終更新は2025年3月で、更新頻度は高くない
コードの脆弱性対策はもちろん重要ですが、リポジトリや組織全体の設定（ブランチ保護ルールや権限管理）という「土台のセキュリティ」も忘れてはいけません。
Legitifyを使えば数分で現状の健康診断ができるので、気になった方はぜひ手元のリポジトリや組織アカウントで試してみてください！
