GitLabの重大修正：配布済みソフトウェアを誰が証明するのか

修正の知らせを、ソフトウェアを買う側から読む

10月12日、GitLabはCommunity Edition／Enterprise Edition（CE/EE）のCI/CD正規表現の問題を修正した。条件によって認証なしでサーバー上のコードを実行できる問題である。GitLab.comは対応済み、Dedicatedは対応不要、自社運用には更新を求めた。19.3.4のOna連携の不具合も19.3.5で修正している。^[1]

ソフトウェアの購入者にとって、開発元の設備が現在どの状態にあるかは大切である。しかし、すでに届いた製品を評価するには、それとは別の情報が必要になる。自分が受け取ったファイルはどれか。開発元が説明している版と同じものか。作った際の記録は残っているか。問題のある設備で実際に何が起きたか分からない段階では、これらの問いをまとめて「安全か危険か」の二択にしても答えは出ない。

ここでいうCI/CD（継続的インテグレーション／継続的デリバリー）は、コードの変更を試験し、配布するソフトウェアを作る工程を継続的に実行する仕組みである。この工程から出たファイルが他社へ渡ると、送り手の現在の設備だけでなく、受け渡した時点の品物が取引の対象になる。買い手が保管したコピー、送り手が管理する配布場所、製品名や版番号が示すものが食い違えば、両社が同じ製品について話しているつもりでも、実際には違うファイルを見ている可能性がある。

今回の資料から、実際の侵入、配布物の改ざん、企業の損失が起きたとは確認できない。本稿は、その発生を前提にした被害推計ではない。SG Groupが注目するのは、重大な修正が出た際、企業間で過去に渡したソフトウェアについて何を説明できるかである。技術資料を使って確かめ方の限界を整理し、受領者の判断、製品の引き渡し、売上の回収へどうつながり得るかを考える。

現在の設備と、過去の納品物を分ける

たとえば、ある会社が業務システムの更新用ファイルを外部の開発会社から受け取ったとする。開発会社はその後、制作設備を更新したと知らせてきた。設備の更新を確認することは、今後の制作環境を考える材料になる。一方、先週受け取ったファイルについての質問には、それだけでは答えていない。買い手の手元にあるものが、更新前のどの作業から生まれ、どの承認を経て渡されたかという履歴が残る。

設備、操作に使う資格情報、配布物は、それぞれ調べる対象が違う。設備については、どの構成をいつ確認したかが問題になる。資格情報とは、利用者やプログラムが操作するためのトークンや鍵などであり、使える範囲と実際に使われた履歴を分けて考える。配布物については、受領した品物を指定できることが出発点になる。この三つを一枚の一覧に記すことはできても、一つの確認結果で残りを埋めることはできない。

同じ版番号が付いているから同じ品物とは限らない、という問いもここから生まれる。開発元が説明のために新しく作ったコピーと、顧客が当時保存したコピーでは、作成の時点が違う。後者を捨てて前者だけを調べると、過去の納品について答えるための材料を失うかもしれない。逆に、二つの違いが正規の修正によるものと分かれば、それを不審な変更と扱う必要はない。違いの存在と、その理由の評価は別の作業になる。

この区別は、全製品の受領を止める判断を自動的に導くものではない。ある納品物と今回の対象設備との関係が確認できない場合と、関係がないと説明できる場合では、追加で必要な情報が変わる。判断を絞るには、会社全体の安心宣言より、その品物を特定した説明が役立つ。製品名、顧客が受け取ったコピー、当時の配布記録を結び付ければ、何について一致し、何についてまだ分からないかが明確になる。

AIのサイバー能力と防御を終える工程 — 新たなサイバー能力から、企業が防御作業を完了する条件を読む。

資格情報を止めても、過去の操作は消えない

GitLabの個人アクセストークン（PAT）をローテーションすると、旧トークンは直ちに無効になる。新しいものには同じ権限と範囲が引き継がれる。^[2] これは将来の利用を変える措置であり、それ以前に行われた書き込みや、外部へ渡ったコピーを取り消す機能ではない。無効化の確認と、過去に何が行われたかの確認には、異なる材料が必要になる。

この点は、調査の担当者と取引先が違う時間を見ているときに重要になる。担当者は「もう使えない」と説明し、顧客は「使えていた間に製品が変わったのか」と聞いているかもしれない。前者が正しくても、後者への回答が残る。失効の事実を報告する際には、それが説明する時点と対象を示すと、顧客が未確認事項を見分けやすい。反対に、過去の不明点があるだけで、失効後も同じ経路が開いていると決めつけるのも誤りである。

