信頼をおくコミュニティー: オープンソースソフトウェアおよびサプライチェーンのセキュリティ

米国をはじめ世界中で、ビジネスや組織はここ数年間に、注目度が高く、重大なセキュリティ攻撃を数多く経験してきました。また実際、そのような攻撃がなくなることはありません。 

Forrester 社の報告書 「アプリケーションセキュリティの現状 2021」によると、外部からの侵害の内、30% はソフトウエアの脆弱性が原因でした。しかし、SolarWinds が示したように、侵害によって社内業務が混乱し、さらには顧客の生活だけでなく、サプライチェーン全体までもが大きく乱されることもあります。 

だからこそ、今、私たちが一丸となってセキュリティ対策に取り組むことが非常に重要なのです。

コミュニティが必要

このような有名なセキュリティ侵害に対応するとともに、ソフトウェアのセキュリティ強化が引き続き必要であるため、ジョーバイデン大統領は2021年5月に大統領令を発布しました。この大統領令は、米国のサイバーセキュリティを向上させることを目的としており、米国企業に大きな影響を与えます。

対象範囲は米国に限定されていますが、世界の他の地域での取り組みに対しても適用されます。相違点は、米国の命令ははるかに具体的で、期限が厳密に設定されている点です。そして、その影響はオープンソースコミュニティ全体に及ぶものと考えられます。

Red Hat などの企業にとっては、大統領令セクション 4 の「Enhanceng Software Supply Chain Security (ソフトウェアサプライチェーンのセキュリティの強化)」に非常に関心があります。 数多くの基準や条件がある中で、私が注目したのは以下の 3 つです。(要点をまとめています)。

1. 自動化されたツールやプロセスを使用して、ソースコードの整合性を維持し、既知の脆弱性や発生する可能性のある脆弱性がないかを確認して、修正していく必要がある。

2. 監査、ソフトウェアおよびコンポーネントの作成元に関するデータを管理して安全なソフトウェア開発手法を利用する。

3. 製品に一部でも使用されているオープンソースソフトウェアの整合性と出所を保証して証明する。

政府はこのような内容を単独で行うことはできないことを認識しています。大統領令では、「民間セクターは、連邦政府と提携し、セキュアなサイバースペースを構築しなければならず、最終的にデジタルインフラストラクチャに寄せる信頼は、そのインフラストラクチャの信頼性と透明性に比例するはずである」とも書かれています。

透明性。パートナーシップ。信頼性。 

この重要な用語は、オープンソースコミュニティやソフトウェア開発に関わるすべての人には馴染み深いものです。

脆弱なソフトウェアサプライチェーン

「ソフトウェアのサプライチェーンは脆弱である。」 これは、Forrester の報告書「Top Security Technology Trends to Watch, 2021」からの抜粋です。

この問題は、オープンソースを支持する者にとっては馴染みにあるものです。以下は、Red Hat のスタッフがこれまでに述べた内容 ではありますが、もう一度言及する価値があります。物理的な形がなく、誰でも貢献できる環境で構築された製品のサプライチェーンのセキュリティをどのように確保すればいいのでしょうか？

オープンソースコミュニティには、匿名や偽名での貢献を好む開発者が世界中から何人も参加しています。コードを作成した人の名前を把握する必要はありませんが、信用する必要はあります。 

これがオープンソースの現実です。全コードの出所を正確に把握することとは相反しており、今後直面するであろう課題の範囲が広がります。 

一度立ち止まって考えてみると、オープンソースコミュニティに存在する人間関係はユニークです。オープンソースコミュニティに貢献する人は、基本的にお互いに依存し合って何かを成し遂げていきます。また、ご存知の通り、このようなコミュニティで作られたソフトウェアには、驚くほど多くのソフトウェアが依存しています。常に互いのコードをプルし合います。このことから、信頼関係の高さが伺えます。

