fbpx

米国大統領令14028に基づくソフトウェアサプライチェーンコンプライアンスの実現 #aqua #セキュリティ #ソフトウェアサプライチェーン

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

New call-to-action

本ブログは「Aqua Security」社の技術ブログで2022年12月6日に公開された「 Achieve Software Supply Chain Compliance with US Executive Order 14028 」の日本語翻訳です。

米国大統領令14028に基づくソフトウェアサプライチェーンコンプライアンスの実現


クラウドインフラの台頭、豊富なビルド済みのオープンソースコード、DevOps のプロセス改善など、多くの要因のおかげで、ソフトウェアによるイノベーションはかつてないほど速く実現しています。

ソフトウェアサプライチェーンは、こうした技術革新の組立ラインであり、ソフトウェアを開発して顧客へ提供するために使用されるコード、ツール、プロセスのあらゆる組み合わせとして考えることができます。社会は、それぞれのデジタル技術をまとめるバックボーンとして、ソフトウェアサプライチェーンに依存しています。このようなソフトウェアサプライチェーンへの依存度は高まっており、当然のことながら、攻撃対象としての魅力も高まっています。外国政府やハッカー集団は、ソフトウェアのサプライチェーンは保護が不十分で、SolarWinds 社や Codecov 社のような攻撃に遭う多くの機会に満ちていると考えています。これらの侵害の深刻さ、被害者の数、および、取得されたアクセスやデータの種類は壊滅的なものでした。

米国政府が国家のサイバーセキュリティを改善する大統領令を制定

ソフトウェアサプライチェーンに対するこうした戦略的な攻撃と、それが政府の重要なデータやシステムのセキュリティへもたらす脅威に対応するため、米国では新たなコンプライアンス要件が設けられました。2022年9月14日に制定された大統領令14028は、ソフトウェアの侵害を防ぎ、国家のソフトウェアサプライチェーンを強固にするため、組織が遵守すべき最低限の基準や行動を要求し定義しています。米国政府機関にソフトウェア、ソフトウェアを含む製品、アプリケーション、OS、ファームウェアを販売する組織は、このガイダンスに準拠する必要があります。

ソフトウェアサプライチェーンセキュリティのベストプラクティスガイドは、これまでに4件公開されています。しかし、コンプライアンスを正確に証明するために従うべき公式のガイダンスは、NIST(米国国立標準技術研究所)が作成した「The Secure Software Development Framework NIST 800-218」です。

Secure Software Development Framework では、ソフトウェア開発者は使用するソフトウェアデリバリーライフサイクルモデル(アジャイル、ウォーターフォール、DevOps など)にかかわらず、プロセスにセキュリティを戦略的に組み込み、運用成熟度に見合った方法でのセキュリティ適用を求めています。

NIST のフレームワークへの準拠を達成するために必要な具体的なコンプライアンス要件は42項目あります。これらの要件は、4つのカテゴリのいずれかに分類され、ハイレベルなソフトウェアサプライチェーンセキュリティの目標に対応させることができます。

  1. 組織を準備する:プロセス、技術が安全なソフトウェア開発するために十分であることを確認し、コードを保護する
  2. ソフトウェアを保護する:ソフトウェアのすべてのコンポーネントを、改ざんや不正アクセスから保護する。
  3. 安全性の高いソフトウェアを作成する:セキュリティの脆弱性を最小限に抑え、安全性の高いソフトウェアを作成する。
  4. 脆弱性への対応:ソフトウェアに存在する脆弱性を特定し、類似の脆弱性が発生しないように修正する。

このフレームワークを採用することで、ソフトウェアで公開される脆弱性の数を減らし、ソフトウェアのサプライチェーンが悪用された場合の影響を軽減し、脆弱性の原因を解決できます。また、組織がソフトウェアの生産者と利用者の両方として、2つの異なる視点からセキュリティの包括的なアプローチに取り組みます。

あらゆる人が影響を受ける

ソフトウェアを販売または利用するすべての組織は、サプライチェーンに含まれます。したがって、大統領令はドミノ効果をもたらします。これを拡大解釈すると、政府と直接契約していない企業もあり、サプライヤーとして準拠する必要はありません。しかし、その顧客は、NIST のガイダンスにも準拠しているソフトウェアコンポーネントやオープンソース群を使用できるようになりました。

コンプライアンス遵守のためのタイムライン

時間を無駄にできません。大統領令で定められた期限はすぐそこまできています。

  • 2023年1月12日までに、政府機関に提供するソフトウェアの担当 CIO は、利用するすべてのソフトウェアベンダーにコンプライアンス要件を通知する必要があります。
  • 2023年6月11日までに、米国政府にとって「重要」とみなされるソフトウェアは、完全なコンプライアンスと認証が必要です。
  • 2023年9月14日までに、米国政府機関またはベンダーに供給されるその他のすべてのソフトウェアは、コンプライアンスと認証を取得する必要があります。

グローバルな影響

この大統領令は米国政府のみに適用されるものですが、他の国々がこれに続くことを期待する先行指標となるものです。NIST が作成したガイドラインは、ソフトウェアサプライチェーン戦略が国家安全保障にますます影響を与えるようになる中で、組織がどのような種類のセキュリティ標準を遵守できるかを垣間見ることができます。

