Gitにおけるコミット署名方式の比較
Gitにおいて作者（author）のなりすましは驚くほど簡単です。自身のマシンで git config user.name "Linus Torvalds" と設定し、彼のメールアドレスを指定するだけで、Linuxの生みの親を騙ったコミットを誰でも作成できてしまいます。
この問題はソフトウェアサプライチェーンセキュリティ（Software Supply Chain Security）に対する直接的な脅威となります。実際にコードをプッシュしたのが誰であるかを検証するために、コミュニティでは現在主に3つのアプローチが使われています。
- 未署名コミット（Unsigned Commit）： 一切署名を行わない方式。Gitはローカルで宣言された名前やメールアドレスを無条件で信頼します。
- 長期プライベートキーによる署名（GPG / SSH）： 開発者がローカルでキーペアを生成し、プライベートキーを保持して公開キーをGitHub等に登録します。コミットごとに対応する暗号化署名が付与されます。
- 静的キーを使わない署名（Sigstore & Gitsignによるキーレス署名）： OpenID Connect（OIDC）プロトコルを活用する仕組みです。GitHub、Google、Microsoftなどのアカウントでログインすると、Fulcioが有効期間10〜15分程度のエフェメラル証明書（短期証明書）を発行してコミットに署名します。署名の全記録は透明性ログ（レジスタ）であるRekorに記録されます。
各ソリューションの実際のメリット・デメリット
KubernetesやCPythonといった多くの主要オープンソースプロジェクトが、すでにSigstoreへの移行を進めています。以下に、実際の運用現場における各選択肢の詳細な比較をまとめました。
1. 未署名（Unsigned）のまま運用
- メリット： スピーディ。新しくプロジェクトに参画した開発者も、面倒な設定なしにリポジトリをクローンしてすぐに開発へ入れます。
- デメリット： セキュリティリスクが極めて高い。悪意のある第三者がTech Leadの名前を騙ってバックドアをプッシュしても、リポジトリ側で検知できません。
2. 従来の鍵管理（GPG / SSH）
- メリット： 広く普及しており馴染み深い。GitHub、GitLab、Bitbucketなど主要プラットフォームが標準サポートしており、コミットに誇らしげな緑色の Verified バッジが表示されます。
- デメリット： 鍵の管理運用が大きな負担になります。プライベートキーのバックアップ、パスフレーズの管理、有効期限の追跡が必要です。メンバーの退職に伴う失効処理も煩雑で、失効証明書を準備せずに秘密鍵を紛失した場合は失効すら困難になります。万が一鍵が漏洩した場合、チームが気づかないうちに攻撃者に悪意あるコードを署名されてしまうリスクもあります。
3. Sigstore & Gitsign によるキーレス署名
- メリット： ローカルディスクにプライベートキーを永続保存しません。鍵漏洩の心配がなく、アイデンティティは企業のSSOアカウントや個人のOAuthに直接紐づきます。Fulcioが10〜15分間のみ有効な一時証明書を発行してコミットに刻印し、即座に破棄。署名の追跡ログはすべてRekorに改ざん不可能な形で保存されます。
- デメリット： OIDCログインのためにブラウザ経由のネットワーク接続が必要です。オフライン環境のCI/CDランナーやエアギャップ環境では、組織内部にFulcioやRekorのクラスタを独自構築する必要があります。
ユースケースに応じた最適な選択基準
プロジェクトごとにインフラ環境や要件は異なります。システムの性質に応じて以下を検討してください。
- GPG/SSHを選ぶべきケース： 完全にインターネットから隔離された環境での運用、または社内規定によりYubiKeyなどの物理セキュリティキーの使用が義務付けられている場合に適しています。
- Gitsign（キーレス）を選ぶべきケース： チーム全体で鍵のインポートや更新の手間に煩わされることなく、統一された署名運用を行いたい場合に最適です。モダンなDevOpsチームやOSSリポジトリにとって理想的な選択肢となります。
プロセスが複雑になればなるほど、開発者は抜け道を探そうとするものです。毎日何十回もパスフレーズの入力を求められれば、面倒になって署名機能ごとオフにしてしまうのが関の山です。Gitsignはこのジレンマをスマートに解消し、Sigstore基準の堅牢なセキュリティと快適な開発体験を両立します。
Gitsignの導入と設定手順
Gitsignは、Git組み込みの gpg バイナリを直接置き換えるためにSigstoreが開発したCLIツールです。LinuxおよびmacOSでのセットアップは非常にシンプルです。
ステップ1：Gitsignバイナリのインストール
macOSの場合はHomebrewを使用します：
brew install gitsignLinux（Ubuntu/Debian）の場合は、GitHubから直接最新のリリースバイナリを取得します：
# 最新バージョンのタグを取得
VERSION=$(curl -s https://api.github.com/repos/sigstore/gitsign/releases/latest | grep tag_name | cut -d '"' -f 4)
curl -LO "https://github.com/sigstore/gitsign/releases/download/${VERSION}/gitsign_${VERSION#v}_linux_amd64.tar.gz"
# 解凍してPATHの通ったディレクトリへ配置
tar -xvzf "gitsign_${VERSION#v}_linux_amd64.tar.gz" gitsign
sudo mv gitsign /usr/local/bin/
gitsign --versionステップ2：GitでGitsignを使用するための設定
Gitでは gpg.x509.program 設定を通じて署名プログラムを切り替えることができます。先ほどインストールした gitsign バイナリを指定します：
# コミットおよびタグの自動署名を有効化
git config --global commit.gpgsign true
git config --global tag.gpgsign true
# X.509証明書フォーマットを設定し、Gitsignを指定
git config --global gpg.format x509
git config --global gpg.x509.program gitsignステップ3：コミットの実行とOIDC認証
セットアップが完了すれば、あとは普段通りに作業を進めるだけです。コミットコマンドを実行すると：
git add .
git commit -m "feat: implement authentication flow"Gitsignが自動的にブラウザのタブを開き、OIDCログインを要求します：
[gitsign] Opening your browser to authenticate with Sigstore...
[gitsign] Successfully authenticated! Ephemeral certificate issued.GoogleまたはGitHubアカウントを選択するだけで完了です。GitsignがFulcioから短期証明書を取得し、git config user.email と一致するメールアドレスでコミットに署名して透明性ログに記録します。
ステップ4：コミット署名の検証
コミットに正しい署名が付与されているか確認するには、次のコマンドを実行します：
git log -1 --show-signatureX.509証明書の情報、発行者、およびRekorのログインデックスが出力されます：
commit a1b2c3d4e5f67890123456789abcdef012345678
gitsign: Valid signature from: [email protected]
gitsign: Issuer: https://github.com/login/oauth
gitsign: Rekor log index: 12948210
Author: Developer <[email protected]>
Date: Sun Oct 11 08:30:00 2026 +0700
feat: implement authentication flowTips：クレデンシャルキャッシュを有効化してブラウザの起動頻度を抑える
コミットのたびにブラウザが立ち上がるのが煩わしい場合は、認証情報キャッシュを有効にしてセッションを1時間保持することができます：
git config --global gitsign.connectorID "https://github.com/login/oauth"
gitsign cache enable業務開始時に一度ログインしておけば、その後のコミットは即座に署名され、透明性を保ちながら1秒未満の高速レスポンスで快適に開発できます。
