ソフトウェアサプライチェーンセキュリティとは何か?

ソフトウェアサプライチェーン攻撃は 、ほとんどのセキュリティチームが予想していたよりも急速に加速しています。Sonatypeの2026年のソフトウェアサプライチェーン現状レポートでは、2025年にオープンソースリポジトリに公開された新しい悪意のあるパッケージが454000以上を特定し、累計は1を超えることが報告されています。20192百万。組織がより多くのオープンソースソフトウェアを消費し、コンテナベースのワークロードを出荷し、ますます複雑なパイプラインを通じてソフトウェアを配布するにつれて、その爆発範囲は拡大し続けています。

ソフトウェアサプライチェーンセキュリティとは、開発者が書くソースコードから取り込む依存関係、コードをコンパイル・パッケージングするビルドシステム、アーティファクトを保存するレジストリ、そしてそれらのアーティファクトを本番で動かすインフラに至るまで、ソフトウェアの構築と提供に関わるすべてのコンポーネント、プロセス、システムを保護する分野です。これは単なる展開時の確認ではなく、ライフサイクルの問題です。

この分野が従来のアプリケーションセキュリティと異なるのは、その範囲にあります。アプリケーションのセキュリティは、あなたのチームが書くコードに焦点を当てています。サプライチェーンセキュリティは、コードが依存するすべての要素と、本番環境に至るコードに関わるすべてのものに焦点を当てています。コンテナベースのデリバリーパイプラインの場合、すべてのベースイメージ、すべてのパッケージ、すべてのビルドツール、そしてすべてのレジストリのやり取りが攻撃対象の一部です。

なぜ今、ソフトウェアサプライチェーンのセキュリティが重要なのか

ソフトウェアサプライチェーンセキュリティの緊急性は、ソフトウェア構築の構造的な変化によって推進されています。現代のアプリケーションは、ゼロから書かれるのではなく、圧倒的に既存のコンポーネントから組み立てられています。典型的なコンテナイメージには数百のパッケージが含まれ、それぞれが独自の依存関係ツリー、メンテナ、更新のリズムを持っています。これらの要素はすべて信頼の決定であり、ほとんどの組織は意図的ではなく暗黙的に信頼の決定を行っています。

依存の問題は信頼の問題です

開発者がプロジェクトにパッケージを追加するとき、そのパッケージが主張通りに動作し、メンテナが本人であること、パッケージレジストリが侵害されていないこと、そしてパッケージが引き続きセキュリティアップデートを受け取ることを信頼しています。この信頼の決定を組織内のすべてのコンテナイメージの依存関係に掛け合わせると、暗黙の信頼の規模が明らかになります。

攻撃者は、広く使われている単一のパッケージを侵害することで、数千の下流組織にアクセスできることを認識しています。依存関係の混乱、タイプポスクワッティング、メンテナアカウントの乗っ取りなどの手法は、攻撃者の手法として標準的な手段となっています。ソフトウェアサプライチェーン攻撃の影響は最初の侵害をはるかに超え、影響を受けたコンポーネントを消費するすべての組織に広がります。ソフトウェアサプライチェーンは、信頼関係が暗黙的であり、検証インフラがしばしば欠如しているため、好まれるベクトルとなっています。

コンテナは攻撃面を変えました

コンテナセキュリティは常に 多層的な課題でしたが、コンテナ化はサプライチェーンのセキュリティ課題を加速させ、多くの組織に今も追いつきつつあります。コンテナイメージとは、アプリケーションコードとそのオペレーティングシステムの依存関係、実行時、設定をまとめた完全かつ不変のソフトウェアアーティファクトです。その不変性はセキュリティ上の利点であり、テストしたものは展開するものとまったく同じです。しかし同時に、その画像のすべての層にあるすべての脆弱性は、積極的にスキャン・検証・更新を行わない限り、本番環境に送られます。

コンテナレジストリはサプライチェーンの中で最も重要なポイントの一つとなっています。画像が保存され、配布され、デプロイのために引き出される場所です。攻撃者が改ざんされたイメージをレジストリにプッシュしたり、デプロイパイプラインを騙して未検証のイメージを引き出させたりすれば、コードレベルのセキュリティ制御を発動せずに本番環境に侵入します。レジストリのセキュリティ、画像署名、プルポリシーは、コンテナ化配送がデフォルトになる前は存在しなかったサプライチェーンのセキュリティ上の懸念事項です。

