5 開発チーム向けソフトウェアサプライチェーンセキュリティのベストプラクティス

ソフトウェアのサプライチェーンセキュリティを理解することは一つのことです。実際のパイプラインで、実際の締め切りや制約がある中で実践することはまた別の問題です。ほとんどの組織は自社のソフトウェアサプライチェーンが拡大する攻撃対象であることを認識していますが、その認識を具体的で繰り返し可能な実践に翻訳するのは難しい作業です。

しかし、なぜ今チームがこの問題に取り組む必要があるのでしょうか?Sonatypeによると、2025で特定されたオープンソースマルウェアの99%以上がnpm上で発生しています。そして最初の自己複製型npmワームが登場し、開発者環境に自律的に広がり、数日以内に数百のパッケージを侵害しました。一方、Verizonの 2025 データ漏洩調査報告 書によると、第三者による漏洩の割合は前年比で2倍となり、 30%に達しました。

本ガイドは、コンテナベースのワークロードを構築・輸送するチームにとって最も重要な実践に焦点を当てています。ソフトウェア提供の自然な流れに沿って、信頼できるコンテンツ、ビルドセキュリティ、事前展開検証、アクセスおよびポリシー制御、継続的な監視という5つのカテゴリーに分類されています。こうすることで、あなたのチームはますます自動化され高度な攻撃に対応できるソフトウェア サプライチェーンをより適切に守 ることができます。

1。まずは信頼できるコンテンツから始めましょう

検証済みで最小限のベース画像を選びましょう

すべての コンテナイメージ は、そのベース画像のセキュリティ体制を受け継ぎます。もしその基盤に未修正の脆弱性や古いライブラリ、不要なコンポーネントが含まれている場合、そのリスクはその上に構築されたすべてのイメージに広がります。サプライチェーンの第一かつ最も高いレバレッジの実践は、最小限で継続的に維持され、検証可能なベースイメージを選択することです。 

完全なSBOM、SLSAビルドレベル 3での出所証明、デプロイ前に検証可能な暗号署名を含むベースイメージを探しましょう。最小限のイメージは、本番作業ではほとんど必要とされないものの攻撃者が頻繁に悪用するシェル、パッケージマネージャ、ユーティリティを除去することで攻撃面を削減します。ここで、 強化され、出所が確認されたベース画像 が基盤となるのです。各ベース画像ごとにカスタムのハードニングスクリプトを維持するのではなく、チームはソースから再構築した画像から、どのように作成されたかを完全に透明にして始めることができます。

ピン依存関係と整合性検証

依存性ピンニングは、サプライチェーン攻撃の一カテゴリーを防ぐ一見シンプルな手法です。Dockerfileがpythonのようなタグを参照する場合、3。12、そのタグは明日の画像ダイジェストを指し示すかもしれませんが、今日とは違うかもしれません。上流で妥協されたり偶発的な変更が静かに建築に流れ込んでいます。

コンテナ画像はタグではなくSHA256 ダイジェストでピンしてください。言語レベルの依存関係(npm、pip、Maven)をロックファイル付きの正確なバージョンにピンし込み、それらのロックファイルの整合性をCIで検証します。ビルドシステムが依存関係を引いて、ハッシュがコミットされたものと一致しなければ、ビルドは失敗するはずです。

• シナリオスポットライト: 例えば、毎晩最新タグのベースイメージからビルドするチームを考えてみてください。ある朝、ルーチンビルドがステージングにデプロイされ、統合テストが失敗し始めます。根本原因は、ベースイメージの上流パッケージ更新が壊れた変更をもたらしたことです。ダイジェストピンと明示的なアップグレードワークフローにより、この種の問題は完全に消え、悪意のある変更が気づかれずに入り込むより危険なバリアントも同様に消え去ります。

2。ビルドパイプラインの確保

ビルドの出所と証明の強制

ビルド・プローナンスは、SBOMsだけでは解き明かせない問いに答えます。すなわち、この遺物はどこで、どのシステムによって、どの出所から作られたのか?出所がなければ、画像の内容は検証できますが、ビルド環境自体が信頼できるかどうかは確認できません。

SLSAフレームワークは、レベル1の基本的な出所文書から、レベル3で偽造不能な出所を生成する強化され改ざん耐性のあるビルドプラットフォームまで、段階的なビルドインテグリティレベルを定義しています。最低限、ビルドはすべてのアーティファクトを元のコミット、ビルド設定、ビルダーのアイデンティティにリンクさせる署名済みの出所証明を生成すべきです。

