ホワイトハウス OSS セキュリティ・サミット:各ベンダーの声明を集めてみた

U.S. Government, Tech Giants Discuss Open Source Software Security

2022/01/14 SecurityWeek — 2020年1月13日にホワイトハウス・サミットが開催され、米国の政府と大手ハイテク企業の代表者がオープンソース・ソフトウェアのセキュリティについて話し合った。広く利用されている Log4j ロギング・ユーティリティーに影響を与える脆弱性が、公開/悪用されたことで、オープンソースとソフトウェア・サプライチェーンのセキュリティの重要性が、あらためて浮き彫りになっている。ホワイトハウス・サミットの目的は、オープンソース・ソフトウェアのセキュリティを向上させ、オープンソース・コミュニティを効果的にサポートする方法を特定することだった。


議論の中心になったのは、1:オープンソースのコードやパッケージの脆弱性を防ぐこと、2:欠陥を発見して修正するプロセスを改善すること、3:パッチを配布して実装する際のレスポンスを改善することである。

ホワイトハウスはサミットの開催を受けて、1つ目のカテゴリーでは、開発ツールにセキュリティ機能を組み込むことで、開発者が安全なコードを書きやすくするアイデアや、コード署名およびデジタル ID の強化などの、コードの構築/保管/配布に用いる、インフラの安全性を確保するアイデアが議論された。

2つ目のカテゴリーでは、最も重要なオープンソース・プロジェクトに優先順位が付けられ、それらを維持するためのメカニズムの導入方法について議論された。3つ目のカテゴリーでは、大統領令が求めているソフトウェア部品表 (SBoM : Bill of Material) の促進/改善および、購入/使用するソフトウェアに含まれる、より小さなソフトウェアを簡単に知ることができるようにする、方法について議論された。

参加者には、バイデン政権/国防総省/商務省/エネルギー省/国土安全保障省/CISA/国立標準技術研究所/国立科学財団の代表者が含まれていた。民間企業からは、Akamai/Amazon/Apache Software Foundation/Apple/Cloudflare/Facebook (Meta)/GitHub/Google/IBM/The Linux Foundation/Open Source Security Foundation/Microsoft/Oracle/RedHat/VMware が参加した。

ホワイトハウス・サミット後の声明

会議に参加した技術系企業や組織のいくつかは、木曜日に会議後も声明を発表した。SecurityWeek では、声明の中から、いくつかのポイントを抜粋している。

Akamai

Akamai は、各業界のリーダーである顧客との継続的なパートナーシップと、ホワイトハウス/国家安全保障会議/広範なテクノロジー・コミュニティとの協力を通じて、以下の 5 つの柱を提唱している。

  • オープンソース技術への依存度の可視化
  • 主要なオープンソース・ライブラリを特定し、強力なオーナーシップと脆弱性管理をサポートする
  • 悪用が確認された場合の確実な封じ込め計画の構築
  • 脆弱性が最初に発見された際の、政府や業界を超えた情報共有の改善
  • 防御力を高めるために、政府によるソリューションの認可を拡大する

Apache Software Foundation

これからは、オープンソース・ソフトウェアを利用している企業や組織が、上流から協力していく必要があると考える。そのためには、オープンソースのサプライチェーンを改善するために、すべての組織が協力しなければならない。

ASF を知っている人は、ASF がコミュニティを大切にし、コントリビュータに公平な競争の場を提供していることを知っているだろう。今日の話し合いは、オープンソース・ソフトウェアの現状のセキュリティ・ニーズに対応するための、より広範な対応のきっかけとなり、方向性を示す良いきっかけになると信じている。

今日のサミットに参加した多くの組織は、オープンソースの重要な貢献者や消費者だが、もちろん全てを代表しているわけではない。私たちは、個々のコントリビュータだけでなく、企業/財団/政府機関からの意見を聞くことが、重要であること認識している。我々としても、それが実現するよう努力していきたいと思う。

GitHub

SolarWinds と Log4j のインシデントは、重要なコードを保護することの重要性を思い出させてくれた。たった1行/2行の脆弱なコードが、瞬く間にシステム全体の健全性/安全性/信頼性に劇的な影響を与えることを、私たちは目の当たりにしてきた。

