Gitコミット署名は安全性を高めるか？署名と検証能力の乖離を追った長期調査 • vonxai blog

ソフトウェアサプライチェーン攻撃の増加に伴い、コミットの改ざんやなりすましを防ぐ手段としてGitコミット署名の導入が進められています。コミットに署名を付与する運用は広く推奨されているものの、署名が実際に行われていることと、開発者がその署名を適切に検証してセキュリティ上の判断を下せるかどうかは別の問題です。

本記事では、米国テネシー大学の研究者であるAbubakar Sadiq Shittu氏らによる2026年の研究論文「A Multi-Month Study of Git Commit Signing」を取り上げます。

3か月にわたるGitコミット署名運用の追跡調査

本研究は、大学の応用暗号学コースの課題として実施され、22名の学生（学部上級生および大学院生）から研究参加の同意を得てデータを分析しました。参加者は暗号技術やGitの基本知識を持つ層であり、ソフトウェア開発組織に参入する若手エンジニアに近いスキルセットを有しています。

調査では、初期設定のみで終わらせず、約3か月の講義期間中に4つの開発プロジェクトを通じてコミット署名を継続させました。さらに、学期末には「2台目の端末への鍵の移行」「悪意のある異常コミットが含まれたリポジトリの検証」「鍵管理や署名の保証範囲に関する記述式質問」を実施し、開発者が直面する運用上の障壁を総合的に評価しています。

日常的な署名の定着と設定時のトラブル

調査の結果、一度環境を構築してしまえばコミット署名の日常運用自体はスムーズに定着することが確認されました。しかし、初期設定や環境移行の段階では、多くの参加者がツールの仕様やフィードバック不足によるトラブルに直面していました。

日常利用の定着と高い満足度

学期末におけるシステムユーザビリティスケール（SUS）の平均スコアは77.61（100点満点中）であり、「良好」に分類される評価でした。参加者の81.8％（18名）が観察されたすべてのコミットに署名を行っており、日常の開発フローにおいて署名コマンドを実行すること自体は負担になりにくいことが示されています。

多くの参加者は「日常の署名は通常コミットとほぼ変わらず自動的だった」と回答しており、日々のコーディング速度を大きく落とす要因にはなりませんでした。

初期設定でつまずいた具体的な要因

一方で、初期設定では試行錯誤が見られました。参加者の36％（8名）が最初のコミット作成までに複数のコミット履歴を残しており、環境構築に手間取った様子が記録されています。主な問題点として以下が報告されています。

SSH signersファイルの構造不一致：SSH署名を利用した参加者において、Gitが要求するallowedSignersFileのフォーマット（<email> <key_type> <key>）と、ssh-keygenが生成する公開鍵の並び順（<key_type> <key> <email>）が異なるため、設定ミスと検証失敗が発生しました。Gitから具体的なエラーが出ないこともデバッグを難しくしました。
Git側の署名鍵未指定：鍵を生成したものの、Gitの設定（user.signingkeyやgpg.format）を更新しなかったため、コミット時に鍵が正しく読み込まれませんでした。
macOSにおけるパスフレーズ入力の不具合：macOS環境でGPGを利用した際、ターミナル上でパスフレーズ入力プロンプトが表示されず、外部ツール（pinentry-mac）の追加設定が必要になる事象が発生しました。

2台目の端末への移行で発生した課題

学期末に別の端末へ署名環境を展開する課題では、参加者の選択が「既存の秘密鍵のコピー（12名）」と「新規鍵ペアの生成（10名）」に分かれました。

表1：端末移行方針別の満足度と所要時間の比較

項目	全体（n=22）	既存鍵のコピー（n=12）	新規鍵の生成（n=10）
ASQ評価平均（標準偏差）	5.32 (1.51)	5.28 (1.77)	5.37 (1.20)
所要時間幾何平均［中央値; 四分位範囲］（分）	51.04 ［42.50; 67.50］	51.33 ［52.50; 78.75］	50.69 ［40.00; 30.00］

どちらの方針を選択しても所要時間（幾何平均約51分）や満足度に統計的な有意差は見られませんでした。新規鍵を生成したグループは端末ごとに独立した鍵を持つことで安全性を重視した一方、初期設定と同じ構成手順をゼロから繰り返す必要がありました。一方、鍵をコピーしたグループは秘密鍵のエクスポート・インポート手順や、GPGでインポートした鍵に対する明示的な信頼度設定（trust level）が必要になるなど、ドキュメントに記載が少ない操作で停滞していました。

署名しても検知できない？改ざんコミット検証の限界

本研究の最も注目すべき発見は、日常的に署名を行っていた開発者であっても、他者のリポジトリに含まれる不正なコミットを検証によって見つけ出すことが困難だった点です。

異常コミットの検出率

参加者には、全20コミット中に13件の不正な変更（未知の開発者、タイムスタンプ改ざん、作者とコミッターの不一致、異なる署名鍵の使用、署名抜け）を意図的に組み込んだリポジトリが渡され、正規の開発者2名の公開鍵フィンガープリントを手がかりに検証が求められました。

表2：問題のあるコミットの種別と検出率

