本文の内容は、2023年2月8日にMICHAEL ISBITSKIが投稿したブログ（https://sysdig.com/blog/github-supply-chain-risks)を元に日本語に翻訳・再構成した内容となっております。 オープンソースプロジェクトgitのコントリビューターメンバーは、2022年6月に、デフォルトのファイル圧縮方法をgzipプログラムから内部のgzip互換の実装に変更するコードをデプロイしました。この変更は、パフォーマンス上の理由と、老朽化したgzipプロジェクトへの依存度を下げるために行われました。残念ながら、この変更はGitHubのようなGitを基盤とするSaaSサービスにも影響を及ぼしました。しかし、GitHubはこの変更をデプロイし、2023年1月にすぐにロールバックすることを余儀なくされました。このシナリオは、オープンソースソフトウェアの隆盛、サプライチェーンの入れ子構造、安全なデリバリーへの影響を浮き彫りにしています。あなたが詩人なら、『For Want of a Nail』はここにぴったりです。最もシンプルな言葉で言えば、小さなことが非常に大きな影響を及ぼすことがあるのです。
gitとは何ですか？GitHubとどのような関係があるのですか？
GitHubは人気のある開発者向けツールとしてよく知られているかもしれませんが、gitそのものやそれを使う理由は、実務者以外ではそれほど知られていません。Gitは、バージョン管理システムおよびソースコードレポジトリとして一般的に使用されています。テキストを中心としたあらゆるファイルを保存・整理し、バージョン管理をより容易に行うことができます。このような理由から、gitは現代のアプリケーションやシステム開発のためのソースコード・リポジトリとして秀でています。Gitは、AWS CodeCommit、Azure Repos、GitHub、GitLabなど、多くのサービス・プロバイダーにも再利用されています。何が起きたのか？
この変更により、ソフトウェアのサプライ・チェーン・セキュリティの重要な側面、特に整合性チェックが壊れました。技術的な問題としては、圧縮アルゴリズムによって生成されたファイルのハッシュやチェックサムも変化してしまうことが挙げられます。これにより、ハッシュ比較に依存し、悪意のある者がソフトウェアに未承認または予期せぬコンポーネントを挿入していないことを検証する、あらゆる整合性チェック機構が破壊されます。これは、マルウェアの脅威の一部を軽減するための一般的なアプローチです。また、バージョン管理、インフラストラクチャーの自動化、安全な継続的デリバリー、ソフトウェアの更新、パッチ、オペレーティングシステムの更新など、多くのITプロセスにおいて整合性チェックは重要な役割を担っています。
Githubのgzip問題がサプライチェーンにもたらすもの
チェックサムは、誰かがオリジナルのソースコードやファイルを変更しない限り、一貫性を保つべきです。この動作はハッシュアルゴリズムの設計によるものであり、コードの統合性や信頼性を確保するための基礎となるものです。整合性検証のためにチェックサムを使うどんなツールも、 gzipの変更によって更新されたハッシュを考慮しなければならないでしょう。コミュニティはその影響について分裂しているようです。最初のコード変更からほぼ6ヶ月が沈黙のうちに過ぎました。しかし、GitHubがより新しいgitコードにデプロイした後、異論を唱えるコメントが殺到し始めました。これは、gitコミットの履歴で確認することができます。
なぜ今、気にする必要があるのか？
アジャイルな方法論やDevOpsのプラクティスでは、gitベースのバージョン管理やワークフローがパズルの一部となるため、頭痛の種となります。具体的には、バージョン管理、継続的インテグレーション、継続的デリバリーが影響を受けます。この変更は、インフラストラクチャー・アズ・コード、ポリシー・アズ・コード、コンテナ・イメージ、ソースコードなどの整合性を確認する方法に影響します。 GitHubのgzip問題は、商用サービスの基盤が依然としてオープンソースを使用しており、オープンソースが現代のソフトウェアサプライチェーンに不可欠であることを思い出させるものです。一部のエンジニアはgitコードリポジトリのインスタンスを自分でデプロイして管理していますが、バージョン管理に参加している人は皆gitを使ってGitHubのようなgitベースのサービスとやり取りしています。 このような変更には、大きな悪影響があります。それは、組織のビルド、デリバリー、リリースプロセスの安定性を阻害する可能性があります。CI/CDビルドパイプラインを経由するものすべてが疑われたり、リスクがあるとみなされたりする可能性があります。この出来事は、多くの組織がソフトウェアのサプライチェーンのリスクについて深刻な懸念を抱いているときに起こりました。どうしてこのようなことが起こり続けるのでしょうか？
このGitHubのgzip問題の場合、誰が責任を負うのでしょうか？gitオープンソースプロジェクトのコントリビューターは、2022年6月にこの変更を行いました。GitHubはずっと後の2023年1月に変更を行ったが、その影響を十分に考慮していなかったようです。 現実には、オープンソースプロジェクトには、変更ログやドキュメントの作成以上に、変更を伝え、調整するためのリソースがないのが普通です。大規模なプロジェクトであっても、専任のフルタイム開発者はごく少数に限られるかもしれません。より一般的には、開発者は時間外に余裕があるときにコントリビュートします。あるいは、オープンソースの推進者である組織で働いている場合、彼らは自分の時間の一部を特定のプロジェクトに捧げているかもしれません。オープンソースの利用者は、コードの変更とその潜在的な影響を理解する責任があります。 これらは、オープンソースプロジェクトと、独立系ソフトウェアベンダーまたはソフトウェアパブリッシャーとしてのビジネスとの根本的な違いです。ベンダーは、オープンソースソフトウェアの開発とメンテナンスにおいて、より積極的な役割を果たすべきでしょうか？オープンソースコミュニティと商業パートナーとの間で責任を共有することは可能でしょうか？これらの疑問は、ソフトウェアのサプライチェーン・セキュリティのジレンマの一部として対処される必要があります。NSA の Enduring Security Framework (ESF) や CISA の Information and Communications Technology Supply Chain Risk Management (ICT SCRM) のような取り組みが、この会話を深めるのに役立っています。ITとセキュリティのリーダーが求めるべきなのは、どのような点なのでしょうか？
利用者は、システムの動作に依存することになります。組織は、上流の変更を慎重に評価するだけでなく、予想される動作の検証にも投資する必要があります。このシナリオは、完全に内部またはクローズドソースの依存関係でデプロイされた可能性もあります。 GitHubのようなプロバイダが圧縮方法を入れ替えるgitコードの変更をデプロイした場合、アーカイブのチェックサムに再び影響を与えることになります。組織は、変更ログとドキュメントを厳重にレビューする必要があります。しかし、”マニュアルを読む” 人はほとんどいないでしょう。変更があまりにも頻繁であったり、すべてをレビューするのに十分なリソースがなかったりするため、この実践は必ずしも運用上、現実的ではありません。この問題は、すぐにソフトウェア部品表（SBOM）の継続的な検証に関する議論に発展しますが、ソフトウェアのサプライチェーン全体に、必要な技術の断片がまだすべて存在しているわけではありません。準備のためにできるステップは以下の通りです。- git リポジトリからのソースの取得に依存しているサービスやツールを検証し、git が計算したチェックサムと比較する。
- ソフトウェアのバージョン更新と署名更新の仕組みも影響を受ける可能性があるため、インベントリに含める。
- 完全性チェックが不適切に失敗しないように、gitプロバイダが圧縮方法を再度変更した場合のチェックサム比較の更新方法について、手順を見直すか、ドラフトを作成する。