【ソフトウェアサプライチェーン編】依存ライブラリと更新経路を守る｜CTF思考フレームワーク #34

こんにちは、アンペンです！

前回は、テンプレートエンジンに混ざる悪意でRCEに至るSSTIを扱いました。

今回は、自分のコードではなく『使っているライブラリ』が攻撃面になるソフトウェアサプライチェーンを見ていきます。依存パッケージから刺される構図と、その守り方を学びましょう。

サードパーティのライブラリって、誰でも使ってるよね？それで攻撃されるの？

便利な反面、依存ツリーのどこか1つが悪意を持つと、自分のコードも一緒に動かされてしまう。これがサプライチェーン攻撃の怖さだよ。

ここまでは『自分のコードの穴』を中心に見てきました。今回はガラッと視点を変えて、“自分のコードは完璧なのに刺される”という、ちょっと理不尽な話です。現代のアプリは、世界中の人が書いたライブラリの上に成り立っています。その中のたった一つが悪意を持つだけで、あなたのアプリごと乗っ取られてしまう。今日は食材の流通網にたとえて、この“見えない他人任せ”のリスクをほどいていきます。

依存は『ピラミッド構造』

現代のアプリは、自分が書いたコードよりも、ライブラリ(npm/pip/RubyGems/Maven等)の方がコード量で圧倒的に多くなりがちです。そのライブラリも、さらに別のライブラリに依存しています。

つまり、依存はピラミッド構造で広がっており、どこか1段が悪意を持つだけで上層まで影響が及びます。これが現代の最も深刻な攻撃面の一つです。

ここで効いてくるのが『信頼の連鎖』という考え方です。あなたが直接選んだライブラリは、たぶん信頼できるものでしょう。でも、そのライブラリが裏で使っている“孫ライブラリ”“ひ孫ライブラリ”まで、あなたは選んでいません。なのに、それらのコードはあなたのアプリの中で同じ権限で動く。つまり“顔も知らない誰か”を、無条件で家に上げているようなもの。直接の知り合いだけでなく、その先までが運命共同体——これがサプライチェーンの本質です。

まず、規模感を実感してください。今どきのアプリは、自分が手で書くコードはほんの一部。残りの大半は、npmやpipで入れた“他人が書いたライブラリ”です。しかもそのライブラリが、また別のライブラリを呼び、それがさらに別を呼び……と、気づけば数百〜数千のパッケージに支えられている。あなたのアプリは、巨大な“他人のコードの山”の上にちょこんと乗っている——まずこのイメージを持つことが出発点です。

図解：自分のコード vs 依存ツリー全体

見える自分のコードはピラミッドの先端で、その下に大量の依存が積み重なっています。攻撃者はこの下層を狙います。

『SBOM』も難しそうな略語ですが、要は“材料表”です。食品のパッケージ裏に原材料が全部書いてあるように、「このアプリは、どのライブラリの、どのバージョンを使っているか」を一覧にしたもの。これがあると、たとえば「あるライブラリに重大な穴が見つかった！」というニュースが出たとき、“うちは使ってる？どこで？”を数分で調べられます。逆に材料表がないと、全部を手で探し回るハメに。いざという時の対応スピードが、まるで変わってくるんです。

サプライチェーン攻撃の3パターン

攻撃の手口は、大きく3つ。『本物そっくりの偽名で公開（タイポ狙い）』『社内パッケージと同名を外部に置いて取り違えさせる』『正規ライブラリ自体を乗っ取って毒を仕込む』。一つ目は、たとえば reqeusts（本物は requests）のような“打ち間違いを待つ罠”。うっかり入れた瞬間、悪意のコードがインストール時に走る——なんてことが起こります。

代表的な手口

• typosquatting：本物に似た名前(reacct など)で偽パッケージを公開し、タイポした人をだます
• dependency confusion：社内プライベートパッケージと同名の悪性パッケージをパブリックに公開、優先順位の隙を突く
• 悪性アップデート/メンテナ乗っ取り：正規ライブラリが乗っ取られ、新バージョンに悪意のコードが混入(event-streamなど)

近年話題になったLog4Shell(Apache Log4j)のような事例では、攻撃の入口は『あるライブラリの脆弱性』そのものでした。発見時にどれだけ素早く対応できるかが、被害規模を左右します。

Log4Shellは、この“依存の怖さ”を世界中に知らしめた事件でした。Log4jという、ほぼ全てのJavaアプリが使っていると言っていいほど普及したライブラリに、深刻な穴が見つかった。すると世界中の開発者が一斉に「うちは使ってる？どのバージョン？」と大慌てで調べ回ることに。問題は脆弱性そのものより、“自分がそれを使っているかすら、すぐには分からなかった”こと。だからこそ、ふだんから材料表（SBOM）を持っておくことが、いざという時の生命線になるんです。

練習は、自分のプロジェクトが“どれだけの他人のコードに乗っているか”をのぞいてみることです。依存ツリーを出力すると、想像の何倍もの数に驚くはず。あわせて、既知の脆弱性スキャン（Dependabotなど）をかけて、危ない依存がないか確認します。攻撃ではなく健康診断。自分のリポジトリの中だけで、安心して試せます。

CTFでやってみよう：依存ツリーを点検

守りについては、最初に“心構え”を一つ。

他人のライブラリの中身まで、全部チェックするのは無理じゃない？

その通りで、完全な事前チェックは現実的に不可能なんだ。だから発想を“防ぐ”から“素早く気づいて、素早く切り替える”にずらす。具体的には、①バージョンをlockfileで固定して勝手に変わらないようにし、②自動スキャンで危ない依存に常時アンテナを張り、③SBOM（材料表）で“どこで何を使っているか”を見える化しておく。そうすれば、悪いニュースが出ても「うちはここだけ、すぐ直そう」と動ける。“ゼロにする”より“最短で対応できる体制”が、この分野の現実解だよ。

守る側なら、「lockfile固定+自動スキャン+SBOM」

サプライチェーン攻撃の守りは、「lockfileでバージョン固定」「CIで自動スキャン」「SBOMで把握」「信頼レジストリへ集約」が中心です。完全防御は難しい領域ですが、検知と切替を素早く行うための準備は不可欠です。

『自分のコードだけ』を守るだけじゃ足りないんだね。

そう。依存ツリーは自分の延長として扱うのが現代の常識。SBOMで見える化しておけば対応速度が違うよ。

ここまでをひと言で言うと、サプライチェーンの守りは『依存も自分のコードだと思って運用する』。他人が書いたものでも、自分のアプリで動く以上、責任は自分側にあります。だから、バージョンを固定し、材料表を持ち、常にスキャンする。“入れっぱなしで放置”をやめるだけで、リスクはぐっと下がります。

まとめ：『依存も自分のコード』として運用する

今日の持ち帰りは『材料表を持ち、いつでも更新できる体制を作る』です。サプライチェーン攻撃は、完全には防げません。でも、自分が何に依存しているかを把握し、危険が分かったらすぐ差し替えられる準備さえあれば、被害は最小限に抑えられます。“ゼロリスク”ではなく“即応できる強さ”——それが、この領域のゴールです。

次回は、APIアクセスを支えるAPI認証を扱います。JWT・OAuth・APIキーが破られる時と、その守り方を見ていきましょう。

次に読みたい記事

参考資料