資格情報の名称をまとめて扱うと、何ができたかの評価も広がりすぎる。GitLabは、ジョブを受け取るRunnerの認証と、実行中のジョブが使うトークンを区別している。デプロイキーはリポジトリへのSSH（Secure Shell、暗号化通信方式）権限であり、GitLab API（ソフトウェア間の操作窓口）やレジストリの認証には使えない。^[3] 調べる際は、具体的な種類と対象を明らかにする必要がある。サーバーの問題が公表されたことから、すべての鍵が使われた、すべての外部保管場所へ到達したと飛躍してはいけない。

受領者へ渡す説明にも、秘密そのものは要らない。どの種類の資格で、どの配布先を操作できたか、その条件をいつ変えたかという記録が判断材料になる。実物の秘密を顧客に送り直せば、説明のために新たな管理対象を増やしてしまう。資格の能力と、その秘密の値は分けて扱える。製品の調査に必要な範囲を定めることは、関係のないアカウントや顧客情報を説明資料へ集めないことにもつながる。

IonQ・Elisity：通信権限と暗号の統合 — 通信権限と暗号技術を組み合わせる企業の計画を読む。

ログの空白をどう読むか

個人アクセストークンの利用時刻は10分ごと、IP情報は1分ごとに更新され、表示される異なるIPは直近五つである。^[2] 一方、ジョブトークンの認証ログは他プロジェクトによる認証を記録し、画面は最大100件、全ログはCSVで取得できる。新しい記録の表示には最大5分かかり得る。^[4] 更新間隔と表示遅延は異なる指標であり、この数字から検知速度を順位付けできない。

ログを読む際に必要なのは、調べたい操作がその記録の対象かを先に確かめることである。納品物が変わったかを知りたいのに、別の種類の認証だけを記録する画面を見て「載っていない」としても、その変更についての証拠にはならない。また、画面に出る件数と、保存されている全履歴の量を取り違えると、調査対象が見えている部分だけに縮んでしまう。資料にある上限が表示の上限なのか、保存の上限なのかは区別すべきである。

時刻の比較にも注意が要る。顧客がファイルを受け取った時刻、送り手が作成した時刻、システムが記録を更新した時刻は、同じ出来事を示していない。時刻が近いという理由だけで、一つの操作から一つの配布物が生まれたと断定することはできない。品物や作業を結ぶ識別情報も必要になる。時間帯を揃えた上で、それぞれの時刻が何を意味するかを添えると、離れた地域の担当者が記録を読み違える余地を減らせる。

空白が残ったときには、どの問いに答えられないかを示すのがよい。「全履歴なし」とひとくくりにすると、顧客が保持している納品物や、独立した受領記録まで無価値に見えてしまう。逆に、一つの利用時刻が残るから配布物の経緯もすべて分かる、と拡大することはできない。足りない記録を、残っている別の証拠がどこまで補うかを考える。これが、調査を無制限に広げずに不確実性を扱う方法になる。

「最新版」を取り直しても、昔の品物とは限らない

GitLabのブランチ用latest成果物URLは、新しいパイプラインの後に別のファイルを指し得る。ジョブIDで指定する方法もあり、資料はジョブの成果物と、リリース用の版付きパッケージを区別する。^[5]

仮に顧客が古いコピーを残していなければ、現在の配布場所だけを見て過去の品物を再現するのは難しくなる。開発元が当時の成果物を別に保存していれば、そこから照合を進められるかもしれない。しかし、その保管物が当時顧客へ渡したものに対応するという説明が要る。作ったもの、公開したもの、実際に受け取ったものの関係を示さなければ、同じ製品の候補を集めただけで止まる。

同じ名前のファイルが複数ある場面では、名前を変えるだけでは問題を解けない。顧客A向けと顧客B向けに異なる設定を入れた配布物が、同じ製品名で管理されていたとする。Aが保存したコピーをBの照合に使えば、正規の差まで異常と見なすおそれがある。これは本稿の仮定例であり、実際のGitLab利用者の事故を述べているわけではない。買い手ごとの納品条件を含めて、比較する二つの品物を選ぶという意味である。

一致するファイルと、信頼できる基準

ハッシュ値はファイルを要約した識別値であり、照合に使える。ただし、比較の基準がどこから来たかも確認する必要がある。米国立標準技術研究所（NIST）のセキュアソフトウェア開発フレームワーク（SSDF）は、改変を確かめる情報と、保存するリリース・来歴の保護を扱っている。^[6] ハッシュという形式が付いていることより、比較する相手を信頼できる理由が大切になる。来歴とは、どの入力や制作環境から品物が生まれたかを説明する情報である。