実際には、CI/CDシステムを構成してSLSAの出所証明(通常はin-toto認証形式で表現)を各画像ビルドと同時に生成するよう設定します。これらの証明は、イメージを本番環境に許可する前に、デプロイポリシーが検証できる暗号学的証拠となります。

ハードンCI/CDインフラストラクチャ

ビルドパイプライン自体が非常に価値の高いターゲットです。もし攻撃者があなたのCI/CDシステムを侵害した場合、彼らはあなたが生成するすべてのアーティファクトに悪意のあるコードを注入でき、既存のチェックでは検出できないかもしれません。なぜなら、悪意のある改変はソースコードのレビュー後に行われるからです。

主な硬化方法には以下が含まれます:

• ビルド環境を分離し、各ジョブが前のビルドの残留状態を残さず、新しく一時的なコンテキストで実行できるようにします。
• ジョブ作成に必要な秘密を最小限に制限しましょう。
• GitHub Actionsやその他のCIプラグインは、mutable tagではなくfull commit SHAにピン留めてください。
• リリースブランチへのマージ前にコードレビューとステータスチェックを義務付けるブランチ保護ルールを強制します。

CISAは、サプライチェーン保証の基盤要素として システムの完全性構築を重視しています 。アーティファクトを生み出したシステムを信用できなければ、どんなにビルド後のスキャンをしても補いにはなりません。

3。展開前に必ず確認してください

SBOMを継続的に生成・消費する

ソフトウェアの資材表は、正確で最新かつ意思決定に組み込まれている場合にのみ有用です。リリース時に一度SBOMを作成し、それをファイルに保管することはコンプライアンス要件を満たしますが、セキュリティ価値は最小限に抑えられます。

より効果的な方法は、各ビルドでSBOMを生成し、それを画像にアテスメントとして付与し、アドミッションコントローラー、脆弱性スキャナー、ライセンスコンプライアンスチェックで後処理することです。新しいCVEが解除されると、現在のSBOMを持つチームは、どの実行中のワークロードが影響を受けるかを数分で判断できます。彼らがいないチームは数日間にわたる法医学演習を開始します。

SBOMと 悪用性データ(VEX )を組み合わせることで、さらにアクション性の層が加わります。VEX文書は、SBOMの脆弱性が特定の画像の文脈で実際に悪用可能かどうかを示し、アラート疲労を引き起こすノイズを減らし、チームが本当に重要な脆弱性に対処できるようにします。

脆弱性分析を開発者のワークフローに統合する

脆弱性スキャンは、スプリントごとにチェックされるセキュリティダッシュボードではなく、開発者がすでに作業している場所で結果を明らかにするときに最も効果的です。分析を内部開発ループに移すということは、ビルド時、プルリクエスト、ローカル開発時に問題をフラグ付けし、イメージがレジストリに到達する前に行うことを意味します。

ここで、 開発者のワークフローに継続的な脆弱性分析を組み込む ことが不可欠となります。スキャン結果を週次レポートにまとめるのではなく、効果的なプログラムは、それをもたらしたコード変更とともに発見を提示し、実行可能な是正ガイダンスを提示します。

NISTのセキュアソフトウェア開発フレームワーク(SSDF)はこのパターンを強化しています。PWの練習をしてください。7 組織は、人間が読みやすいコードをレビュー・分析し、脆弱性を特定し、セキュリティ要件への適合性を確認することを推奨しています。CI/CDに統合された自動分析は、そのガイダンスのスケーラブルな実装です。

4。アクセスの制御とポリシーの執行

レジストリアクセスとイメージポリシーの管理

コンテナレジストリは、組織が実行するすべてのイメージの配布ポイントです。開発者が任意の公開レジストリから任意のイメージを制限なく取得できれば、サプライチェーンは使用するすべてのイメージの管理者にまで及ぶ。

どの画像が使用許可されるかを制限するレジストリアクセス制御を実装し、すべての画像は認証済みの出版社や社内ビルドから取得することを強制し、画像が本番環境に入る前に署名認証を義務付けます。イメージアクセス管理ポリシー により、チームが自由に開発を試みられる一方で、本番環境では審査済みのポリシー準拠画像のみが消費されます。