Heartbleed に見られたように、この問題は今に始まったことではないが、最近の出来事は、技術業界が一丸となって支援するための、2つの方法を明確にしている。まず、ソフトウェアのサプライチェーンの安全性を確保するために、業界とコミュニティが一丸となって取り組む必要がある。2つ目は、オープンソースのメンテナが、自分のプロジェクトのセキュリティを確保しやすくするための、サポートを強化することだ。

Google

オープンソース・ソフトウェアのコードは一般に公開されており、誰もが自由に使用/変更/検査できる。オープンソースは自由に利用できるため、共同でイノベーションを起こすことや、共通の問題を解決するための新技術を開発するを可能にする。そのため、重要インフラや国家安全保障システムの多くの部分に、オープンソースが採用されている。

しかし、その重要なコードのセキュリティを維持するための、公式なリソース配分や、正式な要件/基準が定まっているとは言えない。実際のところ、既知の脆弱性の修正を含め、オープンソースのセキュリティを維持/強化するための作業の大半が、その場限りのボランティア・ベースで行われている。

あまりにも長い間、ソフトウェア・コミュニティは、オープンソース・ソフトウェアの透明性がセキュリティを約束し、多くの人々が問題の検出/解決を見守っているという前提で安心していた。しかし、実際には、多くの人が見ているプロジェクトもあれば、ほとんど、あるいはまったく見ていないプロジェクトもある。

今日の会議では、以下を提案した。

  • 重要プロジェクトの特定
  • セキュリティ/メンテナンス/テストのためのベースラインの確立
  • 官民一体となったサポートの強化

Open Source Security Foundation

本日の会議では、ソフトウェアのサプライチェーンのセキュリティを、保護/向上させるために必要な重要な取り組みに対して、全員が十分にコミットすることで、大きな影響を与えることができる重要な機会を共有した。オープンソースのエコシステムは、重要なオープンソース・ソ・プロジェクトで発見された欠陥の修復を促進するために、サイバー・セキュリティに関する研究/トレーニング/分析などで協力する必要がある。

これらの計画には好意的な意見が寄せられ、有意義な行動をとるための、共同コミットメントへの期待が高まっている。最近の log4j 問題を受けて、オープンソース・ソフトウェア・コンポーネントと、それらが流通していくソフトウェア・サプライチェーンが、最高のサイバー・セキュリティを発揮することを保証するために、官民が協力することが、これまで以上に求められている。

ベストプラクティス/重要プロジェクトの特定/メトリクスとスコアカード/プロジェクト・シグストアなどのワーキング・グループを通じ、本日の会議で議論された主要分野の多くに、OpenSSF は影響を与えてきた。我々は、これらの取り組みをさらに進める準備ができており、新しい参加者やリソースを歓迎する。

Red Hat

Red Hat は、2021年5月の「サイバーセキュリティに関する大統領令」で具現化された、ソフトウェア・サプライチェーン・セキュリティに対する、政権の包括的なアプローチを称賛する。その実施と、その目的である、公開性と透明性に対して継続して熱心に取り組むことが不可欠だ。

サイバー EO の基本方針は、プロプライエタリとオープンソースを問わず、すべてのソフトウェアのセキュリティ態勢を改善するための基本であり、あらゆる種類のベンダーが自社ソフトウェアの可視性を高め、そのライフサイクルに責任を持ち、セキュリティ・データの公開を保証することも含まれている。

さいごに

今回の会議では、オープンソース・ソフトウェアが技術革新のスピードを速め、社会的/経済的に多大な利益をもたらしており、信頼性とサイバー・セキュリティの向上に大きく貢献できるという認識が、重要なテーマとなった。産業用サイバーセキュリティ企業である Claroty は、今回の会議に先立ち、運用技術 (OT) と重要インフラのリスクを明確にするブログ記事 Open Source Use In Critical Infrastructure Under Scrutiny を発表している。

1月14日に「ホワイトハウスの念押し:ハイテク大手のオープンソースが国家安全保障の問題」をポストし、このjホワイトハウス OSS セキュリティ・サミットについて紹介しましたが、今回の記事は、それを受けて表明された各ベンダーのコメントをマトメたものです。各社とも、問題意識を共有しており、根本からの解決には連携が必要であり、それによりソフトウェア・サプライチェーンの問題が解決されると考えています。Apache Log4j の問題も、セキュリティの問題というより、いまのソフトウェアのあり方の問題のように思えます。この勢いで、連携が進むと良いですね。

%d bloggers like this: