OrderHubのビルドと利用者への配布

委託先が開発する受注ポータルOrderHub 2.7.0に、脆弱な文書解析ライブラリが含まれているという通知が届きました。同じ日に、CIで作ったコンテナとCDNから読み込むJavaScriptの改ざんも疑われます。三つは同じ『サプライチェーン』の問題ですが、調べる対象と止める場所は異なります。SBOM、OSS依存関係、CI・CD、成果物署名、SRI、委託先の開発工程を、リリースから利用者まで一つの事例で追います。

読む順序は、用語→依存関係と配布経路→三つの異常を示す証拠→影響範囲→封じ込めと再開です。構成、部品名、アドバイザリ、時刻、ログは全て教材用の架空例です。科目B（午後）では『部品が含まれる』『脆弱な経路が実行される』『改ざんされた成果物が配布される』『利用者が悪性コードを実行する』を別の事実として扱います。

1. 何を管理・検証するのか

用語	OrderHubでの意味と限界
SBOM	Software Bill of Materials。特定の製品・版を構成するソフトウェア部品の一覧と関係。名前、供給元、版、識別子、依存関係、作成主体などを記録する。SBOMに載ることは脆弱性の悪用可能性や成果物の真正性を証明しない。
直接・推移的依存	OrderHubのAPIが直接宣言したreport-kitと、その先でreport-kitが使うdoc-parserを分ける。推移的な部品も実行環境へ含まれ得るため、直接依存だけでは影響調査が終わらない。
ロックファイル	解決された部品版と取得情報を再現する手掛かり。宣言ファイルの範囲指定だけより正確だが、実際の本番イメージや実行プロセスとの一致は別に確認する。
CI / CD	CIはソース取得、テスト、依存取得、ビルドなどを自動化し、CDは成果物を環境へ配布する。ジョブが成功した事実は入力、ビルド環境、署名権限、配布先の安全性を保証しない。
成果物・digest	この例のコンテナイメージとJavaScriptファイルが成果物。digestは内容を識別する値で、可変なタグ2.7.0と区別する。ハッシュ一致だけでは作成者の信頼性を示さない。
成果物署名	成果物digestなどに対して署名し、検証者が許可した鍵・証明書主体で作られたか確認する。署名済みでも、侵害されたCIが悪性物を正規に署名した可能性は残る。
provenance	成果物を、どのソース、ビルド手順、ビルダーで作ったか示す来歴情報。署名と対象digestを検証し、期待するリポジトリ・コミット・ビルダー・入力と照合する。自己申告の文字列だけでは十分でない。
SRI	Subresource Integrity。HTMLのscript等に期待するハッシュを記し、ブラウザが取得した外部リソースのバイト列を比較する。違えばそのリソースを実行しない。期待ハッシュ自体が改ざんされれば防げない。
委託先の開発工程	委託先の開発者、レビュー、リポジトリ、CIランナー、依存取得、署名、引渡しまでの作業。契約上の責任と、発注側が実際に受入れ時に確認する証拠を結び付ける。

2. 一つのリリースを依存と配布の二本の線で追う

OrderHub 2.7.0は社内の受注APIとブラウザ画面から成ります。委託先Vendor-Aはソースcommit c410をレビューし、CIビルドB-410でイメージI-410を作り、社内のレジストリへ渡します。発注側はdigestを固定して本番へ配布します。画面は別にvendor.exampleのCDNからanalytics-v3.jsを読み込みます。以下の略したIDは実際のハッシュ値ではありません。

OrderHubのビルドと利用者への配布

コンテナの配布と、ブラウザが直接取得する外部JavaScriptを分ける。

図ではCDNを省いています。外部JavaScriptはブラウザがCDNから直接取得するため、本番APIイメージの署名だけではその内容を保護できません。逆にSRIが正常でも、APIイメージ内のdoc-parserの脆弱性やCIの改ざんは分かりません。保護対象が異なることを先に固定します。

