Skip to main content

サイバーセキュリティに関する大統領令におけるソフトウェアサプライチェーンのセキュリティ要件を理解する

著者:
Daniel Berman

Daniel Berman

wordpress-sync/blog-hero-software-supply-chain-security

2021年6月10日

0 分で読めます

先月発表されたバイデン大統領のサイバーセキュリティに関する大統領令は、過去 1 年間のニュースの見出しを追っていた人ならほとんど驚くようなことではありません。この大統領令は、SolarWinds の攻撃から始まり、最近の Colonial Pipeline に対するランサムウェア攻撃 (米国のエネルギー企業に対する既知の最大の攻撃) に至るまで、一連のインシデントに対する連邦政府の重要な対応策となります。

最近の攻撃の多くがソフトウェアサプライチェーンに関連するものであることを考えると、ソフトウェアセキュリティ、特にソフトウェアサプライチェーンのセキュリティというテーマが大統領令全体で繰り返されていることは驚くにあたりません。今や悪名高い SolarWinds の攻撃は、米国防総省、国務省、国土安全保障省などの政府機関に加え、マイクロソフト、インテル、シスコなどの民間企業に影響を及ぼし、ソフトウェアサプライチェーンセキュリティというテーマが注目を集めました。

ソフトウェアサプライチェーンに対する攻撃は、今に始まったことではありません。Snyk は 2018 年以降、最近のソフトウェア開発と構成がマルウェアの弱点として利用される可能性があることを指摘してきました。それでも、最近のソフトウェアアプリケーションの開発方法に見られる目立った変化をハッカーが利用する事例がさらに増えています。バイデン大統領の大統領令は、こうした変化を認識し、連邦政府にソフトウェアを販売する企業に対して厳しい基準を設けるよう商務省に指示することで、変化がもたらすリスクを最小限に抑えることを目的としたものです。  

ソフトウェアサプライチェーン攻撃とは?

ソフトウェアサプライチェーン攻撃により、ハッカーは複雑なソフトウェア開発サプライチェーンのソフトウェアにアクセスして変更し、悪性コードを挿入してダウンストリームのターゲットに不正にアクセスできるようになります。ソフトウェアサプライチェーンは最終的な攻撃目標ではありません。ハッカーがマルウェアを挿入する足がかりや将来的にアクセスする裏口を設けるために行われます。たとえば、SolarWinds への攻撃では、ハッカーは同社のネットワークやアプリケーションモニタリングプラットフォームの Orion にアクセスし、ソフトウェアの数千ユーザーに悪意のあるアップデートを配布することに成功しました。

ソフトウェアサプライチェーン攻撃は、最近のソフトウェア開発方法を考えると、非常に有効性の高い攻撃ベクトルです。実際のサプライチェーンと同様、ソフトウェアサプライチェーンでも、計画、資材の供給、製造、および小売が連鎖しています。ソフトウェアサプライチェーンでは、資材の代わりにコードが使われます。このコードはプロプライエタリの場合もありますが、ますます多くの部分が供給元、商用またはオープンソースのコードから調達されるようになっています。これらの依存関係は、悪性コードをソフトウェアに挿入するために利用される可能性があります。ソフトウェア開発にはコードが使用されますが、最近のソフトウェアサプライチェーンでは、開発プロセスが増え続けており、各プロセスがマルウェアの効果的な配布に利用される可能性があります。

ソフトウェアサプライチェーンセキュリティに関して米国連邦政府が求める要件

バイデン大統領の大統領令では、連邦政府のサイバーセキュリティの近代化、連邦政府と民間企業間のサイバーセキュリティに関するコミュニケーションと協力関係の改善、連邦政府が購入するソフトウェアのセキュリティ強化などを求めています。ソフトウェアサプライチェーンに対する攻撃でもたらされるリスクについては、大統領令セクション 4 の冒頭に明確に示されています。

商用ソフトウェアの開発は、多くの場合、透明性、攻撃に抵抗するソフトウェア機能に十分な焦点が当てられておらず、および悪意のあるアクターによる改ざんを防止する適切なコントロールがない。製品が安全に、かつ意図したとおりに機能することを保証するために、厳格で予測できる仕組みの導入が急務です。したがって、連邦政府はソフトウェアサプライチェーンのセキュリティと完全性をすばやく改善するための措置を講じる必要があります。

このリスクから政府機関を守るため、NIST は、ソフトウェアサプライヤーが今後、連邦政府にソフトウェアを販売するために準拠するベストプラクティス、ガイドライン、規格を確立するよう要請しています。

ソフトウェア部品表 (SBOM)

ソフトウェアを構成するコードのうち、ゼロから自社開発するコードはごくわずかで、ほとんどの場合はオープンソースやサードパーティのコンポーネントを利用しています。ソフトウェア部品表 (SBOM) についての大統領令の要件は、この事実を認識したもので、ソフトウェアサプライチェーン攻撃のリスクを軽減するために、ソフトウェアに実際には何が含まれているかについて、透明性を高める必要があることを示しています。  

開発環境のセキュリティを確保

ソフトウェアサプライヤーには、開発環境でセキュリティを確保されていることを証明する必要があります。今回の大統領令では、開発環境のセキュリティが確保されていると見なされる基準を NIST が策定することが求められています。これには、セキュリティの確保されたビルドプロセス、データ暗号化、監査、認証、インシデントのモニタリングと管理が含まれます。

開発プロセスのセキュリティ確保

