コンテナを冷まして出荷し、サプライチェーンの安全を確保

by Canonical on 18 May 2026

過去の侵害と今後の侵害

2025年9月、chalkやdebugなどの一般的なJavaScriptパッケージ数十個がnpmレジストリ上で侵害を受けました。どこにでも使用されるパッケージが侵害を受けたため、フロントエンドのアプリから、バックエンドのマイクロサービス、CIツールまですべてに影響が及びました。開発者に罪はありません。「npm install chalk」といういつものコマンドを実行しただけです。しかし、そこにマルウェアが忍び込みました。

オペレーティングシステムにバグがあったのではありません。ノートPCからウイルスが入ったのでもありません。それはサプライチェーン攻撃でした。開発者がソフトウェアを作るための材料に誰かが毒を仕込んだのです。目新しいことではありません。開発者の1人がフィッシングにかかり、悪意あるコードを含む更新を1回公開し、多数のユーザーがそれを正式な更新だと思ってダウンロードしたということです。

実際、それは正式な更新でした。開発者はマルウェアの配布を意図せず、入っていることさえ知りませんでした。

このときは単にnpmでした。でも、同じ手法でlibcurl、zlib、opensslなど、コンテナがアプリケーションの実行前から依存するシステムライブラリを標的とすれば、実行または開発するすべての基盤が侵害を受けてしまいます。

これが、サプライチェーンセキュリティの「温度」問題です。業界はできたてで熱すぎるコードを出荷しているのです。

コンテナ開発の2つのアプローチ

現代のソフトウェアの多くはコンテナ内で実行されます。しかし、中のコードが十分に冷めているか、アップストリームのオーブンから出したてかには、業界内でも大きなばらつきがあります。

ナイトリーリビルド

近年、人気が高まっているのは、毎晩、すべてのパッケージの最新バージョンをアップストリームから取り込み、最初からコンテナイメージを生成する方法です。署名、検証、フットプリントの最小化には各種ツールを使用します。一見、これは完璧に見えます。ソースがクリーンなら良いコードを短時間で出荷できます。アップストリームでバグを修正すれば、次の夜のリビルドでパッチが得られます。

でもソースに不正コードが入ったら？

小型で、追跡可能で、エンタープライズグレードの完璧なマルウェアが生成、署名、配信されることになります。もちろん再現性もばっちり。いくら優れたインフラストラクチャでもバックドアがあれば意味がありません。

これが、アップストリームのオーブンから直接コードを出荷するということです。ラックで冷やす時間も寝かせる時間もなく、温度を確認する人もいません。

意図的更新

Ubuntuは別の方法をとります。安定リリースは2年に1回の配信です。パッケージのバージョンは固定し、セキュリティ修正は局所的なバックポートで行います。新機能や審査の終わっていないアップストリームの変更は取り込まず、脆弱性だけを修正するということです。根拠に基づく意図的な更新です。

派手さはありませんが、落ち着いて、慎重で、予測可能な方法です。

ナイトリーリビルドのように頻繁ではありませんが、コードにはすでに実績があるので、安定性と信頼性が得られます。冷えている、つまり時間、詳細な点検、期待どおりの動作に依存する実運用環境のワークロードによって十分にテスト済みなのです。

サプライチェーンのセキュリティに絶対的な確実性はありません。誰かがlibcurlにバックドアを仕込もうとしたら？Ubuntuベースのコンテナは、リリース計画に入っていない更新をおそらく取得しないでしょう。アップストリームの最新コード（HEAD）を追いかけるチームが「熱々の」コードをユーザーに届けるのに対し、意図的な更新のモデルは動じず、影響を受けません。

そのコンテナがcurlの2022年のバージョンを実行しているのは、Ubuntuが遅れているのではなく、メンテナーがそのバージョンが何をするのかを正確に把握しているからです。もっと重要なのは、長く冷やしておいたそのバージョンが「何をしないのか」です。冷えたコードとは予測可能なコードなのです。

バックドアを最初に出荷するのは誰？

次の状況を考えてみましょう。悪意のあるパッチがアップストリームにマージされるとします。見つかりにくく、署名もされ、CIも通過します。クリーンに見えるため、「熱々」の状態で世界中に公開されます。

ナイトリーリビルド方式では、自動的にアップストリームのコードが取り込まれます。イメージが生成、スキャンされ、CVEは検出されません。まったく新しいコードだからです。署名済みでミニマルで、完璧に悪意あるコードが、何の疑問も持たれず、熱いまま配信されます。