送り手と顧客が同じ値を示すなら、同じ品物を議論しているという方向へ進める。一方、現在の配布場所にあるファイルと、同じ場所で今公開されている識別値だけを比べる場面では、二つが一緒に変わる可能性を評価しなければならない。同じ管理元にある二つの情報の一致と、別の時点に別の当事者が保持した記録との一致では、説明できることが違う。基準の作成時点と保管経緯が、比較結果の意味を変える。

別の当事者が保持したから無条件に正しいということでもない。顧客が受領後にファイルを変換した、記録した値が別のコピーに対応していた、といった可能性もある。どの状態の品物を保存したかが分からなければ、送り手との違いを改ざんと呼ぶのは早い。問い合わせでは、納品時の保存物か、展開後のものか、別の処理を経たものかを明らかにする。双方が比較対象を指定してから、その差の説明へ進むべきである。

この考え方は、過去の受領物を残した会社だけが責任を免れる、といった法的判断を示すものではない。取引で何を引き渡す約束だったか、受領確認をどう行うかは個別の条件による。ここで評価しているのは証拠が答えられる問いである。保存したコピーは技術的な比較を助けるが、契約のすべてを証明する書類に変わるわけではない。技術上の一致と、取引上の履行を分けると議論が進めやすい。

署名と来歴で、何を確かめるのか

ソフトウェア供給の来歴を扱うSLSA（Supply-chain Levels for Software Artifacts）の検証資料は、品物のハッシュ値、署名された来歴、信頼する制作基盤の識別、期待したソースや設定を照合する方法を説明している。制作基盤への信頼は前提として残る。^[7] 確認項目が増えるのは、同じ安心宣言を重ねるためではない。

顧客が期待する製品と、署名が対象とする品物の関係も明らかにする必要がある。別の顧客向けに正規に作ったソフトウェアが、誤って渡されるという仮定を考えてみる。その品物の署名に問題がなくても、受領者の必要に合うとは限らない。逆に、期待した機能が動くからといって、作成元に関する疑問がすべて解けるわけでもない。製品を使えることと、その作成経緯を説明できることは、別の価値を持つ。

判断の基準を通知後に変えた場合も、時点を明らかにすることが重要になる。新しく承認した作成元を使って過去の納品を説明するなら、当時の条件との違いを示す必要がある。当初の約束が分からないまま、現在の基準に合うから当時も適切だった、と結論づけることはできない。この問いは、資料の書式が整っているかより、その資料がどの版の受け渡しを説明しているかに向かう。

また、すべての顧客が同じ詳細な制作記録を持つとは限らない。必要な粒度は、品物の役割や、買い手が自分で確認できる範囲によって変わる。説明が足りない場合には、何を追加で示せば判断が進むかを絞れる。資料の種類を増やすこと自体を目的にすると、受領物とのつながりがない記録が積み上がる。ある一つの品物について、記録と期待する条件を結ぶことが先である。

過去の事例を、今回の被害に置き換えない

2020年12月17日の米サイバーセキュリティ・インフラストラクチャー庁（CISA）資料は、SolarWindsの改変されたバイナリに正規の証明書による署名があったと記している。^[8] 過去の例が示すのは、正規の署名と、無害な品物という判断が同じではないことである。これを今回のGitLab利用者で同様の改ざんが起きた証拠にすることはできない。別の事件の被害規模を使って、今回の損失を埋めることもできない。

仮定例：旧版の説明と、新版の受領が食い違う

ここからは説明のための仮定例である。開発会社が取引先へ業務用ソフトウェアを納品し、取引先は受領したコピーを保存していた。後日、制作設備の問題が公表され、開発会社は作り直した品物を提示したとする。取引先が旧版の説明を求めているのに、開発会社が新版の試験結果だけを答えれば、質問と回答がすれ違う。新版を選ぶかどうかの判断に、その資料は使えても、旧版の経緯は残る。

まず比較する二つの品物を定めると、すれ違いの場所が分かる。取引先が保存したコピーと、開発会社が当時渡したと説明するコピーが同じなら、旧版を同じ対象として調べられる。異なるなら、別の納品先向けだったのか、正規の更新だったのか、保管後に変わったのかを確認する必要がある。いきなり責任のある会社を決めるのではなく、差が生まれた段階を絞るという順番になる。