依存・配布物	この例の関係と確認元
OrderHub 2.7.0	製品。配布記録から本番のimage digest I-410と画面HTML版H-410を確認する。タグ名だけでは実行中の内容を特定しない。
report-kit 3.2.0	OrderHubのAPIが直接使う架空OSS部品。ロックファイルとSBOMの両方へ記録する。
doc-parser 1.4.0	report-kitが使う架空の推移的依存。アドバイザリADV-41の対象とする。依存経路をSBOMとビルド内容で照合する。
ベースイメージとOS部品	npm等のアプリ依存以外の層。アプリのロックファイルだけでは列挙できず、コンテナ全体を走査する必要がある。
analytics-v3.js	CDNからブラウザが取得。ビルド時SBOMに含まれない場合があるので、外部スクリプト台帳、HTML版、SRI値、配信実体を別に管理する。

3. SBOMから脆弱性の影響範囲を絞る

通知ADV-41はdoc-parser 1.4.0の細工された文書を解析した際に問題が生じ、1.5.0で修正されたという架空の内容です。まず『どの製品・版に部品があるか』を検索し、次に『該当機能が本番で実行されるか』を確認します。CVEや名称だけの突合では、同名別製品、版表記の差、OSパッケージへの再梱包を取り違えるため、供給元、識別子、ハッシュ、依存経路を確認します。

text

release=OrderHub-2.7.0 build=B-410 image=I-410
component=report-kit version=3.2.0 relation=direct
component=doc-parser version=1.4.0 relation=via-report-kit
advisory=ADV-41 affected=doc-parser:1.4.0 fixed=1.5.0
prod=cluster-a running_image=I-410
route=/api/import uses=doc-parser exposure=authenticated-users

この架空記録なら、少なくともcluster-aのI-410に対象版が含まれ、認証済み利用者の文書取込経路が存在すると分かります。ただし、ADV-41の悪用条件を満たす文書を処理したか、攻撃に成功したかは未確認です。アクセスログ、取込対象の形式、解析器の呼出し、例外・クラッシュ、送信元をつなげて調べます。

判定段階	必要な証拠と結論の上限
部品の存在	SBOM、ロックファイル、イメージ内部のファイルで、該当版がその成果物に含まれるかを見る。リポジトリ上の宣言だけでは実行中イメージとの一致は不明。
製品・環境への配置	image digest、配布履歴、実際のPod/サーバのdigestを照合。タグ2.7.0は後から付け替え可能なので、タグだけで影響環境を決めない。
機能の到達可能性	取込APIのルーティング、認証条件、doc-parserの呼出し箇所、攻撃に必要な入力形式を調べる。存在だけで悪用可能と即断しない。
悪用の痕跡	要求・エラー・端末/EDR・外向き通信を時間で照合。ログがない場合も、保持期間と監視範囲を確認するまでは『未悪用』と断定しない。
VEX等の影響表明	供給者の『影響なし』には対象製品・版、根拠、作成時点が必要。実環境の到達性やカスタマイズと矛盾しないか発注側が検証する。

SBOMはリリース単位で作り、部品の直接・推移的関係と生成時点を保ちます。開発時にだけ使うテスト用部品と本番へ同梱される部品を区別します。ただしビルド時の部品にも、コード生成やパッケージ取得を通じて成果物改ざんの経路があります。『ランタイムにないから無関係』という結論も早計です。

4. CI・CDで配布物がすり替わる場所

別の異常として、B-410のあとに未承認のビルドB-411が生じたとします。攻撃者が委託先でリポジトリ外の共有CIテンプレートを変え、注文画面へ外部送信コードを混ぜたイメージI-411を作り、同じ2.7.0タグへ再登録しました。これはdoc-parserの脆弱性とは独立した経路です。誰が何を変更できたかをソース、CIテンプレート、ランナー、依存取得先、レジストリ、配布権限に分解します。

CI改ざんが利用者へ届く経路

