ゆめさくセキュリティ

レッスン 5-2

供給網のリスク

自分が安全でも、頼っている先が破られれば同じことです。

目安 60 分 トラック 5 設計と制度の 2 本目

読み終えたら依存の 1 つについて部品の一覧を作り、既知の穴と照らせる

この頁の流れ

  1. 1なぜ通るのか
  2. 2脆いコードと直したコード
  3. 3ログでの見え方と検知
  4. 4直し方と確かめ方
  5. 5関わる事例
  6. 6確認クイズ
  7. 7説明課題
  8. 8一次資料
  9. 9次へ

自分で書いていない部品、ビルド、署名、部品の一覧 (SBOM)、委託先を扱います。版を固定しない依存の書き方と、版とハッシュを固定した書き方を手元で比べ、部品の一覧を作って既知の穴と照らす手順までを扱います。

出典を確かめた日 2026年10月24日

なぜ通るのか

自分のアプリのコードを 1 行ずつ見直したとします。けれども、動いているコードの多くは自分で書いた物ではありません。ライブラリ、ライブラリが頼るライブラリ、それを組み立てるビルドの仕組み、更新を配る経路、保守を任せた委託先。どれも、自分の手の外で書き換わり得ます。

供給網の攻撃は、守りの固い本丸ではなく、本丸が信じて取り込む物を狙います。取り込む側は、相手を信じて受け取るので、中身を確かめないまま自分の権限で動かしてしまいます。

信じて取り込む境目

境目は、外から来た物を「自分の物」として扱い始める所にあります。依存を入れる時、更新を当てる時、委託先に接続を許す時です。

  • 依存を入れる時。名前だけを書いて版を決めないと、入れるたびに中身が変わり得る
  • ビルドの時。ビルドの仕組みが破られると、正しい手順で作った物に別のコードが混ざる
  • 署名の時。署名は「この鍵の持ち主が出した」ことを示すだけで、中身が安全だとは示さない
  • 委託先の接続。保守のための入口は、委託先が破られれば、そのまま入口になる

何が入っているかを知らない

もう 1 つの穴は、自分のアプリに何が入っているかを知らないことです。広く使われる部品に重大な穴が見つかった時、どの製品のどこにその部品が入っているかをすぐに答えられなければ、直す前の調べで時間を失います。

CISA は、部品の一覧 (SBOM) を、ソフトウェアを作っている部品の入れ子の一覧、つまり材料の表だと説明しています。一覧があれば、穴が公表された日に「うちにはあるか」を照らせます。

脆いコードと直したコード

ラボの中で、手作りの小さな部品 labpkg を 1 つ用意し、手元のフォルダからだけ入れます。外の配布元には接続しません。

版を固定しないか、版とハッシュを固定するか

脆いコード名前だけを書く requirements
labpkg
直したコード版とハッシュを固定する requirements
labpkg==1.0 \--hash=sha256:...

直した方の ... の所には、その版の配布ファイルの SHA-256 (64 けたの 16 進数) を書きます。Python の pip は、この形で書くと、落としたファイルのハッシュを書いた値と照らし、違えば入れるのを止めます。

脆い方は、手元にある labpkg を何でも入れます。同じ名前で中身の違う物に置き換わっても気づきません。新しい版が出れば、黙ってそちらが入ります。

入っている部品を一覧にして照らす

Python部品の一覧を作り、既知の穴と照らす
from importlib import metadata def parts(path):ds = metadata.distributions(path=[path])return {d.metadata["Name"].lower():d.version for d in ds} KNOWN = {("labpkg", "1.0"): "LAB-0001"} def check(sbom):return [KNOWN[(n, v)]for n, v in sbom.items()if (n, v) in KNOWN]

parts は、入れたフォルダの中の部品の名前と版を集めます。KNOWN はラボのための既知の穴の表で、ふだんは公開の脆弱性の情報がここに当たります。名前と版が分かっていれば、照らすのは表を引くだけです。逆に版を固定していないと、一覧の版は入れるたびに変わり、照らした結果も当てになりません。

ログでの見え方と検知

直した書き方で入れたあと、手元のフォルダの labpkg を、同じ名前と同じ版のまま中身だけ違う物に置き換えて、もう一度入れます。pip は止まり、記録に次の行が残ります。

記録直した書き方で中身が替わったときの記録
ERROR: THESE PACKAGES DO NOT MATCHTHE HASHES FROM THE REQUIREMENTS FILE.labpkg==1.0 from file:///lab/wheels/Expected sha256 beb50c96Got        82d0e736

実際の行ではハッシュは 64 けたで出ます。ここでは先頭の 8 けただけを載せ、ファイルの住所も短くしています。脆い書き方では、同じ置き換えをしても何も出ずに入ります。守る側は、次の物を見張ります。

見る物なぜ効くか
ハッシュの食い違いで止まったビルド中身の差し替えか、固定の更新漏れかを必ず調べる
依存を固定した表の変更新しい部品や版の変化は、レビューで目に入るようにする
更新のあとの見慣れない外への通信ビルドに混ざった物は、正しい署名付きで届くことがある

