Linux Foundationのコミュニティは、「サイバーセキュリティに関する米国大統領令で要求されるセキュリティ対策」をどのように実現していくのか

本ブログは、How LF communities enable security measures required by the US Executive Order on Cybersecurity (By David A. Wheeler: Director, Open Source Supply Chain Security) の参考訳です。

Linux Foundation (LF) のコミュニティはセキュリティと真摯に向き合っており、すべての組織が最近の米国大統領令に準拠するために必要になるツールと標準の作成に尽力してきました。

概要

「公的部門、民間部門、そして最終的には米国民の安全とプライバシーを脅かす、継続的に発生し、ますます高度化している悪意のあるサイバー攻撃」に対抗するために、最近、米国ホワイトハウスは国家のサイバーセキュリティの改善に関する大統領令 (EO: Executive Order)を発表 (記者会見も実施) しました。

本投稿では、すでにLinux Foundationのコミュニティが構築してきたもので、このEOをサポートするために有効なものを紹介し、あわせて、それを支援するために将来提供を予定しているものについて言及します。 まずは、最初に、状況を説明しましょう。

Linux Foundationのオープンソース セキュリティ イニシアチブの状況

私たちは、サプライチェーン (SC: supply chain) のセキュリティを含め、セキュリティには深い関心を持っています。 Linux Foundationは、LinuxカーネルやKubernetesなど、最も重要で広く使用されているいくつかのOSSの本拠地となっています。LFの活動として以前から行われてきたCore Infrastructure Initiative (CII)、および現在のOpen Source Security Foundation (OpenSSF)は、コンポーネントととして、一般的で、広く使用されているOSSをセキュアにするために取り組んできました。 特にOpenSSFは、「オープンソース エコシステムをセキュアにするために協業する」、幅広い業界の連合体です。

Software Package Data Exchange (SPDX)プロジェクトは、セキュリティの分析に必要なソフトウェアの透過性の実現と、ソフトウェア部品表（SBOM: software bill of materials) データの交換を可能とさせることに、過去10年間取り組んできました。 SPDXは、ISO標準になるための最終レビューの段階にあり、大規模なサプライチェーンを持つグローバル企業によってサポートされており、またオープンソースおよびクローズドソースのツールをサポートする大規模なエコシステムを持っています。 SPDXは、SBOMに対する大統領令 (EO) の要件をすでに満たしています。

今では、LF内のいくつかのサブ組織が、さまざまなバーティカル市場のセキュリティに焦点を当てて活動しています。 たとえば、LF Public HealthとLF Energyは、それぞれのセクターでセキュリティに取り組んできました。 またCNCFで協業しているクラウド コンピューティング業界は、クラウド システムとアプリケーションのためにソフトウェア サプライチェーンのベストプラクティスをサポートするためのガイドも作成しました。

そのような状況を踏まえて、いくつかのEOステートメント(記述順序に従って)と、これらの課題に対処するために、何年にもわたり、LFコミュニティがオープンコラボレーションにどのように投資をしてきたかについて見てみましょう。

ベストプラクティス

EO 4(b)および4(c)は次のように述べています*。

「商務長官 (NISTを介してその責務を果たす) は、連邦政府、民間部門、学界、およびその他の適切な関係者からの意見を求めて、いろいろな標準、手順、または基準に準拠するために必要な、既存の標準、ツール、およびベストプラクティスを洗い出し、必要なら新しく開発する。そのガイドラインにおいては、ソフトウェアのセキュリティを評価するために使用できる基準と、開発者とサプライヤー自身のセキュリティ プラクティスを評価するための基準を含み、ソフトウェア サプライチェーンのセキュリティを強化するためのセキュアなプラクティスへの準拠を実証する革新的なツール、または方法を洗い出す。」 EO 4(e)(ix)では、「セキュアなソフトウェア開発プラクティスへの適合性の証明」について説明しています。

* EO 原文：
(b) Within 30 days of the date of this order, the Secretary of Commerce acting through the Director of NIST shall solicit input from the Federal Government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria in subsection (e) of this section. The guidelines shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.
(c) Within 180 days of the date of this order, the Director of NIST shall publish preliminary guidelines, based on the consultations described in subsection (b) of this section and drawing on existing documents as practicable, for enhancing software supply chain security and meeting the requirements of this section.

OpenSSFのCIIベストプラクティス バッジ プロジェクトは、セキュリティに焦点を当て、開発者とサプライヤのセキュリティ プラクティスを評価するための基準を含めて、OSSのベストプラクティスを具体的に提示しています (3,800を超えるプロジェクトが参加しています)。 またLFは、サプライチェーンの問題にさらにフォーカスしたガイダンス (現在開発中) を、SLSA (Supply-chain Levels for Software Artifacts)と連携して追加する予定です。