1. CI設定変更：証跡ジョブ定義の差分／防御・対処レビューと権限分離
2. B-411実行：証跡入力とビルド来歴／防御・対処隔離ランナーと来歴
3. I-411登録：証跡 digestと署名主体／防御・対処署名検証と固定
4. 本番へ配布：証跡配布承認と稼働値／防御・対処 digest固定と受入検証

未承認ジョブから配布までの各段階で証拠と制御点を分ける。

図の三段目で署名が正しくても、悪性I-411を作ったジョブに正規の署名権限が渡っていれば署名は成功します。検証では『署名が有効』に加え、期待したソースcommit c410、許可したCIビルダー、ジョブ定義、成果物digest、発注側の承認したリリースとの一致を確認します。

text

10:20 build=B-410 commit=c410 image=I-410 result=success
10:21 sign image=I-410 signer=ci-release provenance=P-410
11:02 build=B-411 commit=c410 image=I-411 result=success
11:03 sign image=I-411 signer=ci-release provenance=P-411
11:04 registry tag=2.7.0 digest=I-411 actor=ci-release
11:08 deploy env=prod tag=2.7.0 resolved_digest=I-411

ログではB-411も同じcommit c410を名乗り、署名者もci-releaseです。しかし出力digestが異なり、タグがI-411へ動いています。これは改ざんの調査対象を示しますが、悪意の有無はジョブ定義、依存取得結果、ビルド環境、承認された変更と比較して判断します。同じソースから異なるdigestが出ること自体は、非再現ビルドでも起こり得ます。

検証する境界	必要な制御と反証
ソースとレビュー	保護ブランチ、複数人レビュー、CI定義変更の承認、強い認証。commit c410が正規でも、ジョブ定義が別権限で変われば出力は変わる。
依存取得	ロックファイル、検証済みレジストリ、ハッシュ固定、取得ログ。版を固定しても取得先の改ざんや任意スクリプトの実行を調べる。
CIランナー	一時的で隔離した実行環境、最小権限、秘密情報の短期発行。共有ランナーの汚染や無制限の署名権限を避ける。
成果物署名	信頼する署名主体と対象digestを検証。署名鍵・OIDC主体を誰が使えたか、侵害時刻以後の署名を区別する。
provenance	期待したリポジトリ、ソースrev、ビルダーID、入力、出力digestを検証。ジョブ自身が自由に書ける未保護メタデータを独立証拠として扱わない。
CDと本番	タグでなくdigestを固定し、署名・来歴・承認結果を配布ゲートで確認。実行中digestと承認済みdigestが一致するまで完了としない。

5. 外部JavaScriptとSRIで防げる範囲

OrderHubの画面HTML H-410には、CDNのanalytics-v3.jsを読み込むscriptがあるとします。CDNのファイルが同じURLのまま差し替えられると、利用者のブラウザは新しいバイト列を取り込み、画面の権限で実行し得ます。HTTPSは通信路と接続先を保護しますが、CDN運営側や配信内容の変更が承認済みかまでは判断しません。

html

<script src="https://cdn.vendor.example/analytics-v3.js"
        integrity="sha384-<承認済みバイト列のBase64ダイジェスト>"
        crossorigin="anonymous"></script>

12:10 browser=WS-41 resource=analytics-v3.js
      expected=H-410/SRI actual=changed result=blocked
12:11 api=OrderHub order_create result=success

上のintegrity値は説明用のプレースホルダであり、そのまま動く値ではありません。実際には承認したファイルからSHA-384等のハッシュを計算し、HTMLへ固定します。ブラウザは取得したリソースを検証し、不一致ならスクリプトを実行しません。異なるオリジンからのSRI対象ではCORSが必要で、この例の`crossorigin="anonymous"`とCDN側のCORS応答を合わせます。