このような信頼関係が、時間をかけて形成される共同作業の精神を生み出し、オープンソースコミュニティの原動力となるのです。例えば、Linuxは、一人の開発者から、文字通りインターネットを動かすソフトウェア管理の分散型コミュニティへと発展しました。最近の例では Kubernetes があります。Kubernetes は、多くのビジネスにとって急速に、インフラストラクチャのコア部分になっています。

Kubernetes と Linux カーネルに共通しているのは、他の多くのプロジェクトと同様に、他の多くのオープンソースソフトウェアに依存していることです。Linux カーネルは、プログラムホストに依存して実行やコンパイルを行います。同様に、Kubernetes は多くの依存関係を取り込み、その依存関係にもは独自の依存関係があります。

なお、これはオープンソースに限ったことではありません。プロプライエタリなソフトウェアを実行する場合には、その背後には依存関係のあるサプライチェーンが存在する可能性がありますが、その中にはオープンソースのものもあれば、そうでないものもあります。その違いは、オープンソースソフトウェアの依存関係はたどることができるのに対し、プロプライエタリなアプリケーションの部品表は透明性に欠けるという点です。

良い知らせと悪い知らせ

まず、良い知らせというのは、「オープンソスソフトウェアの使用量は拡大していく一方である」という点です。監査対象のコードベースのほぼ 99% にオープンソースコードが含まれていることをご存知でしたか？これは、「The State of Application Security 2021」 Forrester 社の報告書によるものです。

また「オープンソスソフトウェアの使用量は拡大していく一方である」というのは、悪い知らせでもあるのです。つまり、このようにオープンソースの使用量が増えることで、悪質な行為をする者だけでなく、新しい脅威も増えてきます。今年の「State of the Software Supply Chain」の報告書によると、2021年には、上流のオープンソースエコシステムの弱点を突くことを目的としたソフトウェアサプライチェーン攻撃が、前年比で 650％ と大幅に増加しました。

結局のところ、この重要なセキュリティ対策は実行可能であり、今後も可能であることです。

なぜ分かるのでしょうか？Red Hat Enterprise Linux (RHEL) を例にとってみてみましょう。オープンソースのサプライチェーンにおけるセキュリティへの懸念が背景にあるにも拘らず、現在 Fortune 500 社の 95% が RHEL を採用しています。RHEL は、環境を超えて一貫したワークロードへの基盤を提供するエンタープライズ Linux オペレーティングシステムで、数百のクラウドおよび数千のベンダーから認定を受けています。これは、成熟した変更管理の結果でもあり、また、米国だけでなく世界中で信頼されています。 

ここで、前述の 3 つのキーワード、「透明性」、「パートナーシップ」、「信頼」に戻ります。これまでも、この 3 つのキーワードを基に、やり遂げ、今後も継続していくつもりです。

ソフトウェアソースの信頼および検証

オープンソースは、誰でも作業内容を確認できるので、ソフトウェアやセキュリティプロトコルをチェックして検証することもできます。

ソフトウェアのサプライチェーンのセキュリティを確保するアイデアの 1 つとして、アプリケーションを構成するアーティファクト (例: ソフトウェアの部品表 (BOM)、コンポーネントのマニフェスト、依存関係のツリーなど) にデジタル署名をするというものがあります。 

Red Hat の CTO オフィスでセキュリティエンジニアリングリードを務める Luke Hind 氏は以下のように述べています。 「デジタル署名は、事実上、ある時点のオブジェクトを「フリーズ」します。つまり、このデジタル署名により、現在の状態にあるこのオブジェクトが記載通りの内容であり、何も変更されていないということが分かります。これは、多くのソースからコードを多数プルして、複雑なワークロードに組み込む開発者にとっては、優れたものです。」

現在のデジタル署名ツールの多くは、その目的に適していますが、多くの場合手間がかかり、面倒であったり、高価であったりします。また、オープンソースの革新的なエンジンのモデルや、DevOps や CI/CD などの自動開発プロセスにも適合しません。