異常の種別	該当コミット数	検出率（n=22）
未知の開発者によるコミット	3	12/22 (55%)
タイムスタンプの改ざん	2	9/22 (41%)
作者とコミッターの不一致	2	9/22 (41%)
不正な署名鍵による署名	1	11/22 (50%)
署名の欠落	5	11/22 (50%)

参加者が検出できた問題コミットの平均数は13件中わずか4.77件（中央値3.50件）にとどまりました。さらに、参加者の27.3％（6名）は問題のあるコミットを1件も検出できず、13件すべてを発見できた参加者は一人もいませんでした。

なぜ検証作業は失敗したのか

検証が困難だった背景には、ツールの使いづらさと概念の混同が複合的に絡み合っていました。

検証ツールの設定難度：正規の開発者のSSH鍵を検証するには、ローカルにallowedSignersFileを用意して紐付ける必要があります。この設定を完了できた8名は平均9.12件の異常を検出できたのに対し、設定できなかった14名は平均2.29件しか検出できませんでした。
暗号学的検証の放棄：設定に失敗した参加者のうち6名は、暗号署名の検証そのものを諦めました。その結果、コミットの検出スコアは平均1.50件まで落ち込みました。
コード内容の目視確認への逃避：署名検証に苦戦した参加者の一部は、コードの差分を目視で確認し、「不審なキーワード（eval関数やAPIキーの露出など）がないか」をgrepで探す手法に頼りました。その結果、ある参加者は「差分コードに明らかな悪意が見当たらなかったため、このリポジトリのコミットに問題はないと判断した」と報告しました。署名が正規のものであるかどうかの確認が、コード内容の安全性チェックと混同されていた例です。

半数近くに見られた鍵管理とセキュリティの誤認

学期末に実施された5つの記述式設問により、参加者の45％（10名）がコミット署名のセキュリティ特性や鍵管理に関して少なくとも1つの誤解や誤った認識に基づいた回答をしていました。

「秘密鍵を紛失すると過去のコミットが検証できなくなる」という誤認（3名）：秘密鍵を失っても、公開鍵が残っていれば過去の署名の検証は可能です。署名処理と検証処理の非対称性が正しく区別されていませんでした。
「SSHプッシュ認証があるためコミット署名は不要」という誤認（1名）：リポジトリへの通信接続を認証するSSH接続鍵と、コミット内容そのものの同一性・作成者を保証する署名鍵の違いが混同されていました。Gitのコミットメタデータ（作者名やメールアドレス）はプッシュ権限があれば自由に偽装可能です。
「鍵漏洩の対策としてリポジトリ移行やアカウント再作成を行う」という誤認（2名）：秘密鍵が窃取された場合に必要なのは鍵自体の失効手続きですが、アカウントやリポジトリの再作成といった別レイヤーの対応で済ませようとする回答が見られました。
「署名鍵の再利用はセキュリティ上悪手である」という誤認（1名）：セッション鍵や暗号化鍵の再利用禁止ルールを、同一人物が繰り返しコミットに署名するための公開鍵署名に誤って適用していました。

開発チームで参考にできる観点

本研究の結果は、Gitコミット署名を導入する開発チームに対しても同様に言えることがあります。

署名をつけることと正しく検証することは異なる

コミットログを調査して「署名付きコミットの割合」を集計するだけでは、リポジトリの安全性を測る指標としては不十分です。開発者が署名を行う習慣を身につけていても、取り込むコードの署名を誰がどのように検証しているかが定義されていなければ、なりすましや不正な改ざんを見逃すリスクが残ります。

個人任せの手動検証には限界がある

Git標準のCLIを用いた手動の署名検証は、allowedSignersFileの構築や鍵の探索など手順が複雑であり、開発者の作業負担が大きくなります。結果として暗号検証を諦め、コミットメッセージやコードの見た目による確認に後退してしまう傾向が観察されました。

開発組織においては、個々の開発者のローカル環境での手動検証に依存するのではなく、CI/CDパイプラインやブランチ保護ルール（署名付きコミットの必須化や信頼済み公開鍵リストとの自動突合）による機械的な検証フローを整えることが現実的な対策として考えられます。

鍵のライフサイクルと脅威モデルの共有

開発者が「なぜ署名が必要なのか」「通信認証と何が違うのか」「鍵を紛失・漏洩した際にどのレイヤーで対処すべきか」を正しく理解していない場合、誤った安全宣言を行ったり、漏洩時の対処を誤ったりする可能性があります。ツールを導入するだけでなく、コミット署名が防ぐ脅威と防がない脅威の境界を開発チーム内で明確にしておくことが有益です。

まとめ：署名の習慣化から適切な検証プロセスの確立へ

本研究は、Gitコミット署名の日常利用が定着しやすい一方で、署名の検証手順の複雑さや暗号技術に対する概念的な誤解が大きな障壁となっている実態を明らかにしました。

開発者が日常的にコミットへ署名を行うようになったとしても、それだけでサプライチェーンの安全性が担保されるわけではありません。適切な検証手順がツールやCIによって支援され、開発者自身がコミット署名の保証範囲を正しく理解して初めて、なりすましや不正改ざんに対する防御が機能します。

署名機能の有効化にとどまらず、検証の自動化と運用方針の周知をセットで進めることが、開発チームにおけるセキュリティ強化の重要な観点となります。

Webサービスや社内のセキュリティにお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！

参考資料：

A Multi-Month Study of Git Commit Signing