状況	SRIの判断と残る課題
CDNが同じURLの中身だけ変更	期待ハッシュと異なれば読み込みを拒否。障害としても見えるため、利用者影響を監視し、承認なしにintegrity値を更新しない。
承認して新版へ切替	新ファイルをレビュー・固定し、HTMLのハッシュを合わせて更新。旧HTMLと新CDNファイルが混在する移行期間は版付きURL等で整合させる。
HTMLごと改ざん	攻撃者がHTMLとintegrity値を一緒に変更できればSRI単独では止められない。HTMLの配布経路・署名・レビュー・CSP等を別に守る。
動的追加・別の外部コード	該当script以外にSRIが付いていなければ保護されない。外部スクリプト台帳とCSPで読み込み元と適用範囲を管理する。
外部サービスのデータ送信	正規スクリプト自体が個人情報を外部へ送る設計なら、ハッシュ一致でも止めない。権限・データ利用目的・契約を確認する。

`result=blocked`はそのWS-41で当該リソースの実行を拒否した証拠で、全利用者が保護された証拠ではありません。SRIなしの古いHTML、ブラウザ拡張、別のURL、キャッシュ、サーバ側のAPI侵害は別に調べます。CSPは許可する読込元の制限に役立ちますが、許可済みCDN上でファイルが差し替わった場合、オリジン許可だけでは内容の同一性を保証しません。

6. 委託先と発注側の工程・責任を結ぶ

工程	委託先の実施と発注側の受入れ証拠
設計・調達	対象製品、外部サービス、OSS利用、脆弱性通知窓口を定義。発注側は資産台帳と依存部品を受け取り、利用目的とデータ流出経路を把握する。
ソース変更	委託先はレビュー、権限、CI定義の保護を実施。発注側はレビュー記録と緊急修正時の例外承認を受け取る。
ビルド	委託先はSBOMとprovenanceをリリースごとに生成し、署名対象digestへ結び付ける。発注側は受入れ時に署名と期待する主体・入力を検証する。
脆弱性対応	通知から影響調査、暫定対策、修正版提供までの連絡期限と窓口を決める。発注側は自社本番のdigest、到達可能性、業務影響で優先度を決める。
配布・運用	委託先のレジストリへの登録権限と、発注側の本番配布承認を分ける。外部JavaScript更新の承認者、SRI更新、旧版停止、ロールバックを明記する。
事故・監査	双方で保全するGit、CI、レジストリ、配布、CDN、ブラウザのログと保持期間を決め、再委託先にも必要な報告・是正条件を及ぼす。

契約に『安全な開発を行う』とだけ書いても、事故時に必要な証拠が残るとは限りません。成果物の受入れ条件を、SBOMの対象範囲、署名・来歴の検証結果、脆弱性の対応期限、改ざん発見時の通知、ログ提供、再委託先の管理として具体化します。発注側は本番への配布権限と事業停止の判断を自ら持ちます。

7. 三つの異常を同じ画面で見つけたときの切り分け

異常	最初に照合する識別子と次の証拠
ADV-41の通知	SBOMのdoc-parser版→該当image digest→稼働環境→取込APIの到達性→悪用痕跡。部品の存在と侵害成功を分ける。
I-411へのタグ変更	レジストリ監査→B-411のジョブ・provenance→署名主体→CDのresolved digest→稼働値。署名有効と承認済みを分ける。
SRI不一致	HTML版H-410のintegrity値→CDN応答のバイト列→CORS結果→ブラウザのblock→他の画面版・利用者。単一端末のblockと全体保護を分ける。
利用者からの不審報告	発生時刻、画面HTML版、読み込んだJS、API・端末ログ、ネットワーク送信先を結ぶ。三経路のどれかと決め付けない。

因果関係の証拠は強さが異なります。SBOMの一致は含有の証拠、配布ログはどのdigestが稼働したかの証拠、ブラウザのSRIエラーはその資源を拒否した証拠です。いずれも単独で情報漏えいの有無を証明しません。注文データの外向き送信や変更は、APIログ、端末/ネットワーク記録、監査ログで別途確認します。

8. 封じ込め・修正・再開の順序