規制圧力が加速しています

政府や業界の義務付けにより、サプライチェーンのセキュリティは単なるベストプラクティスではなく、コンプライアンス要件となっています。国のサイバーセキュリティ改善に関する大統領令14028は、米国連邦ソフトウェアサプライヤーに対し、SBOM生成および安全な開発慣行を含む特定のサプライチェーンセキュリティ基準を満たすことを義務付けています。NISTのセキュアソフトウェア開発フレームワーク(SSDF)が参照アーキテクチャを提供します。また、SLSA(ソフトウェアアーティファクトのサプライチェーンレベル)は、アーティファクトが安全に構築されたことを検証するための段階的なフレームワークを提供しています。

これらの枠組みは単なる政府の要件ではありません。彼らは業界を超えた調達基準を形成しています。現代のソフトウェアは圧倒的にオープンソースのコンポーネントから構成されており、そのコンポーネントにはしばしば既知の脆弱性が存在します。出所証明、SBOM、検証可能なビルドプロセスを通じてサプライチェーンの健全性を証明できない組織は、企業や公共部門の契約からますます締め出されています。

ソフトウェアサプライチェーンセキュリティの仕組み

サプライチェーンのセキュリティは単一のツールや実践ではありません。これはソフトウェアの提供パイプラインのあらゆる段階で適用される一連のコントロールです。各ステージには独自の攻撃面があり、特定の保護が必要です。

ソースコードと依存関係の保護

サプライチェーンはコードの始まりから始まります。ソースコードリポジトリには、アクセス制御、コミット署名、そして許可された変更のみがコードベースに反映されるように分岐保護ルールが必要です。しかし、より大きなリスクは通常、ファーストパーティコード自体ではなく依存関係にあります。

サプライチェーンセキュリティのための依存管理は、単にパッケージを更新するだけにとどまりません。それは、パッケージが信頼できるソースから来ていること、公開後に改ざんされていないこと、そしてパッケージが依存するパッケージの推移依存関係が信頼できるかどうかの検証を含みます。ロックファイル、ハッシュ検証、依存関係のピンニングが基本的な制御です。プライベートレジストリーやキュレーションされたパッケージフィードは、依存関係ツリーに入るものに対する組織的なコントロール層を追加します。

ビルドプロセスの安全確保

ビルドシステムは、ソースコードや依存関係をデプロイ可能なアーティファクトに変換するものです。侵害されたビルド環境は、ソースコードがどれだけクリーンであっても、生成されるすべてのアーティファクトに悪意のあるコードを注入する可能性があります。ビルドの整合性とは、孤立した一時的な環境でビルドを実行し、毎回クリーンスタートを切り、何がどのツールでどのソースから作られたかを正確に記録する出所証明書を作成し、最終的な成果物のすべてのコンポーネントの完全なインベントリを提供するSBOMを生成することを意味します。これは、ソースコードレベルでは侵害が見えないため、最もセキュリティを確保するのが難しい段階の一つです。

SLSAフレームワークレベルはここで有用な成熟度モデルを提供します。SLSAビルドレベル 3では、ビルドプロセスは強化されたビルドプラットフォーム上で実行され、出所は偽造不可能であり、ビルドプラットフォームは各ビルドを分離して実行間の改ざんを防ぎます。ここで、 強化され出所検証された画像 が不可欠となり、各画像がどのように作成されたかを暗号学的に証明できます。

コンテナイメージとレジストリーの保護

コンテナ画像は現代のサプライチェーンにおける主要な配送アーティファクトであり、画像セキュリティが中心的なサプライチェーンの関心事となっています。画像の保護はベース画像から始まります。もし基盤が未検証で、時代遅れであったり、不要なパッケージで肥大化している場合、その上に構築されたすべての画像がそのリスクを引き継ぎます。

信頼されたベースイメージは最小限で、定期的に上流のセキュリティ修正に対して再構築され、検証可能な出所で配布されます。これらは、すべてのパッケージを記録するSBOM、隠蔽されず透明な脆弱性スキャン結果、そして画像が構築されて以来改ざんされていないことを消費者が確認できる暗号署名を備えています。 