しかし、暗号鍵を誰が所有して、保護するかとう問題もあります。これらの鍵は極めて重要です。たとえば、無数の寄稿者がいるオープンコミュニティでは、全員が秘密鍵を持つことになるのでしょうか？コミュニティのリード (存在する場合) だけが保有すべきでしょうか？または、スポンサーでしょうか？個人の情報が漏洩された場合に、鍵の保有者本人であるか、攻撃者であるか、どのように確認するのでしょうか？

これは、特にオープンソースのソフトウェアサプライチェーンが直面する大きな課題です。 

Red Hat でもともと、試作されたオープンソースプロジェクトは、Red Hat、Google などの支援を受けて、Linux Foundation が主導しています。 

Sigstore は、オープンで透明性が高く、アクセス可能な方法でソフトウェアのサプライチェーンのセキュリティを強化する手法を提供しています。これは、暗号化された署名をより簡単に、誰もが利用できるようにすることを目的としています。そして何よりも、無料で利用できます。

これまでに、このコミュニティには、メンバー 465 名、組織 20 社が参加しており、このコミュニティの今後 を楽しみにしています。

データサイエンティストへの信頼

アプリケーションや基盤のソフトウェアスタックで使用するソースの透明性、パートナーシップおよび信頼性が、「信頼」の全体像ではありません。

信頼できるソースだけから構成されたアプリケーションであっても、新たな脆弱性を引き起こす可能性があり、アプリケーション自体と下層にあるコードの依存関係の両方で、新たな欠陥やセキュリティの問題がないか積極的にチェックする必要があります。DevSecOps のプラクティスや自動化ツールは、上記の内容を管理できるように進化を遂げていますが、さらに上を目指しています。

Red Hat の AI DevSecOps イニシアチブの目的は、ソフトウェア開発とライフサイクル管理のベストプラクティスを AI で自動化して、この負担を軽減することです。CI/CD システムにプラグインする統合機能やボットを使用することで、開発者はソフトウェアスタックを予測可能な方法で定義しやすくなります。また、継続的なメンテナンス (スタックの最適化、新しいバージョンへの更新、テスト、セキュリティ修正) のタスクも自動化します。

このような自動化ツールは、実際の開発者の使用状況や、コミュニティでのやり取り、および経時的に動作を改善する自動テストなどから学習するガイダンスシステムに支えられています。このコンセプトを最初に実現したのが、Project Thoth と呼ばれるオープンソースのサービスです。 

Thoth は、AI を使用して、データサイエンスのユースケースに最初に焦点をあてて、Python アプリケーションのソフトウェアスタックを分析して推奨します。データサイエンティストは、任意のツールに直接ガイダンスを統合する JupyterLab プラグインや、ビルドパイプラインに統合された自動化経由で、Thoth を利用できます。 

こうすることで、データサイエンティストは、基盤となるソフトウェアスタックの複雑性やセキュリティ上の問題に悩まされることなく、本来の仕事であるデータサイエンスに集中できます。

オープンアプローチの価値

プロジェクトのセキュリティおよび脆弱性管理では、「オープンアプローチ」が重要になります。Red Hat で行っている作業はすべてオープンであるため、脆弱性管理についてもオープンな方法論を採用していても驚かれないことでしょう。

実際、弊社では、ソフトウェアのコンポーネント内で発見された脆弱性を管理するためのアプローチを説明したホワイトペーパーを発表したばかりです。本書では、Red Hat がお客様向けに採用したフレームワーク、規格、技術、およびツールを説明します。

オープンなアプローチの一環として、コミュニティおよびお客様とパートナー提携を行います。そして最終的には、オープンソースのセキュリティに取り組むことで、幸運にも協力してくれるすべての人に必要な信頼感を与えることができればと思っています。

透明性。パートナーシップ。信頼性。

これこそが、オープンソースコミュニティが 2021 年に現在の位置に到達するのに役立ったものであり、今後も共に前進していくのに役立ってくものです。