Tech Insights / Secure Software Supply Chain

セキュアなソフトウェア サプライ チェーン:本番環境への高速かつセキュアなソフトウェア デリバリ

セキュアなソフトウェア サプライ チェーンを導入することは、ソフトウェア開発を安全に行い、DevSecOps の能力を促進するうえで非常に重要です。


セキュアなソフトウェア サプライ チェーンとは

セキュアなソフトウェア サプライ チェーンとは、ソフトウェア(およびそのすべての依存関係)を安全かつ確実に一貫性のある方法で本番環境に提供するために使用する一連のプロセスを指し、ソース コードの定期的なアップデートや、定義済みのコントロールによるプラットフォーム ガバナンスを通じて実現されます。

セキュアなソフトウェア サプライ チェーンを導入することで、コードとその依存関係について信頼性とコンプライアンスを確保し、最新でリリース可能な状態に維持できます。また、定期的なスキャンを通じて脆弱性を検知および報告し、排除することもできます。定義済みの一連のポリシーをチェーン内のすべてのシステムに一貫して適用することで、不正アクセスを防止し、署名されていないパッケージが実行されないようにします。




セキュアなソフトウェア サプライ チェーンのベスト プラクティス

セキュアなソフトウェア サプライ チェーンを構築するには、組織が許容可能なリスク レベルを鑑みながら、高速性と品質を維持しつつ、ソフトウェア パッケージ(ファーストパーティまたはサードパーティ製)をソース コードから本番環境に提供するための一連のツールや手法が必要になります。