Ubuntuのように意図的に更新されるディストリビューションはどうでしょうか。固定されたバージョンは古いかもしれませんが、予測可能で安定しています。Ubuntuのメンテナーがコードを冷ましている間に悪意あるコードがアップストリームで発見されるため、ユーザーに届きません。

ゼロCVEの問題

セキュリティ検出ツールはCVEをうるさく警告します。1つでもあれば「危険」です。ゼロなら万事OK。

しかし実際のところ、CVEは長く調査されている古いコードによく見つかります。新しいコードはまだ誰も調べていないのでゼロになります。新しいコードの場合、CVEゼロは安全ではなく未検査を意味します。新しすぎて、中になにがあるかまだ誰も知らないということです。

アップストリームから毎晩リビルドする場合、まったく検査されていないコードを取り込むことになります。署名してから質問するのは、十分に冷める前に料理の味を判断するのと同じです。

本当のセキュリティには時間がかかる

セキュリティは単なるスキャンの結果ではありません。それは厳しい考え方であり、慎重な自制を必要とします。言い換えれば、アップストリームのコードを採用する前の警戒心、すでに機能しているものを変更するときの厳しさ、信頼を広げることへの懐疑心です。

たとえばUbuntuでは、アップストリームが間違っているかもしれない、急ぎすぎかもしれない、侵害を受けているかもしれないことを想定しています。だからUbuntuのメンテナーは慎重に判断します。毒見してからテーブルに出すのです。台所から持ち出す前に料理を冷まし、自分で毒見していない食べ物はテーブルに出しません。

ナイトリービルドのモデルは、ミニマリズム、透明性、新しさを重視していますが、その新しさがリスクになることもあります。「できたて」は「熱すぎて信用できない」かもしれません。

新しさがリスクになる

コンテナを「クリーン」に保つとされるアップストリームからのナイトリービルドは、バックドアを取り込む仕組みでもあります。逆に、パッケージのバックポートはコンテナを凍結するように見えますが、実は不正の侵入を防ぎます。

あるキッチンでは集まった素材を即座に調理します。別のキッチンでは素材を吟味し、時間をかけ、安全だとわかってから調理するというわけです。

サプライチェーン攻撃がコアシステムのライブラリに及んだときは、どちらの方法がマルウェアを環境に取り込み、どちらがその回避に役立つのか、改めて考える必要があります。

リビルドは検証ではない

すべてのパッケージをリビルドし、レイヤーをスキャンし、アーチファクトに署名することは可能です。ただし、コードの意図を把握せず、どこから来たのか、なぜ変更されたのか、誰が差分にコードを追加したのかわからないとすれば、それは単に他人のマルウェアを、より高速で性能の高いインフラでリビルドしているに過ぎません。

リビルドとは複製です。何を複製しているのか知っているときは有用です。しかし、侵害されたコードを忠実にリビルドしても、検証していることにはなりません。逆に攻撃者のCIをすることになります。誰かが仕込んだ毒を温め直し、新しい料理だと言うのと同じです。

別の意味のCVE

「既知CVEゼロ」をもてはやされる今、人々は大きなリスクを無視しています。「このイメージに脆弱性はあるか」と問わないからです。今こそ「信用しすぎではないか」という問いかける必要があります。

CVE数は現れるのが遅い指標です。侵害はCVEが検出される前に発生します。つまり本当の脆弱性はパッケージそのものではなく、その考え方にあります。アップストリームが公開された瞬間に安全だと考えることが問題なのです。

結び

問題は、特定のベンダーやプロジェクトの話ではありません。業界が信頼と「温度」をどう扱っているかの問題です。

意図的更新では、アップストリームが常に信頼できるわけではないと考え、慎重に扱います。そしてコードに冷却期間を与えます。一方、ナイトリーリビルドは、アップストリームは信頼できると想定し、最新に保つことを重視するため、絶えず動いています。そしてすべて「熱々」でユーザーに届けます。

18か月間手を触れていないコンポーネントが、パイプラインの中で最も安全なコンポーネントということもあります。忘れられていたからではなく、十分に冷却され、そこに存在する価値を実証したからです。

ソフトウェアサプライチェーンのセキュリティでは、最善のコードが常に最新とは限りません。最善なのは真実が表面に出るまで長く冷却されたコードです。ですからコードを冷ましてください。そのほうが味も良くなります。