最後の行は、署名を確かめていても混入は届き得る、という事例から来ています。署名と固定は「誰が出したか」と「前と同じか」を確かめますが、出した側のビルドが破られていれば、それ自体が正しく署名されて届きます。

直し方と、直ったことの確かめ方

自分の PC の中だけで行います。外の配布元にも、他人の機械にも接続しません。

  1. 作業用のフォルダに wheels を作り、手作りの labpkg 1.0 を 1 つ置く
  2. 名前だけの requirements で、手元の wheels からだけ入れる設定で入れ、入ることを確かめる
  3. labpkg の配布ファイルのハッシュを取り、版とハッシュを固定した requirements に書き換える
  4. 同じ名前と版のまま中身の違う labpkg に置き換え、名前だけの方は黙って入り、固定した方はハッシュの食い違いで止まることを確かめる
  5. 入れたフォルダから部品の一覧を作り、ラボの既知の穴の表と照らして、labpkg 1.0 が引っかかることを確かめる
  6. 終わったら、作業用のフォルダごと消す
Python差し替えで止まることを固める試験
def test_pinned_rejects_swap(lab):swap_wheel(lab, body="changed")r = pip_install(lab, "req-pinned.txt")assert r.returncode != 0assert b"HASHES" in r.stderr def test_sbom_finds_known(lab):pip_install(lab, "req-pinned.txt")hits = check(parts(lab / "site"))assert hits == ["LAB-0001"]

試験は「同じ差し替えで、固定しない方は通り、固定した方は止まる」ことと、「一覧から既知の穴が引ける」ことを固めます。

依存の固定は、手元で確かめられる守りの最初の 1 つです。その外側に、ビルドの環境を分けて完全性を確かめること、署名の鍵を守ること、委託先との接続を台帳で管理することが続きます。NIST の SP 800-161 は、作られ方や組み込まれ方が見えにくいことを、供給網のリスクの根として挙げています。

関わる事例

SolarWinds の Orion では、ビルドの仕組みが破られ、2020年3月から6月に出た更新に悪意あるコードが入りました。会社の届出によると、そのコードはソースコードの置き場には無く、ビルドの段階で入れられていました。CISA によると、混ざった部品は SolarWinds の正規の署名の証明書で署名されていました。ビルドの環境を分けて完全性を確かめることと、署名の鍵を守ることが、ここから来る守りです。

Log4Shell (Apache Log4j の脆弱性、CVE-2021-44228) では、広く使われる部品に重大な欠陥があり、どの製品や機器にその部品が入っているかを、各組織がすぐに洗い出せませんでした。米国の Cyber Safety Review Board の報告は、使っている所を探して企業と作り手が奔走したと書いています。部品の一覧と依存の棚卸しが、まさに効く場面です。MOVEit Transfer の事例 (CVE-2023-34362) も、自分では書いていない部品の穴の例です。CISA と FBI によると、インターネットに公開された MOVEit Transfer のウェブアプリに仕掛けが置かれ、その下のデータベースからデータが盗まれました。

委託先の側からは 2 件です。イセトーでは、受託の業務で生じた帳票のデータを、扱ってはならないサーバに便宜的に保管し、消すべきデータも消していませんでした。個人情報保護委員会によると、データを置く場所の決まりは社内だけの物で、委託元との契約書には書かれていませんでした。大阪急性期・総合医療センターでは、給食の委託事業者の側から病院のサーバーに入られました。調査委員会は、病院とベンダーのあいだの責任の分かれ目の不明瞭さを中核の要因に挙げ、脆弱性の管理の役割分担も問題にしています。

IPA の「情報セキュリティ10大脅威 2026」でも、組織の 2 位は「サプライチェーンや委託先を狙った攻撃」で、8年連続の選出です。

確認クイズ

1 問目

依存の版とハッシュを requirements で固定しました。これで防げることはどれですか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

2 問目

広く使われる部品に重大な穴が公表されました。最初に答えたい問いはどれですか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

説明課題

次のことを、自分の言葉で 3 行にまとめてください。書けたら、このレッスンは修了です。

  • 依存の 1 つについて、部品の一覧をどう作り、既知の穴とどう照らすか
模範解答を見る

まず依存の版とハッシュを固定し、入れるたびに同じ物が入るようにする。入れたあとで、入っている部品の名前と版を一覧にし、公開の脆弱性の情報と名前と版で突き合わせる。版を固定していないと一覧が入れるたびに変わるので、固定と一覧は組で持つ。

一次資料

どれも 2026年10月24日に開いて、題と中身を確かめました。

次へ

次のレッスンは「法務と倫理」です (準備中)。技術としてできることと、してよいことの境目を、調べる前に書面で決める理由を扱います。

次のレッスン 5-3 法務と倫理 準備中

このレッスンにつながる物