ソフトウェアサプライヤーには安全な開発プラクティスを遵守し、実施した対策を証明できるようにすることも求められます。これにはコードの整合性を保ち、脆弱性を見つけて修正するために、開発の初期段階および開発中にセキュリティテストを自動化して実行することが含まれます。ソフトウェア開発や使用されたツールやプロセスの実行を証明する「アーティファクト」は、必要に応じて入手できます。

オープンソースの整合性

通常、アプリケーションを構成するコードの 80 ~ 90% はオープンソースコードです。このような現実を踏まえ、今回の大統領令ではソフトウェアサプライヤーに対して、「製品の一部で使用されているオープンソースソフトウェアの完全性と来歴を保証し、証明する」ことを求めています。

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

ソフトウェアサプライチェーンを強化して NIST ガイドラインに備えるため、まずアプリケーションのセキュリティを確保します。Snykは、開発者ファーストのクラウドネイティブアプリケーションセキュリティプラットフォームを提供しており、大統領令に記載されている要件の大部分をサポートしています。

開発者をエンパワーする

大統領令で要求されている安全な開発手法の実装が成功するかどうかは、開発者がセキュリティを開発ワークフローに簡単に統合できるかどうかにかかっています。開発におけるセキュリティの確保は、開発者自身のセキュリティの確保から始まります。開発者はアプリケーションの開発方法を決定し、最終的には、コードの完全性、品質、およびセキュリティに責任を負うことになります。開発プロセスの後半に組み込まれる従来型のセキュリティモデルは、直感的でないワークフローによって摩擦が生じるため、ペースの早い開発環境では、もはや選択肢にはなりません。

Snyk が取っているアプローチは、開発者フレンドリーなツールとセキュリティチームの適切なガイダンスを提供して開発者を支援する方法です。Snyk プラットフォームは、開発者が喜んでツール、ツールキットに含まれる他の開発ツールと動作や外観が似ていて、開発スピードも遅くならないツールを提供できるよう設計されています。

SDLC 全体でセキュリティを自動化

ソフトウェア開発プロセスの早い段階でソフトウェアの完全性を確保するため、大統領令は自動化されたセキュリティテストの早期実施を求めています。「...これは定期的に、または少なくとも製品、バージョン、または更新のリリース前に実施するものとする。」Snyk のユーザー企業は、用意されている各種統合および Snyk API を活用し、ソフトウェア開発プロセスのさまざまな段階でセキュリティテストを自動化しています。これは開発者のローカルな開発環境から始まり、Git ベースのワークフロー、ビルドプロセスを経て、本番環境まで続きます。 

最先端のソフトウェアを構成するすべてのコードのセキュリティを確保する

アメリカの大統領令は、アプリケーションを構成するコードが変更されているという事実を認めています。プロプライエタリなコード、オープンソースパッケージ、コンテナ、およびクラウドインフラのプロビジョニングを担うコード (Infrastructure as Code) など、これらは最新のソフトウェアサプライチェーンで使用される素材です。

企業がこの新しいリスクプロファイルを管理し、軽減するためには、包括的なアプリケーションセキュリティのアプローチが求められます。開発チームが作成するコードのセキュリティを確保するため、静的アプリケーションセキュリティテスト (SAST) ツールを重視するセキュリティチームは、オープンソースとコンテナの使用がもたらすリスクを無視しています。ソフトウェア構成分析 (SCA) ツールでは、プロプライエタリなコードがカバーされません。Snyk のプラットフォームは、包括的な開発者ファーストのソリューションを提供し、企業で最新のソフトウェアを構成するすべてのコードのセキュリティを確保するのに役立ちます。

認証とコンポーネントレベルのレポーティング

上記のように、ソフトウェア開発で導入されたプロセスと手段を SBOM の形で提供し、使用されたコードについて連邦政府に透明性を提供することが、大統領令で規定された要件の中で重要な部分を占めています。Snyk は、SBOM やその他の種類のレポートの表示とエクスポートを可能にする広範なレポート機能を提供しています。また、Snyk ユーザーは Snyk API を活用して、サードパーティのレポートおよび脆弱性管理ツールに自動的に統合し、企業のセキュリティとコンプライアンス体制を継続的にモニタリングできます。

今後の展望

この大統領令では、NIST が暫定的なガイドラインを 6 か月以内に公開し、最終的なガイドラインを 1 年以内に公開することを求めています。  この大統領令は、連邦政府に製品を納入する企業を対象としていますが、この基準は民間企業で採用され、ソフトウェア市場全体に影響を及ぼしていくと考えられます。

まずは大統領令を詳しく調べ、既存のソフトウェアサプライチェーンとの主要なギャップを特定することから計画することが賢明と言えるでしょう。

Snyk では、NIST によって導入されたガイドラインの進化を追跡し、ブログで最新情報を発信していく予定です。当社は大統領令を遵守する NIST の取り組み、特に SBOM SIG を使う SBOM 仕様に関する取り組みにも積極的に参加しています。

この大統領令の要件を満たせるよう政府機関を Snyk がどのように支援しているかについて詳しくは、snyk_federal@snyk.io までお問い合わせいただくか、Snyk for Government の Web ページをご覧ください。

wordpress-sync/blog-hero-software-supply-chain-security

CISOがDevSecOps戦略をどのように変革しているか

現在の状況は、500人の開発者に対してセキュリティ専門家は1人という割合です。セキュリティのプロは、開発者がセキュリティ上の判断を下すためのサポートとして、より意識高く、知識を持ち、協力的に業務を遂行する必要があります。