この透明性の違いは重要です。一部の画像提供者は、スキャン結果をきれいに見せるために脆弱性データを抑制または軽視しています。本当に信頼できる画像は、まだ修正されていないものを含めてすべてを示してくれるので、チームは不完全な情報に基づいて行動するのではなく、情報に基づいた判断を下せます。

レジストリセキュリティは、誰がイメージをプッシュ・プルできるかを制御し、イメージ署名ポリシーを強制し、展開前に画像の脆弱性をスキャンし、すべてのレジストリとのやり取りの監査トレイルを維持することを含みます。コンテナレジストリを信頼できる真実の情報源として扱う組織は、サプライチェーンの侵害を防ぐ上で実質的に有利です。

デプロイメントと実行時間の確保

サプライチェーンの最終段階は展開と実行時間です。デプロイ管理により、信頼できるレジストリからの認証済み署名済みイメージのみが本番環境に取り込まれます。アドミッションコントローラー、画像検証ポリシー、デプロイ時のSBOMチェックは、未検証のアーティファクトが本番環境に到達するのを防ぐ執行ポイントを作成します。

ランタイムセキュリティは最後の防御層を追加します。完全に安全に構築・デプロイのパイプラインがあっても、ランタイム監視は、予期せぬネットワーク接続、異常なファイルシステムアクセス、または実行すべきでないプロセスなど、侵害されたコンポーネントを示す異常な挙動を検出します。サンドボックス型実行環境は 、侵害されたコンポーネントが以前の制御を通過した場合の爆発範囲を制限する隔離を提供します。

サプライチェーンセキュリティにおけるSBOMの役割

ソフトウェア資材明細(SBOM)は、ソフトウェアの成果物のすべてのコンポーネント(パッケージ、ライブラリ、バージョン、ライセンスおよびそれらの関係)を機械で読み取れるインベントリです。サプライチェーンセキュリティの文脈では、SBOMは他のすべてを可能にする透明性の層として機能します。見えないものは検証できず、SBOMはソフトウェアのアーティファクトの内容を可視化します。

SBOMがサプライチェーンセキュリティツールとして、コンプライアンスの成果物としてSBOMを区別する点は、その生成と使用方法にあります。コンプライアンス志向のSBOMは一度作成され、保管され、監査時に参照されます。セキュリティ指向のSBOMは、各ビルドごとに自動的に生成され、記述されたアーティファクトに付与され、既知の脆弱性、ライセンスの競合、ポリシー違反をチェックする自動化ツールによって利用され、アーティファクトが本番環境に届く前に処理されます。GitHubの脆弱性動向分析によると、 公開されたCVEの数は年々増加しており、自動SBOM駆動のスキャンはオプションではなく必須となっています。

最も効果的なサプライチェーンセキュリティプログラムは、SBOMを説明したソフトウェアとともに移動する生きた遺物として扱います。新たな脆弱性が開示されると、SBOMは即座に回答させてくれます:影響を受けるのか、どこで、どの部署されたアーティファクトなのか?その対応時間こそが、制御された修復と緊急の発進の違いです。導入の詳細は、 当社のソフトウェアサプライチェーンセキュリティベストプラクティスガイドをご覧ください。

4 一般的なソフトウェアサプライチェーン攻撃ベクトル

サプライチェーンがどのように攻撃されるかを理解することは、それらを守るために不可欠です。攻撃ベクトルはパイプラインの異なる段階を標的とし、それぞれに特定の制御が必要です。

1。依存関係に基づく攻撃

これらはソフトウェアが依存するパッケージやライブラリをターゲットにしています。依存関係の混乱は、パッケージマネージャーが名前を解決する方法を悪用し、ビルドシステムを騙して正当なプライベートパッケージではなく悪意のあるパブリックパッケージを引き寄せます。タイポスクワッティングは、開発者の誤字に頼り、人気ライブラリに似た名前のパッケージを登録します。メンテナアカウント乗っ取りは、信頼できるパッケージメンテナの認証情報を侵害し、正当な配信チャネルを通じて悪意のあるアップデートを押し流します。