次に、新版を受け取る条件を旧版の評価から切り分ける。取引先が互換性の試験を必要としているなら、制作元が変わったことの説明だけでは受領の判断は終わらない。逆に、機能が同じであっても、旧版の経緯についての追加説明を求めることは矛盾しない。この二つを一つの会議で扱っても、決めた内容は別々に残せる。旧版について分かったことと、新版へ移る際に残る確認を混ぜないことが大切である。

実際の契約に、交換、再試験、支払い保留の条件があるかは別途確認が必要になる。この例から、顧客に必ず支払いを止める権利がある、開発会社に必ず全品交換の義務があるとは言えない。技術上の問いを明確にすれば、契約担当者も何の説明が不足しているかを検討しやすくなる。証拠の不足を法的な結論へ直結させず、当事者が決める必要のある事項を分けて示すのである。

国境を越える取引で、説明はどこまで届くか

ソフトウェアの送り手と受領者の間に、販売会社、組込み製品のメーカー、保守会社が入る場合を考える。開発元が一つの配布物を説明しても、その先で別の製品へ組み込まれていれば、最終の購入者が受け取ったものとの関係が必要になる。途中の会社が何も変えていない場合と、設定や部品を加えた場合では、開発元の説明だけで答えられる範囲が違う。流通の段階を省くと、証拠が対象とする品物が変わってしまう。

国際取引では、この関係を複数の当事者が同じ意味で読めることに価値がある。通知の日付だけを訳しても、どの納品物について話しているかが一致しなければ、説明は届かない。送り手が使う版の名称と、買い手が保存したファイルの名称が異なる場合には、両者を対応させる情報が必要になる。翻訳が正確でも、品物の対応が曖昧なら、調査や受領確認を長引かせる原因になり得る。

取引先を広げるほど、同じ説明を転送するだけでは足りない場面が増える。一社目への説明が、その会社に渡した品物に限定されていれば、二社目の別の品物にも当てはまるとは限らない。共通する部分と、納品先ごとに異なる部分を分ければ、無関係な情報を毎回作り直さずに済む。これは本稿の条件付きの取引分析であり、今回、特定の販売網が影響を受けたという報告ではない。

その反対に、途中の会社が受領と再配布の対応を保っていれば、最終の購入者の問いを開発元へ戻しやすくなる。重要なのは、組織が何社あるかという数だけではない。どの会社の説明が、どの品物まで届くかである。流通が長くても対応が明確なら調査を絞れる可能性があり、直接の取引でもコピーの特定ができなければ不明点は残る。距離や国の数を、そのまま危険度に置き換えてはいけない。

供給網の遅延と在庫・現金 — 物の物流を扱う基礎解説。ソフトウェア配布とは条件が異なる。

受領の判断が、売上と現金の時期を変える条件

経済への伝わり方は、調査そのものの費用だけではない。顧客が新しいソフトウェアの受領確認を終えることが、次の納品や代金回収の条件になっている取引なら、説明が整う時期は商取引の時期に関係する。製品が完成していても、買い手が比較する品物を特定できなければ、確認の作業が進まない場合がある。ただし、今回そうした遅延が起きたとの確認はなく、すべての取引が同じ条件を持つわけでもない。

仮に顧客が一つの版だけを確認しているなら、必要な説明を絞ることができる。複数の版を同時に扱い、各社で異なるものを組み込んでいる場合は、対応を整理する負担が増え得る。ここで費用を決めるのは、単純な売上の大きさではない。どれだけの品物を再び対応付ける必要があるか、過去の受領物が残っているか、当事者が同じ資料を読めるかといった条件である。

販売の継続と代金の回収も分けて考えたい。新規の注文を受けられる状態でも、過去の納品に関する質問が回収の段階で残る場合がある。反対に、受領確認が不要な定額の契約なら、個別の照合がそのまま入金の延期につながるとは限らない。取引条件を見ずに、制作設備の問題を企業の売上減や資金不足へ直接結び付けることはできない。市場で数字を評価する際も、この途中の条件が必要になる。

世界経済への影響を大きく見積もるには、影響を受けた供給者、製品、取引の規模を示す別の証拠が要る。深刻な技術問題であることと、金融市場全体の損失を算出できることは違う。本稿で示せるのは、配布物の説明が受領判断へ、その判断が条件によって取引の時期へ伝わる経路である。金額がない部分を大きな市場予測で補うより、どの追加情報があれば評価を変えられるかを示すほうが有用である。

サイバー防御需要から株主の現金へ — 需要や株価と企業の現金を結ぶ条件を読む。

調査を狭められる場合もある