• シナリオスポットライト: MedplumHIPAAおよびHITRUSTの要件を満たす顧客を支援するヘルスケア開発者プラットフォームは、コンテナ基盤をDocker Hardened Imagesに移行し、コードベース全体でわずか 54 行の追加・削除 52 しました。その結果、急激に減少したCVE数、デフォルトでの非root実行、そして本番環境でのシェルアクセスがなくなりました。また、監査人に話すためのよりクリーンなストーリーも得られました。カスタムハードニングスクリプトやごとの例外ドキュメントを説明する代わりに、チームは文書化されたハードニング手法やSLSAビルドレベル 3 出所を指摘できます。

パイプライン全体に最小権限を適用する

サプライチェーン攻撃は、過剰に権限が与えられたサービスアカウント、広範な範囲を持つCIトークン、あるいは単一のジョブで必要とする以上のアクセス権を持つ共有認証情報を頻繁に悪用します。配信パイプラインに最小権限を適用するということは、すべての認証情報、トークン、APIキーをその特定のタスクに必要な最小権限に限定することを意味します。

CISAは、すべての開発者およびCI/CDアカウントに対してフィッシング耐性の多要素認証を推奨しています。認証以外にも、ビルドサービスアカウントが本番レジストリにプッシュされないこと、デプロイトークンがビルド構成を変更できないこと、そして単一の認証情報がソースコードと本番環境の両方へのアクセスを許可しないようにしてください。

5。監視し、対応し、改善しましょう

ランタイムモニタリングの実装

静的分析とビルドタイムスキャンは、予想される脅威を捉えます。ランタイムモニタリングは、見逃したものを検出します。サプライチェーンの侵害が事前の管理を突破した場合、ランタイム異常検出は予期せぬ動作を識別する層です。例えば、コンテナからの新しいネットワーク接続が送信されるはずのないもので、不変の画像内のファイルシステムの変更、または画像の通常のプロファイルから逸脱したプロセス実行パターンなどです。

サプライチェーンセキュリティのための効果的なランタイムモニタリングは、従来のアプリケーションパフォーマンス監視を超えています。コンテナワークロードの基準的な挙動プロファイルや、既知の悪意シグネチャだけでなく、逸脱時にトリガーされるアラートが必要です。これは、テスト中は通常通り振る舞うものの、特定のランタイム条件下で悪意のある動作を引き起こす侵害された依存関係を検出するために特に重要です。

インシデント対応をサプライチェーンプログラムに組み込む

サプライチェーンのインシデントが発生した場合、対応速度は準備に依存します。依存関係の侵害、悪意のあるベースイメージ更新、ビルドシステムの侵害に対する対応を練習したチームは数時間で対応します。これらのシナリオを練習していないチームは何日も慌ただしく動き回る。

インシデント対応計画には以下の手順を含めるべきです:

• 侵害された部品から生成されたアーティファクトを特定すること(ここで出所やSBOMが自らの利益を得ます)
• 暴露された可能性のある資格を取り消し、ローテーションすること
• 検証済みのソースから影響を受けた画像の再構築
• ソフトウェアの下流利用者とのコミュニケーション

ベストプラクティスを一目で見れば

はじめ

ソフトウェアサプライチェーンセキュリティプログラムの構築は反復的な作業です。このガイドの実践は全体像を表していますが、そこに至る道は段階的です。まず基盤から始めましょう:信頼されたベースイメージと依存関係の整合性です。ビルドのプロビナンスとSBOMを重ねてみて。その後、プログラムが成熟するにつれてポリシーの執行、開発者統合スキャン、ランタイムモニタリングへと拡大しましょう。

Docker Hardened Imagesは 、これらの実践を実装するチームにとって既成の基盤を提供します。数千枚の最小限で継続的に再構築されたイメージが、SLSAビルドレベル 3 出所、署名されたSBOM、OpenVEXの脆弱性データで出荷されており、カスタム強化パイプラインの維持にかかる負担なしに信頼できる出発点を提供します。SRLabsによる独立した評価により、DHIのプロヴィナンスチェーン、署名モデル、脆弱性管理ワークフロー、そして継続的な強化実践が検証されました。 

これにDocker Scout を組み合わせて、開発ワークフローに直接統合した継続的な脆弱性分析を組み合わせることで、エンジニアリング組織にスケールするサプライチェーンセキュリティプログラムをサポートするコアツールが完成します。

• 硬化画像の全カタログをご覧いただき、今日からベース画像の交換を始めましょう。
• ソフトウェアサプライチェーンのセキュリティ確保に関する詳細は、弊社のホワイトペーパーをダウンロードしてください。

よくある質問