2。ビルドシステムの妥協

ビルドシステムを侵害した攻撃者は、生成されるすべてのアーティファクトにコードを注入できます。これは特に危険です。なぜならソースコードはクリーンなままで、コードレビューでは侵害を見つけられないからです。

3。イメージおよびレジストリ攻撃

コンテナ固有の攻撃ベクターには、改ざんされた画像を公開レジストリーにプッシュしたり、人気のある公式画像を模倣した名前の悪意のある画像を作成したり、誤設定されたレジストリアクセス制御を利用して正当な画像を侵害された画像に置き換えたりすることが含まれます。画像署名の検証やレジストリアクセス管理ポリシーを持たない組織は、これらのベクターに対して特に脆弱です。

4。CI/CDパイプラインの活用

CI/CDパイプラインはしばしば権限(シークレットへのアクセス、デプロイ認証情報、本番環境へのアクセス)を持ち、高価値のターゲットとなります。攻撃者はパイプライン設定を悪用して秘密を抽出したり、ビルド出力を改変したり、正当なワークフロー中に実行されるステップを注入したりします。

AIコーディングエージェントの台頭は、この脅威に新たな側面を加えています。コード生成や依存関係を修正するエージェントは、安全で孤立した環境で動作しなければ、機械の速度でサプライチェーンのリスクをもたらす可能性があります。毒入りパイプラインは、悪意のあるペイロードを運びながら、すべての自動セキュリティチェックを通過するアーティファクトを生成できるため、特に危険です。

ソフトウェアサプライチェーンセキュリティの基本原則

効果的なサプライチェーンセキュリティプログラムは、技術実装と組織文化の両方を導く一連の原則を共有しています。

ソフトウェアサプライチェーンセキュリティプログラムの開発

アドホックなセキュリティ慣行から構造化されたサプライチェーンセキュリティプログラムへ移行するには、パイプラインの各段階でコントロールを重ねることが必要です。目標は一度にすべてを実施することではなく、基盤を築き、組織が成熟するにつれてそれを基盤に構築することです。

1。信頼できるイメージ財団を築く

ほとんどの組織が取れる最も高いレバレッジは、ベースイメージに何を入力するかをコントロールすることです。開発者が検証なしに公的レジストリーから恣意的な画像を抽出しているなら、他のサプライチェーンセキュリティ投資はすべて不安定な基盤の上に築かれています。

信頼できるイメージ財団とは、最小限(攻撃対象を減らし)、定期的に再構築(上流の修正を取り入れて)し、出所証明やSBOMとともに配布される、承認されたベースイメージの厳選セットを維持することを意味します。 

良いニュースは、これを一から作る必要はないということです。SLSAビルドレベル3出所と完全な脆弱性透明性を備えた強化・継続的に再構築されたベースイメージは、標準イメージのドロップイン代替として使用できるため、チームは既存のCI/CDパイプラインを改修することなく採用できます。

2。SBOMの生成と消費の実装

SBOMはすべてのビルドパイプラインの一部として自動的に生成され、記述されたアーティファクトに紐づけられ、脆弱性やポリシー違反をチェックする自動化ツールによって利用されるべきです。標準的なSBOMフォーマットであるSPDXとCycloneDXは、どちらもスキャンおよびポリシーツールで広くサポートされています。一つ選び、組織全体で標準化しましょう。

3。イメージ署名と検証を展開します

イメージ署名は、画像を構築した主体とそれを展開する環境との間に暗号的な信頼の連鎖を作り出します。署名キーは中央管理されるべきで、署名はビルドパイプラインの一部として自動的に行われ、検証は導入時のアドミッションコントローラーやレジストリポリシーを通じて強制されるべきです。画像が信頼された鍵で署名されていなければ、本番環境に届くことはありません。

4。レジストリおよび画像アクセスポリシーの強制

開発者やデプロイメントパイプラインがどのレジストリーから取得できるかをコントロールしましょう。未承認の公開レジストリーへのアクセスをブロックし、画像は認証済みのソースからの提供を求めるポリシーを施行してください。Docker Desktopでは、 レジストリアクセス管理 がこれらの制御を提供し、CI/CDだけでなく開発者ワークステーション間でポリシーが一貫して適用されるようにします。