大統領令14208の遵守を達成するために


幸いなことに、大統領令への準拠は、ソフトウェアサプライチェーンセキュリティの実践を採用することの大きな利点の1つとなるでしょう。この4つの包括的なステップは、大統領令を準拠するために必要なすべてのソフトウェア開発と認証のコンポーネントを効率的に組み込み、安全な開発と準拠を「一石二鳥」的な手法に転化しています。

  1. 安全な開発環境とプロセス:開発環境の安全な構成を確保し、付随する認証を完了させる。

    何をどこにセキュリティ適用すればよいかを知ることは、出発点として非常に重要です。そのためには、組織のソフトウェア開発インフラを可視化し、ソフトウェアを安心してリリースするために必要なプロセスやツールをどこに導入すればよいかを把握する必要があります。開発環境を保護するには、誰がコードリポジトリ、CI パイプライン、または、アーティファクトレジストリにアクセスできるかを制御し、SDLC 全体にわたって最小特権アクセスのマントラを活用することが必要です。開発環境に使用されるツールのセキュリティもまた、重要な要素です。これは、ビルドごとに脆弱性とライセンスの問題をスキャンすることで実現され、悪意のあるアドオンが悪用されることを防ぎます。

    Aqua のような包括的なソフトウェアサプライチェーンセキュリティソリューションは、人、ツール、プロセスを結び付け、これらのセキュリティベストプラクティスを開発フローの直感的な部分とし、自動化を活用してスピードとレポーティングを実現するものです。

  2. コードの安全性:コードのソースが信頼できること、コードの脆弱性が修正されていることを確認し、付随する証明書を完成させる。

    ソースコードが安全で信頼できるものであることの確認は、脆弱性、シークレット情報、マルウェアなどを検出するコードスキャナーを活用することで一般的に行われます。このスキャナーは、開発プロセスの早い段階で脆弱性を特定するのに役立ちます。これは一般に、開発者がまだコードを書いている段階でセキュリティのシフトレフトを実践することとして知られており、最も簡単かつ安価に修正できます。最高のコードスキャナーは、脆弱性の発見、開発者の IDE や CI/CD にプラグイン可能、バイナリに対して実行可能、低い誤検知を実現し、様々な対応すべき問題を検出します。

    大統領令を遵守するためには、既知のコードの脆弱性を是正する必要があります。この作業は、重大性に応じて優先順位をつける必要があります。ソースコードが検証され既知の脆弱性が一掃されると、組織はソフトウェアサプライチェーンポスチャ管理において、コンプライアンスを維持しながら積極的に行動する準備が整うことになります。このプロセスでも、ポリシーの自動化とインテリジェントな通知機能がこれらのベストプラクティスをすべて取り入れながら、開発者のペースを落とさないために役立っています。

  3. ソフトウェア部品表(SBOM):内部およびサードパーティのコードの出所データを管理し、製品リリースごとに最新の SBOM を把握する。

    ソフトウェア部品表(SBOM)は、ソフトウェアに含まれ、コンプライアンスへ適合するために必要なコンポーネントのリストを提供するものです。また、サードパーティサプライヤーに対して、その製品の品質とセキュリティに対する責任を負わせるものです。最も重要なことは、プロプライエタリおよびオープンソースの依存関係ツリーを明らかにし、CVE への必然的な対応を積極的な作業とすることです。

    新たな脆弱性やソフトウェアサプライチェーン攻撃が発見された場合、チームは、開発・使用されるすべてのソフトウェアのあらゆるコンポーネントを検証して、リスクの露呈を判断しなければなりません。例えば、重要なアプリケーションに、新たに侵害されたオープンソースライブラリが含まれているかどうかを検証する場合などです。スピードと対応は、影響を受けるアーティファクトをいかに早く発見し、ピンポイントで修正できるかに左右されます。

  4. オープンソースの健全性:使用中のすべてのオープンソースソフトウェアのデータの完全性と出所を維持する。

    NIST のガイダンスでは、オープンソースのコードが多く取り上げられていますが、これは、オープンソースに現れる脆弱性を特定、追跡、是正することが困難であるためです。オープンソースは、現代のソフトウェアソリューションの実に70~90%を占めており、ソフトウェアの完全性を確保する上で最も厄介なものの1つとなっています。オープンソースの利用が拡大していることを考えると、セキュリティ戦略上、オープンソースは重要な要素です。

    ソフトウェアの品質は、オープンソースプロジェクトの健全性、その開発者、その他の重要な指標に依存します。完全性を維持するには、すべてのオープンソースを SCA(ソフトウェア構成分析)でスキャンし、既知の脆弱性を持つ悪いコンポーネントがコードに導入されないように自動化を設定し、常に新しい脆弱性を監視する必要があります。

Aqua のソフトウェアサプライチェーンセキュリティソリューションは、ソフトウェア開発ライフサイクル全体のエンドツーエンドのセキュリティと整合性を確保するために構築されました。ソフトウェアプロバイダーは、導入後30日以内にソフトウェア開発コンポーネントの安全性に関する大統領令の要件を迅速に満たし、証明できます。また、継続的なコンプライアンス証明のためのレポートと管理機能が含まれています。

New call-to-action

New call-to-action

新規CTA