最初にB-410/B-411のジョブ定義・入力、ソースcommit、SBOM、provenance、署名、レジストリ変更、CD配布、HTML・CDNの応答を時刻付きで保全する。ログの保全先は侵害されたCIと分離する。
I-411が未承認なら配布を止め、可変タグの利用を停止する。署名権限やCI資格情報の悪用が疑われる場合は失効・更新し、影響期間中に署名された成果物を再検証する。
ADV-41についてはI-410/I-411の含有と/api/importの到達性を確認し、必要なら取込機能の一時停止、入力制限、監視を行う。委託先に修正版の依存更新と再ビルドを要求する。
CDNの変更を凍結し、承認済みの版付きURL・SRI値へ戻す。HTMLとJSの組合せを試験し、CORS・CSP・ブラウザエラー・注文APIの正常動作を確認する。
新しいソース・CI環境からイメージを作り直し、SBOM、署名、provenance、期待した入力とdigestを検証して配布する。実稼働digestと承認値が一致するまで旧タグを使わない。
影響範囲の取込要求、異常な外向き通信、注文データの変更を調べ、委託先・発注側の責任者が報告と再開を承認する。復旧後も旧版・旧HTML・旧CDNキャッシュを監視する。

旧イメージへのロールバックは、I-411の改ざんを避ける助けになりますが、I-410にdoc-parser 1.4.0が残っているなら脆弱性は解消しません。逆に依存を1.5.0へ上げた新イメージも、侵害されたCIで作れば改ざんを持ち込み得ます。再開判定は『脆弱な部品がない』『来歴と署名が検証できる』『外部スクリプトが承認版である』を個別に確認します。

9. 科目B（午後）での解答手順

まず対象の製品版、成果物digest、HTML版、外部JSのURLとハッシュを表にし、異なる識別子を混ぜない。
脆弱性では部品の存在→実配置→到達可能性→悪用痕跡の順に強い結論へ進む。
改ざんでは誰がソース・CI・署名・配布を変更できたかを調べ、署名有効だけで安全とは書かない。
SRIではブラウザが取得した外部資源とHTML内の期待ハッシュを比較し、HTMLの信頼性とCORS条件も示す。
対策は発生位置に置き、検証可能な再開条件と委託先・発注側の責任者を示す。

10. 短答演習

演習1：推移的依存

条件：OrderHubの宣言ファイルにdoc-parserはないが、SBOMにはreport-kit経由で載る。質問：ADV-41の調査対象から外せるか。解答：外せない。I-410に該当版が含まれ、取込機能で使うか確認する。誤答の理由：直接依存だけを対象とみなしている。

演習2：SBOMの一致

条件：SBOMにdoc-parser 1.4.0がある。質問：侵害成功を確定できるか。解答：できない。取込APIの到達性、入力、実行、異常・通信ログが必要。誤答の理由：含有と悪用成功を同一視している。

演習3：署名済みI-411

条件：I-411の署名はci-releaseで有効だが、B-411は未承認。質問：配布してよいか。解答：止める。期待するビルダー、ジョブ、入力、承認、digestを照合する。誤答の理由：署名者が正しければ内容も承認済みと決め付けている。

演習4：可変タグ

条件：本番に2.7.0タグがある。質問：I-410が稼働しているか。解答：タグだけでは不明。実行中のresolved digestを確認する。誤答の理由：タグを不変の識別子と扱っている。

演習5：SRIエラー

条件：WS-41でanalytics-v3.jsのSRI不一致が発生。質問：全利用者の漏えいが防がれたと言えるか。解答：言えない。WS-41の当該資源は拒否されたが、他のHTML版・ブラウザ・経路を調べる。誤答の理由：一点の観測を全利用者へ広げている。

演習6：ロールバック

条件：I-411からI-410へ戻すとdoc-parser 1.4.0が残る。質問：事故は完了か。解答：未完了。改ざん経路と脆弱性経路を別々に解消し、双方を検証する。誤答の理由：一つの対策で別の原因まで消えたと考えている。

11. 一次資料

W3C：Subresource Integrity

NIST SP 800-218：セキュア開発と供給者との連携

SBOM・OSS依存関係・CI/CD・成果物署名・SRIと供給網リスク