5。脆弱性スキャンをパイプラインに統合する

スキャンは複数のポイントで行うべきです: 

• 依存関係が追加されるとき
• 画像が構築されるとき
• 画像がレジストリーにプッシュされるとき
• 展開されたアーティファクトに対して継続的に

目標は、修復が最も安価で混乱の少ない段階で、パイプラインの早期に脆弱性を発見することです。継続的な脆弱性分析を開発者のワークフローに直接統合し、問題を明らかにしてエンジニアが対応できるようにし、セキュリティダッシュボードに埋もれてほとんどチェックされないのを防ぎましょう。

6。サプライチェーンの侵害に対するインシデント対応を確立する

サプライチェーンのインシデントは、侵害がしばしば組織外で発生するため、通常のセキュリティインシデントとは異なります。インシデント対応計画は、信頼された依存関係が侵害された場合、ベースイメージに新たに明らかになった脆弱性がある場合、またはビルドシステムが検証不能なアーティファクトを生成する場合などを考慮しなければなりません。 

どの配布アーティファクトが影響を受けているかを速く特定できれば(SBOMが自ら支払う部分です)、対応も速くなります。

サプライチェーンのセキュリティはどの段階にありますか?

サプライチェーンのセキュリティ成熟度は組織ごとに大きく異なります。この自己評価を使って、あなたの組織がどこに位置し、次に何を優先すべきかを特定しましょう。

フレームワークと標準

いくつかのフレームワークは、サプライチェーンのセキュリティに対して構造化されたアプローチを提供しています。これらは競合するのではなく補完的なものであり、成熟した組織は通常、複数のフレームワークに沿うものです。

SLSA(ソフトウェアアーティファクトのサプライチェーンレベル)

SLSA はソフトウェアアーティファクトの整合性を検証するための段階的なフレームワークを提供します。そのビルドレベルは、アーティファクトの製造方法に対してますます厳格な要件を定めており、レベル 1 の基本的なビルドの由来から、偽造不可能な出所を持つ強化されたビルドプラットフォームまで 3。SLSAは、抽象的なサプライチェーンセキュリティ目標を具体的で検証可能な技術的要件に変換するため、特に価値があります。

NIST SSDF(セキュアソフトウェア開発フレームワーク)

NISTのSSDF(SP 800-218)は、組織の準備、ソフトウェアの保護、十分に安全なソフトウェアの生成、脆弱性対応の4つの実践グループを中心とした包括的な安全開発実践を提供します。これは大統領令 14028に基づく連邦ソフトウェアサプライチェーン要件の主要な参照枠組みです。

OpenSSFスコアカードとGUAC

オープンソースセキュリティ財団は、オープンソースプロジェクトのセキュリティ状況を評価するためのツール(Scorecard)や、サプライチェーンメタデータの集約・クエリ(GUAC、Plan for Understanding Artifact Composition)のためのツールを提供しています。これらのツールは、組織がどのオープンソースコンポーネントを信頼すべきかについて情報に基づいた判断を下すのに役立ちます。

はじめ

サプライチェーンセキュリティはインフラ分野です。コンプライアンスチェックリストではなくパイプラインコントロールのセットとして取り組む組織こそが、最も強靭なソフトウェアデリバリーシステムを構築する組織です。このガイドの実践は段階的にレイヤー化するように設計されています。もしあなたの組織がゼロから始めるなら、最も高いレバレッジをかける行動から始めましょう:信頼されるイメージ基盤を築くことです。ベースイメージに何を入れるかを制御し、SBOMを自動的に生成し、そこからパイプラインの各段階で検証を強制します。

Docker Hardened Imagesは 、SLSAビルドレベル 3 の出所、継続的な脆弱性監視、ビルドから展開までの整合性を検証する暗号署名を備えた本番環境の基盤を提供します。Docker Scout による継続的な脆弱性分析と、ポリシー強制のためのレジストリアクセス管理を組み合わせることで、チームは全配送パイプライン全体にわたるサプライチェーンセキュリティのためのインフラ層を作成できます。

硬化画像の全カタログをご覧いただき、今日からベース画像の交換を始めましょう。

よくある質問