ベストプラクティスは、開発者がそれらを理解している場合にのみ役立ちますが、ほとんどのソフトウェア開発者は、セキュアなソフトウェアの開発に関する教育やトレーニングを受けたことがありません。 LFは、edX上に、誰でも無料で利用できるSecure Software Development Fundamentalsのコースのセットを開発し、リリースしました。 OpenSSF Best Practices Working Group (WG)は、ベストプラクティスの特定と公表に積極的に取り組んでいます。 また、以下で説明するように、LFは多くの具体的な標準、ツール、およびベストプラクティスも提供しています。

暗号化とデータの機密性

EO 3(d)は、各政府機関が「保存データ、および移送中のデータの暗号化」を採用すること求めています。 移送中の暗号化は、TLS (“https://”) プロトコルを使用してWeb上で実施されます。Let’s EncryptはTLS証明書のための世界最大の認証局です。

さらに、LF Confidential Computing Consortiumは、コンフィデンシャル コンピューティングの定義と採用を加速させるために尽力しています。 コンフィデンシャル コンピューティングは、ハードウェア ベースのTrusted Execution Environmentで計算を実行することにより、使用中のデータ (保存データおよび移送中だけでなく) を保護します。 これらの安全で隔離された環境は、使用中のアプリケーションやデータへの不正アクセス、改変を防ぎます

サプライチェーン インテグリティ

EO 4(e)(iii)は以下の要件を求めています。

「自動化されたツール、または同等のプロセスを採用して、信頼できるソースコードのサプライチェーンを維持し、それによってコードのインテグリティを確保すること。」

LFには、特にサプライチェーンのインテグリティをサポートする多くのプロジェクトがあります。

• in-totoは、ソフトウェア サプライチェーンのインテグリティを確保するために特別に設計されたフレームワーク。

• The Update Framework (TUF)は、開発者がソフトウェア アップデート システムのセキュリティを維持するのに役立ち、さまざまなテクノロジー企業やオープンソース組織によって本番環境で使用されている。

• UptaneはTUFから派生したもの。 これは、コンピューター化された車載ユニットに無線で配信されるソフトウェアを保護するオープンでセキュアなソフトウェア更新システムとして設計されている。

• sigstoreは、透明性ログ技術 (改ざん防止機能を備えた公開ログ) に裏打ちされた暗号化ソフトウェア署名 (リリース ファイルやコンテナ イメージなどに対して) を容易に採用させることにより、オープンソース ソフトウェアのサプライチェーンを改善させる公益的な非営利サービスを提供するプロジェクト。

• LFは、署名を容易にし、発信元を確認するツールに注力しているプロジェクトにも資金を提供している。たとえば、gitを拡張して署名のプラグインを可能にさせる検討を行っている。また、patattツールを使用すると、電子メールで送信されたパッチに対してエンドツーエンドの暗号化認証を簡単に提供できる。

• OpenChain (ISO 5230) は、オープンソースライセンスコンプライアンスに関する国際規格。 OpenChainを適用するには、OSSコンポーネントを識別する必要がある。 OpenChain自体はライセンスに重点を置いているが、そのように識別された情報は、当該コンポーネントの他の側面を分析するために(たとえば、既知の脆弱性を探すために)簡単に再利用できる。

ソフトウェア部品表 (SBOM) は、サプライチェーンのインテグリティをサポートします。 SBOMは非常に広範囲な役割を持っており、以下に説明します。

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

多くのサイバーリスクは、既知の脆弱性を持つコンポーネントを使用していることで発生します。 既知の脆弱性は、国家レベルの燃料パイプライン、通信ネットワーク、電気・ガス・水道などの公益事業、送電網などに関連した重要なインフラストラクチャ業界で特に懸念されています。 これらの脆弱性の悪用は、供給ラインとサービスの中断につながる可能性があり、場合によっては、サイバー攻撃による人命の損失につながることもあります。

これらの脆弱性は通常、コンポーネントが開発完了し、組み込まれた後に発見されるため、1回限りのレビューは役に立ちません。 代わりに必要なのは、これらの重要なインフラストラクチャ システムを稼働させるために開発され、ソフトウェア環境に組み込まれているコンポーネントを可視化することです。これは、食品の成分を可視化する方法と似ています。

ソフトウェア部品表(SBOM)は、デバイス、またはシステムの作成に使用されるソフトウェアコンポーネントを構成する入れ子構造のインベントリまたは構成要素のリストです。 これは、政府機関内や主要産業で使用される国家レベルのデジタル インフラストラクチャに関連しているために特に重要です。これらのインフラストラクチャは、侵入された場合に国家安全保障上のリスクをもたらします。 SBOMを使用すると、サプライチェーンで提供されるソフトウェア コンポーネントに対する運用リスクとサイバー リスクに対する理解が深まるでしょう。

EOには、ソフトウェアの部品表(SBOM)とSBOMを元にした作業の必要性に言及する文章が広範囲に記載されています。

• EO 4(e)では、購入者にSBOMを「製品で直接、またはWebサイトで公開することによって」提供し、「製品で使用されているオープンソース ソフトウェアのインテグリティと出所を保証および証明する」ことを要求。
• また、EO 4(e)は、典型的にSBOMが必要となる作業を要求している。たとえば、「自動化されたツール、または同等のプロセスを使用して、既知、および潜在的な脆弱性をチェックし、それらを修正すること。これらを定期的に行うこと…」。 また、「ソフトウェア開発プロセスに存在する内製、およびサードパーティのソフトウェア コンポーネント、ツール、およびサービスに対して、データ、ソフトウェア コードやコンポーネントの出所(つまり、起源)、および管理情報を継続して正確、かつ最新なものとなるように維持し、その管理状況を定期的に監査し、実施状況を確認すること。」
• EO 4(f)では「SBOMの最小限の要素」の公開を要求しており、EO 10(j)ではSBOMを「ソフトウェア構築に使用されるさまざまなコンポーネントの詳細とサプライチェーンの関係を含む正式な記録…」、「 SBOMは、製品を組み立てているコンポーネントを列挙する…食品包装上に示される成分リストと似たもの。」と公式に定義している。

LFは、10年以上にわたってSPDXの開発と改良を行ってきました。 SPDXは世界中で使用されており、ISO/IEC Draft International Standard (DIS) 5962として承認される過程にあります。SPDXは、より大規模なコンピューターソフトウェア内のソフトウェアコンポーネントと、それらのコンポーネントのライセンスなどのメタデータを識別するファイル形式です。 SPDX 2.2は、「SBOMの最小限の要素」に対するNational Telecommunications and Information Administration (NTIA) の現在のガイダンスをすでにサポートしています。 一部のエコシステムにはSBOMに含む情報に関して、エコシステム独自の規約を定めていますが、SPDXはどんなエコシステムに対しても情報を提供することができます。

SPDXは現在、実際に以下のように使用されており、将来的にはさらに採用が増えていくと予想されます。

• NTIAの「plugfest」では、SPDXを生成する異なる10種類のSPDXプロデューサーがデモを実施しました。 SPDXは、さまざまなソースからのデータの取得をサポート (たとえば、ソースコード分析、実行可能形式ファイル、サードパーティ ソフトウェアの分析など)。
• SPDXで作成されたSBOMを格納しているLFプロジェクト ソフトウェアのデータベースが利用できる。
• yoctoやZephyrなど、さまざまなLFプロジェクトがビルドの一部としてバイナリ形式のSBOMを生成するために取り組んでいる。
• SPDXのさらなる採用を促進するために、LFは主要なパッケージ マネージャー用のSPDXプラグインの作成を支援している。

脆弱性の開示

不可避的にいくつかの脆弱性は後で発見され、修正される必要があります。 EO 4(e)(viii)は、「報告、および開示プロセスを含む脆弱性開示プログラムへの参加」を要求しています。 そうすることで、見つかった脆弱性はそれを修正できる組織に通知できます。

CIIベストプラクティス バッジ合格基準では、OSSプロジェクトは脆弱性を報告する方法を明確に提示する必要があります。 OpenSSF Vulnerability Disclosures Working Groupは、OSSにおける、「適切に管理された脆弱性の報告とコミュニケーションを成熟させ、支持する」ためにより広範囲に取り組んでいます。 最も広く使用されているLinuxディストリビューションには、堅牢なセキュリティ対応チームがありますが、Alpine Linuxディストリビューション (コンテナベースのシステムで広く使用されている) にはありませんでした。 Linux FoundationとGoogleは、セキュリティ対応チームを含めて、Alpine Linuxがさまざまな改善を行うための資金を提供しました。

LFは、連邦政府がVulnerabilities Equities Process (VEP)を刷新して、OSSプロジェクトを含む商業組織とより協調して作業し、より多くの脆弱性情報を共有することができるようになることを期待しています。 米国が開示することができなかったすべての脆弱性は、攻撃者によって発見、悪用される可能性があるからです。 LFはこのような議論が今後なされることを期待しています。

クリティカル ソフトウェア

クリティカルソフトウェアに焦点を当てることは非常に重要です。しかし、クリティカルソフトウェアとは何なのでしょうか？ EO 4(g)には、行政府が「クリティカルソフトウェア」を定義することを要求しており、4(h)では、行政府が「クリティカルソフトウェアの定義を満たすソフトウェア、およびソフトウェア製品のカテゴリのリストを定めて、政府機関がそれを利用できるようにすること」を求めています。

Linux FoundationとLaboratory for Innovation Science at Harvard (LISH)は、「Vulnerabilities in the Core: Preliminary Report and Census II of Open Source Software」を作成しました。 現在、LFとLISHは、そのレポートを改訂中です。 CIIは、OpenSSL (Heartbleed発生後)、OpenSSH、GnuPG、Frama-C、OWASP Zed Attack Proxy (ZAP)など、多くの重要なプロジェクトを特定し、支援してきました。 OpenSSF Securing Critical Projects Working Groupは、クリティカルなOSSプロジェクトをより適切に選定し、支援が必要なクリティカルなOSSプロジェクトにリソースを集中させてきました。そのようなプロジェクトの最初のリストも既に作成しており、プロジェクトに対する資金援助も始めています。

Internet of Things (IoT)

残念ながら、インターネット (IoT) 関連機器のセキュリティは問題が多いことが良く知られています。 IOTにセキュリティが欠けているという、有名なジョーク、「the S in IoT stands for security.」（「IOTの中のSはSecurityのS」だが、実際にはSはない。）があります。

EO 4(s)は、「IoT関連機器のセキュリティ機能とソフトウェア開発手法について(既存の消費者製品ラベリングプログラムに基づいて)一般の人々に教育するパイロットプログラムを開始し、これらのプログラムに参加する開発者や製造業者にインセンティブを与える方法を検討すること。」 EO 4(t)は、そのような「IoTサイバーセキュリティ基準」は、「より広範囲に広がるテストと評価のレベルを反映させていくこと。」と述べています。

Linux Foundationは、IoTシステムの主要コンポーネントの多くを開発しており、その本拠地にもなっています。 これらには以下が含まれます。

• 多数のIoT関連機器で使用されているLinuxカーネル。
• IoT、および組み込みシステム向けのカスタマイズされたLinuxベースのシステムを作成するyoctoプロジェクト。 yoctoは完全に再現可能なビルドをサポートしている。
• EdgeX Foundryは、IoT エッジのデバイスとアプリケーションの相互運用性を促進する柔軟なOSSフレームワークであり、何百万回もダウンロードされている。
• Zephyrプロジェクトは、リソースに制約のあるIoT機器の多くで使用されているリアルタイム オペレーティング システム (RTOS)を提供しており、そのビルド中にSBOMも自動的に生成する。 Zephyrは、CVE (Common Vulnerabilities and Exposures) Numbering Authority (CVE採番機関) として認められている数少ないオープンソースプロジェクトの1つ。
• seL4マイクロカーネルは世界で最も高度に保証されたオペレーティング システム カーネル。 包括的な証明 (フォーマル検証) が実施されていることで知られている。

セキュリティラベリング

EO 4(u)は、以下を明確にしていくことに焦点を置いています。

「セキュアなソフトウェア開発手法または消費者向けソフトウェアに対するラベリングプログラムの基準を洗い出し、その基準は、セキュアな手法のベースラインレベルを反映したもので、可能ならば、製品が受けてきた可能性のある広範囲なテストと評価のレベルを反映させる。また、推奨ラベルを特定、変更、あるいは開発し、可能なら、ランク化されたソフトウェアのセキュリティレイティングシステムを作成すること。」

OpenSSFのCII Best Practicesバッジプロジェクト(前述)は、OSS開発のベストプラクティスを具体的に特定し、すでにランク化(合格、シルバー、ゴールド)しています。 現在、3,800を超えるプロジェクトが参加しています。

セキュリティやより広範囲な品質の評価に関連したプロジェクトもいくつかあります。

• Community Health Analytics Open Source Software (CHAOSS)は、コミュニティの健全性を明らかにし、リスクを特定するための分析方法と基準を作成することに焦点を置いて活動しる。
• OpenSSF Security Metrics Projectは、まだ、開発途上ながら、オープンソースプロジェクトのセキュリティ関連データを収集し、集約し、分析し、それを伝達するために作られたプロジェクトです。
• OpenSSF Security Reviews Initiativeは、オープンソースソフトウェアに対するセキュリティレビューの結果を収集し、それらをまとめて提供。
• OpenSSF Security Scorecardsは、任意のOSSに対して迅速なレビューを行い、合格・不合格判定ができるように、一連の自動化された手順を提供。

結論

Linux Foundation (LF)は、世界中のシステムで使用されているオープンソースソフトウェア(OSS)のセキュリティの向上に長年取り組んできました。 多くの企業や個人からの時間、資金、その他のリソースの面で、数多くのコントリビューションを受けてきており、これらがなければ、推進していくことはできませんでした。 皆様に感謝致します。 私たちは常に、オープンソースソフトウェアの開発とデプロイメントを改善するために皆様と協力していくことを常に嬉しく思っています。これは私たち全員にとって重要なことです。

David A. Wheeler, Director of Open Source Supply Chain Security at the Linux Foundation