「Verified」コミットの欠陥：なぜGitHub/GitLabはサプライチェーンセキュリティにおいて不十分なのか

ソフトウェア・サプライチェーン攻撃は重大な懸念事項となっており、開発のあらゆる段階における堅牢なセキュリティ対策の重要性が浮き彫りになっています。コードの完全性を確保するための基本的な側面はコミット署名であり、これは変更の作成者と真正性を検証することを目的としています。しかし、GitHubやGitLabのような主要なGitプラットフォームにおいて、コミット署名の実装と強制方法に重大なギャップが存在しており、既存の「Verified」バッジを回避できる巧妙な攻撃に対して組織を脆弱なままにしています。

この問題は、プラットフォームが特定の署名鍵を強制できないことに起因しており、攻撃者が正当な「検証済み」コミットを装ってリポジトリに悪意のあるコードを注入することを可能にしています。本記事では、現在のコミット署名による保護の限界、人気のあるプラットフォームに欠けている機能、そしてこれらのセキュリティ上の欠陥を補うために開発チームに課せられる多大な負担について探ります。

「Verified」コミットの錯覚

GitHubとGitLabは「Require signed commits」機能を提供しており、一見すると、リポジトリにプッシュされたすべてのコミットがコミッターのアカウントに関連付けられた鍵で署名されていることを保証することで、セキュリティを強化しているように見えます。しかし、この保護は根本的に欠陥があります。もし攻撃者が開発者のノートPCやGitHub/GitLabのアカウントを乗っ取った場合、そのアカウントに新しい署名鍵を追加するだけで済みます。この新しい、権限のない鍵を使用して、攻撃者は悪意のあるコミットをプッシュできますが、それらは依然として切望される「Verified」バッジを受け取ることになります。

このシナリオは重大な盲点を作り出します。「Verified」バッジは、信頼の証として意図されていますが、サプライチェーン攻撃の潜在的なベクトルとなってしまいます。この機能だけに頼っている組織は、誤った安心感を得ることになり、悪意のあるコードが正当なものに見えながら、コードベースにシームレスに統合されてしまう可能性があります。

プラットフォーム機能における決定的なギャップ

核心となる問題は、GitHubとGitLab内におけるきめ細かな制御と強制メカニズムの欠如にあります。具体的には、これらのプラットフォームは現在、以下を提供していません：

組織レベルでの承認済み署名鍵の許可リスト（allowlists）: 組織が、コミットに署名することを許可するのみの承認済み署名鍵（例：組織が発行したハードウェアベースのYubiKeysなど）を指定し、強制する組み込みの方法がありません。
署名鍵そのものに基づくプッシュの拒否: プラットフォームは、たとえ正当なユーザーアカウントに関連付けられていても、コミットが承認済み許可リストにない鍵で署名されている場合に、プッシュを自動的に拒否するように設定することができません。
鍵のアクセスに関する組み込みの、きめ細かな監査: 組織は、誰が何にアクセスしたかを理解するために、監査ログを自身でストリーミングし、解析する必要があります。そのため、権限のない鍵の追加や使用を効率的に検出することが困難です。

これらの欠けている機能があるため、「Require signed commits」を有効にしても、単一の乗っ取られた開発者アカウントを通じてGitの履歴の完全性が侵害されるリスクが残ります。

現在の回避策の限界

これらのプラットフォームの制限に仕舞い、多くの組織は以下のような回避策に頼っています：

継続的インテグレーション（CI）パイプラインでの署名再検証: これは、CIにおいて、内部の許可リストとコミット署名を照合して再チェックするステップを追加することを意味します。
承認されていない鍵によるデプロイのブロック: CIが権限のない鍵で署名されたコミットを検出した場合、デプロイを停止します。
セルフホスト型のGitをpre-receiveフックで運用: カスタムフックをセルフホスト型のGitインスタンスに実装し、コミットがリポジトリに届く前に署名鍵のポリシーを強制します。

これらの回避策は、ある程度の検出や防止を提供しますが、すべてに決定的な欠陥があります。それは、悪意のあるコミットが依然としてリポジトリに届いてしまうことです。CIは「事後」にそれを検知します。つまり、たとえデプロイが阻止されたとしても、乗っ取られたコードはすでにコードベースに統合されてしまっています。真のサプライチェーンセキュリティの目的は、悪意のあるコードが信頼できるリポジトリの履歴に決して入らないようにすることであり、この「事後」の検出では不十分です。

組織への負担

これらの基本的なセキュリティ機能の欠如は、組織、特に小規模な開発チームにとって、ソフトウェア・サプライチェーンを保護するために多大なリソースを投入する多大な努力を強るいるものです。これには以下が含まれます：

すべての開発者にハードウェア・セキュリティ・キー（例：YubiKeys）を配布すること: 実務的および財務的に大きな負担となります。
カスタムの検証および監査パイプラインの構築: 鍵のポリシーを強制し、活動を監視するための独自のシステムを開発することです。
監査ログをSecurity Information and Event Management (SIEM)システムにストリーミングすること: ログの解析とアラート通知のために、追加のインフラストラクチャと専門知識が必要になります。

「標準的なセキュリティ機能」として認識されるべきものに対して、これほどのレベルの努力が必要となることは、大きな不満の源となり、リソースをコアの開発やイノベーションから逸らしてしまうことになります。

プラットフォームによるさらなるサポートへの呼びかけ

現在の状況は、現代の開発におけるセキュリティニーズと、主要なGitプラットフォームの提供機能との間の決定的な乖離をうらつしています。GitHubのようなプラットフォームは、AIを活用したコーディング・アシスタントなどの機能に多大な投資を行っていますが、「Verified」サプライチェーン攻撃を防ぐための基本的なセキュリティ・メカニズムは未解決のままです。組織は、プラットフォームが以下のような堅牢で組み込みの機能を提供することを求めています：

特定の、組織が承認した署名鍵の強制。
ゲートウェイにおいて、これらの鍵の要件を満たさないプッシュを拒否すること。
鍵の管理と使用に関する、透明かつ実行可能な監査トレイルを提供すること。

これらの機能がなければ、単一の乗っ取られた開発者アカウントを通じて「Verified」サプライチェーン攻撃を回避する脅威は、世界中の開発チームにとって、具体的かつ差し迫った懸念事項であり続けます。Gitのログと履歴の完全性を確保することは、プラットフォーム・プロバイダーにとって最優先事項であるべきです。