対象設備が製品の作成や配布に使われていなかったと確認できれば、その製品についての調査は絞れる。ここで必要なのは、会社が同じソフトウェアを使っているかという一般論より、納品物との具体的な関係である。会社全体の利用が分かるだけでは、すべての製品との関係は決まらない。逆に、納品物を作った設備が特定できるなら、無関係な製品や取引先へ同じ質問を広げる必要がない場合もある。

制作工程が扱う情報にも差がある。GitLabの変数のマスキングは、悪意あるスクリプトが秘密へアクセスすることを防ぐ保証ではない。^[9] それをもって今回すべての秘密が漏れたとは言えない。ある作業にどの情報が渡されたかを確認できれば、外部への到達可能性を考える範囲が狭まることもある。使えるはずだった能力と、実際の操作の証拠を区別することが、過小評価も過大評価も避けるために必要になる。

独立して保存された受領物や、当時の説明との対応が残る場合も、調査の進め方は変わる。現在の配布場所を何度も確認するしかない場面と違い、過去の品物を固定して比較できるからである。ただし、一致が確認できたことから、機能上の欠陥もない、すべての契約条件も満たすと広げてはいけない。答えが得られた問いを限定して示すことが、次の問いを絞る助けになる。

したがって、今回の発表だけを根拠に、すべての製品を止めることや、すべての資格情報を同じ方法で入れ替えることを一律に勧めることはできない。判断には、利用形態、品物との関係、残る証拠が必要になる。必要な追加確認を具体化できる場合は進め、不明点が大きい場合はその範囲を示す。何もしないという結論と、全体停止という結論の間にも、品物ごとに検討できる選択肢がある。

SG Groupの見方：受領者が検討できる説明にする

SG Groupは、送り手が配布済みの品物について説明する際、顧客が自分の受領物に対応させられるかを重視する。企業名を主語にした安心宣言だけでは、顧客は手元のコピーへ話を結び付けにくい。どの品物を対象とし、何を比べ、どの点がまだ分からないかを示せば、顧客は自分で持つ材料と照らし合わせられる。説明の量より、相手の問いに答えられることが大切である。

判断は少なくとも三つの状況で変わる。対象設備と納品物の関係が切り分けられ、独立した記録も一致する場合は、追加確認を絞る方向へ進める。関係はあるが過去の記録が不足している場合は、問題がないとの断定を保留しつつ、比較できる品物を確保する意味が大きくなる。具体的な不正変更が見つかった場合には、その品物の受領者と経路に沿って対応を考える。これは確率付きの予測ではなく、証拠による条件分岐である。

この見方に対する反論は、詳細な照合の負担が取引を遅らせるというものだろう。無関係な品物や、すでに説明できる内容に同じ調査を繰り返せば、その懸念はもっともである。本稿の提案は、確認項目を際限なく増やすことではない。顧客の品物に届く問いへ絞ることで、どこまでの説明が必要かを定めるという考え方である。品物を特定せず資料だけ増やす方法は、この目的に合わない。

次の情報を、同じ品物に結び付けて読む

今後の続報では、公式の修正案内の変更と、特定の利用環境についての確認を区別したい。修正案内が変われば、現在の設備をどう評価するかに関係する。特定の品物について新しい記録が出れば、過去の納品をどう評価するかが変わる。どちらも重要になり得るが、同じ種類の更新ではない。報道日が新しくなっただけで、品物についての新しい事実が増えたとは限らない。

取引に近い続報としては、どの品物を対象とする説明なのか、その品物が誰の保管物と比較されたのか、判断に使う記録がどの時点のものかが役立つ。企業が調査の終了を知らせた場合も、対象とした製品や期間が分かれば、受領者は自分のケースに当てはめられる。対象が違う調査結果を自分の品物への回答と取り違えないためにも、説明の範囲を読み取ることが必要になる。

市場への影響を検討する際には、具体的な納品、受領確認、支払い条件に関する情報が出たかを追う。価格が動いたという情報だけでは、その変化を今回の事象へ帰属できない。他の企業発表や需給の変化もあり得るからである。技術上の重要性を認めつつ、経済上の大きさを判断するための材料は別に求める。この姿勢は、重大な問題を軽く扱うことでも、最悪の規模を先に決めることでもない。

開発元の現在の状態を知り、受領した品物を特定し、その作成と受け渡しの説明を読む。これらがそろうと、購入者は追加確認を続けるか、新しい品物を選ぶか、説明で足りるかを検討しやすくなる。国境を越えて売られたソフトウェアでは、同じ品物を示す情報が当事者をつなぐ。今回の知らせから経済を考える際も、まずこの受け渡しを具体的に読むことが、根拠のある評価への入口になる。