VMware は、組織がセキュアなソフトウェア開発を通じてセキュリティをアジャイル ソフトウェア開発に組み込み、ソフトウェア サプライ チェーンへの攻撃による被害を軽減するために重視するべき 5 つの領域を特定しました。

  1. 1. セキュアなアプリケーション ソース コード

    ソフトウェア開発ライフサイクルにおいて、サプライ チェーンのなかでもっともコントロールできる部分は、開発者が記述するコードです。安全ではないコードが入ってしまうと、セキュアなサプライ チェーンが無意味なものになります。コードの安全性を確保する戦略を実践することで、サプライ チェーンに対する攻撃を軽減できます。

    ベスト プラクティス

    • 開発者の知識向上に取り組み、本番環境のセキュリティ状態の向上を支援します。
    • コード リポジトリにアクセス コントロールを使用し、コードの不正な変更や不要な変更を抑止します。
    • コードのリンティングや静的コード アクセスを活用し、開発時に発生しやすいプログラミング エラーを検知します。これにより、エラーが本番環境のバグとして悪用されることを事前に阻止します。
    • コードのピア レビューを実施して、ヒューマン エラーによって取り込まれた意図しない脆弱性と、悪意のある人物によって故意に仕掛けられた脆弱性の両方を防ぎます。
    • コードの漏洩やリバース エンジニアリングなどによってソース コードが公開された場合に攻撃を防ぐことができるように、シークレット管理を導入し、ソース コードに機密性の高い認証情報や構成を含めないようにします。
    • ソフトウェア セキュリティ テストの一種である静的アプリケーション セキュリティ テスト(SAST)を使用してソース コードをスキャンし、既知の脆弱なコーディング プラクティスに一致するコーディング パターンを探します。
    • ソース コンポジション分析(SCA)を実施し、アプリケーションに使用されているサードパーティのライブラリ、フレームワーク、コンポーネントを検証します。

    成果

    • アプリケーション開発者は、セキュリティ ベスト プラクティスに従うことで、高品質のコードを開発できます。
    • リポジトリへのすべてのコミットが信頼済みになります。
    • ソース コードには、シークレットやその他の機密性の高い環境データが入りません。
  2. 2. アプリケーションの依存関係の管理

    ビルドを作成するときに、ゼロから始める開発者はほとんどいません。開発者は、開発時間の節約や短縮のために、オープンソースやその他のカタログにある事前作成されたコードを使用できます。このため、ソフトウェアについては、本番環境でアプリケーションの脆弱性をチェックしてパッチを適用するときには、最終ビルドに組み込まれた事前作成済みのコードを考慮に入れる必要があります。

    セキュアなソフトウェアの設計と開発を確実に行うには、アプリケーションの依存関係を明確に可視化できなければなりません。定期的にスキャンを実行し、依存するすべてのライブラリにパッチが適用されており、共通脆弱性識別子(CVE)が含まれていないことを確認しておけば、依存関係が悪用される可能性を軽減できます。

    ベスト プラクティス

    • 定期的なスキャンに依存関係の脆弱性スキャンを組み込み、依存するすべてのライブラリにパッチが適用されており、CVE が含まれていないことを確認します。
    • 脆弱な依存関係に適時パッチを適用します。
    • 依存関係ピンニング(ロックファイル)を使用する(特定の検証済みのバージョンに依存関係を固定する)ことで、依存関係を誤ってアップデートして新しい脆弱性を取り込んでしまうことがないようにします。
    • 多くの開発者によって使用され、よく知られた定評のあるソースから取得した依存関係を使用することを検討します。このような依存関係は、信頼性が高くない場所から取得した依存関係よりも、侵害される確率が低い可能性があります。
    • 使用されている依存関係を正確に把握します。モダン アプリケーションは多くの場合、数十個あるいはそれ以上の依存関係から構成されているため、依存関係階層の深い場所に脆弱性が紛れ込んでしまって攻撃経路が生じることがあります。
    • 新しい依存関係を採用する際には妥当性を検証します。場合によっては、大規模な依存関係を採用しないことで攻撃対象領域を最小にすることができます。
    • 既存の依存関係のアップデートを評価します。ソフトウェア ベンダーは多くの場合、定期メンテナンスの一環として、中央のサーバからアップデートを配布しています。ベンダーのネットワークに侵入できた攻撃者が、定期的な製品アップデートを装ってマルウェアを送り込むことがあります。
    • リスク管理を行います。

    成果

    • 開発者は、サードパーティおよび社内の依存関係の来歴を確実に検証できます。
    • アプリケーション チームは、アプリケーションのソフトウェア BOM を包括的に可視化できます。
    • ステークホルダーは、CVE に対して脆弱なアプリケーションを迅速に特定できます。
    • アプリケーションの依存関係の脆弱性に対して、パッチをスムーズに適用できます。
  3. 3. CI/CD システムの保護

    ガバナンスは、継続的インテグレーションと継続的デリバリ(CI/CD)のパイプラインの制御において要になる要素です。システムを使用する権限が定義され、正しく設定されていることを確認することは、ソフトウェア サプライ チェーンの保護に役立ちます。この設定には、最小権限の原則も含める必要があります。

    ベスト プラクティス

    • CI/CD パイプラインにアクセス コントロールを導入し、抜け道をなくすことでパイプラインのバイパスを防止します。
    • 自動化パイプラインでジョブ、タスク、およびスクリプトを実行するには、必要な最小限の権限を持つシステム アカウントを使用します。
    • プッシュ方式の代わりにプル方式のデプロイを使用します。プッシュ方式のデプロイでは、ターゲット システムの外部に認証情報を公開する必要があります。プル方式のデプロイ シナリオでは、ターゲット システムの認証情報が公開されることなく、コントローラの同期ステータスが Git リポジトリ(GitOps)またはイメージ レジストリから変更されます。
    • CI/CD パイプラインの認証情報管理機能を使用し、デプロイ ツールがもっとも機密性の高い環境に対して認証情報を求めるようにします。
    • ビルド ログと監査証跡を生成して保存します。

    成果

    • 開発者は、サードパーティおよび社内の依存関係の来歴を確実に検証できます。
    • アプリケーション チームは、アプリケーションのソフトウェア BOM を包括的に可視化できます。
    • ステークホルダーは、CVE に対して脆弱なアプリケーションを迅速に特定できます。
    • アプリケーションの依存関係の脆弱性に対して、パッチを比較的スムーズに適用できます。
  4. 4. イメージのビルドとレジストリの保護

    コンテナ イメージの安全性を高めるには、イメージ レジストリ内の重大な CVE の数を減らし、CVE の修正にかかる目標時間を短縮することを目指します。これを達成するには、基本イメージが信頼済みで署名済みであること、そしてイメージ リポジトリに制御ポリシーが適用されていることを確認する必要があります。

    ベスト プラクティス

    • イメージ リポジトリにコントロール/アクセス ポリシーを導入します。CI 自動化プロセスによって認可および検証済みのイメージ参照のみを使用し、それ例外のアクセスを最小限にします。
    • 承認済みの少数の基本イメージを使用し、攻撃対象領域を縮小します。基本イメージへの署名とバージョン管理を確実に行います。信頼済みの基本イメージが判別、利用できるようにして、ビルドに使用します。
    • アプリケーションのイメージやアーティファクトを安全な場所に保存します。イメージ リポジトリにコントロール ポリシーを適用し、イメージに署名したうえでレジストリに保存するようにします。
    • 脆弱性データベースをアップデートし、そのデータベースを定期イメージ脆弱性スキャンに使用します。
    • 信頼済みで既知のアーティファクトのみで構成されたアーティファクトのセットから作成されたセキュアで再現可能なイメージ ビルドを使用します。ビルド時にバックドアが形成されることを困難にし、バックドアが形成されても検知できるようにします。
    • 本番環境にプロモートされるアーティファクトを追跡し、テストに使用されたものと同じアーティファクトが上位の環境にプロモートされるようにします。監査証跡を利用します。
    • イメージのタグ付けを使用します。
    • 構成証明を検証します。

    成果

    • アプリケーション イメージが署名されることで、イメージの整合性を保証できます。
    • イメージをセキュアなレジストリに保存できます。
    • デプロイされたアーティファクトの信頼性が担保されます。
    • イメージの脆弱性を可視化できます。
    • イメージの脆弱性の修正を運用に組み込むことができます。
  5. 5. ランタイムの保護

    ゼロトラスト アーキテクチャと SIEM(セキュリティ情報およびイベント管理)を、高度な脅威検知ツールとともに導入することで、アプリケーションやアプリケーション開発プラットフォームにとってより安全な環境を構築できます。可観測性をプラットフォームの運用に組み込むと、ランタイムを監視し、アプリケーションの振る舞いを理解するのに役立ちます。

    ベスト プラクティス

    • 多数のイベントを関連付けることにより、セキュリティ エンジニアが攻撃を検知できるようにします。これには、攻撃者がアクセスに成功したことを示す特定のイベントを識別できる SIEM ツールや脅威検知ツールなどが使用できます。
    • ランタイム脆弱性スキャンを利用して、Kubernetes 環境の脆弱性を識別します。
    • セキュアなネットワークを導入することで、攻撃者がいずれかのネットワークへのアクセスを取得し、続いてその他の信頼済みのネットワークや環境に簡単に移動するのを防ぎます。セキュアな通信によって転送中のデータを保護することは、攻撃者によるネットワーク トラフィックのスニッフィングを防止するうえで重要です。
    • セキュアなマルチテナンシー戦略を採用します。ネームスペースとクラスタベースの戦略を採用して分離を行い、ロールベースのアクセス コントロールを追加します。
    • 開発環境を正しく構成し、インフラストラクチャの構成エラーによって起こりやすいセキュリティ侵害を回避します。
    • シークレット管理を導入して、シークレットが必要なアプリケーションやサービスにシークレットが安全に配布されるようにし、そのようなアプリケーションやサービスが機能するために必要なシークレットのみにアクセスできるようにします。こうすることで、攻撃対象領域を縮小し、侵害が発生した場合の影響を低減できます。
    • セキュアな環境アクセスを導入し、認可されたユーザーのみが環境にアクセスできるようにします。これを保証するために、複数の異なるセキュリティ コントロールを採用することが適切である場合があります。不正アクセスを検出できる必要があります。
    • 動的なアプリケーション セキュリティ テスト(「ブラック ボックス」テスト)を活用し、実行中のアプリケーションにセキュリティ上の脆弱性や弱点がないか確認します。
    • 署名されていないイメージが本番環境で実行されないようにします。
    • サプライ チェーン内のセキュリティの脆弱性を修正するのに要する時間を短縮します。
    • ポリシーを一貫して適用します。セキュリティ ポリシー、ログ監査、順守ポリシー、ネットワーク ポリシーを決定して適用し、テストを行います。
      • セキュリティ ポリシーおよびアクセス ポリシーを一貫して適用します。
      • セキュアなソフトウェア サプライ チェーンから取得されたものではないコードをシステムが実行できないようにします。
      • (Rego)ポリシーを記述する際にはミスを犯しがちです。適切なテストを行いながら慎重にポリシーを開発する必要があります。
      • 組み込まれたポリシーをテストし、競合が生じないことを確認します。

    成果

    • ワークロードが確実に分離されるため、隣接するワークロードに影響を与えたり、それらにアクセスしたり、干渉したりすることはできません。
    • ネットワーク上のサービス間の通信を安全かつ確実に行うことができます。
    • 開発者は、アプリケーションの CVE を迅速に可視化できます。
    • 最新状態のセキュアなワークロード ホスティング プラットフォームを実現できます。


セキュアなソフトウェア サプライ チェーンの重要性

ここ数年間、サプライ チェーンへの攻撃が増大するにつれて、ソフトウェア開発への注目度がますます高まっています。最近米国で発令された「国家サイバーセキュリティの向上に関する大統領令」では、組織のサプライ チェーン セキュリティに対するベスト プラクティスが概説されています。その中では、攻撃者が開発プロセスへのアクセスを取得し、ソース コードにマルウェアを埋め込むことに成功したサプライ チェーン侵害について触れられています。このマルウェアはダウンストリームで公開されたソフトウェアに伝播され、攻撃者はそのアプリケーションを実行する組織から情報を盗み取ることができました。この大統領令によって、米国の組織では、よりセキュアなソフトウェア サプライ チェーンを開発し、重要なインフラストラクチャ機能の中断を引き起こし得る侵害を回避しようとする気運が高まっています。

本番環境へのパスに潜む脆弱性を把握し軽減することで、ビジネス投資のリスクを低減できるだけでなく、よりセキュアなソフトウェアを迅速にエンドユーザーに提供する機会を獲得するとともに、開発者がコードをデプロイする過程で生じる摩擦を解消できます。Tanzu は、運用担当者が定義したガードレールを使用してセキュアなツールを作成するためのソリューションを提供し、開発者を支援します。お客様は、Tanzu Labs のエキスパートと協力して組織に適したプロセスを確立し、開発チームとセキュリティ チームのコラボレーションを向上させることができます。VMware は、実績のあるソリューションを使用して DevSecOps の手法を改善し、お客様がセキュアなプラットフォームでアプリケーション開発プロセスを保護して、ビジネスに価値をもたらすアイデアを構築できるよう支援しています。