Secure Software Summit:OSS サプライチェーン・セキュリティの現状について

Secure Software Summit: The State of OSS Supply Chain Security

2022/03/17 SecurityBoulevard — Open Source Software (OSS) サプライチェーンが、サイバー攻撃にさらされている。最近の Log4Shell 脆弱性に見られるように、OSS のサプライチェーンは、セキュリティの弱点を突こうとする、攻撃者の焦点となりつつある。数多くの調査レポートにおいて、いわゆる次世代ソフトウェア・サプライチェーン攻撃の、過去 10年間での大幅な増加が示されている。これらの攻撃は、ソースコード/ビルドシステム/CI/CDツール/コードテスト・ツールといった、ソフトウェア・サプライチェーンの重要なリンクの侵害を狙ったものである。

次世代型攻撃は、あらゆる言語と、あらゆる種類のソフトウェアで発生しており、その頻度も増加している。一般的な形態としては、タイポスクワッティング/悪意のコード・インジェクション/ツール改ざん (CodeCov インシデント) などが挙げられる。コンテナ・セキュリティ企業である Anchore によると、2021年には 64% の組織が、ソフトウェア・サプライチェーン攻撃の影響を受けたと報告している。

次世代の攻撃の増加する波は、インベントリの作成や、ソフトウェアのアプリケーションとサプライチェーンにおけるコンテンツの透明化を義務付ける、新しい規制を推進している。 米国のバイデン大統領により発行された大統領令 14082 は、米国連邦政府において実行される全てアプリケーションへの Software Bill of Materials (SBOM) の取り込みなどの、セキュリティ慣行に関する複数の項目を義務付けている。

この大統領令を受けるかたちで National Institute of Standards and Technology (NIST) は、アプリケーション・セキュリティのために参照する、アーキテクチャとテンプレートを作成している。つまり、ソフトウェア・セキュリティに関する規制は、コードを生成する企業や、コード上で動作する製品 (SaaS 製品を含む) を販売する、すべての企業に影響を与える可能性が高くなる。

明らかにすると、OSS ソフトウェアのサプライチェーンが経験した問題のいくつかは、オープンソースに限ったこものではない。最近に発生した Microsoft Exchange Server に対するサプライチェーン攻撃や、SolarWinds ネットワーク管理ツールに対する SunBurst 攻撃は、プロプライエタリのコードベースをターゲットにしていた。

とはいえ、OSS は、プロプライエタリなソフトウェアとは全く異なる方法で、製造/保守されている。そのため、いくつかのユニークなリスクが発生する。本章では、これらのリスクと、そのリスクに対処するための、推進されている有望な取り組みについて説明する。

なぜ OSS サプライチェーンは狙われるのか?

主な理由は2つある。1つは遍在性であり、もう1つは弱さである。OSS は遍在しているといっても過言ではない。Sonatype によると、全コードベースの 98% に OSS が含まれているようだが、過少評価である可能性が高い。OSS のコンポーネントを使わず、ゼロからコードを構築することは、現在では不可能である。OSS の普及により、OSS を作成/配布/管理するサプライチェーンが、明らかにターゲットになっている。同時に、OSS の普及は、企業のアプリケーションに含まれる、すべての OSS 依存コンポーネントの保守/更新/パッチ適用に関する、負担を増大させることになる。

そこには、さまざまな困難が存在する。つまり、時間をかけてコードを更新し、脆弱性がないことを確認するよりも、差し迫った問題を解決するために、OSS コードを挿入する方がはるかに簡単である。そのため、Sonatype は、すべてのアプリケーションの 92% に、古いコードや脆弱なコードが含まれていると推定している。私たちは、信用調査会社 Equifax が運営する Apache Struts ソフトウェアへの攻撃 (数億人分の個人情報および金融情報が流出) などを通じて、ユーザー組織による OSS コードの保守が不可能であることの影響を、目の当たりにしてきた。

攻撃者には、OSS が有効な経路であることが認識されている。また、多くのケースで、サプライチェーンが最も脆弱であるため、ここではサプライチェーンに着目していく。サプライチェーンは、責任ある組織間の隙間に存在するため、厳重に管理されていない場合が多く、また、セキュリティが積極的に確保されていない場合がある。

広く利用されているサプライチェーンの構成要素としては、継続的インテグレーション/継続的デプロイメント・ツール、システムに簡単にアクセスできる OSS ライブラリ/パッケージマネージャ/オープンソース開発者用ツールなどがある。そして、多くの場合において、無給の職業としてコードを書く人がいて、パートタイム・メンテナが保守の責任を負っている。

OSS 特有の課題

OSS の3つの主要な利点として、オープン/フリー/トランスペアレントがある。そして、それぞれが、セキュリティとサプライチェーンに関するユニークな課題を生み出している。

オープンの二面性

Linus Torvalds は「多くの視線が、すべてのバグを浅くする」と言った。ある程度はその通りである。しかし、その同じ視線が、修正するのではなく、悪用するために、バグを探しているとしたらどうだろう?インターネット上では、誰もが良い人というわけではなく、GitHub のアカウントを持っていれば、誰でも重要なライブラリにコードを提供できるという、現実を悪用しようとする人も多くいる。このことは、多くの優れたコントリビューターを惹きつけると同時に、多くの悪者や犯罪も惹きつける。

そのような悪の行動は、しばしば隠されたり、時期の選択が行われたりする。たとえば、比較的人気があり、大規模なアプリケーションで使用されている、単独のメンテナが運営するプロジェクトやライブラリに、悪者がコントリビュートを求めることをよく見かける。多くの場合において、メンテナはプロジェクトに対する需要に追いつくために苦労している。悪意の脅威アクターは、支援を申し出た後に、いくつかの良質の PR を提出し、リポジトリへのコミット権限を得るだろう。この時点で、悪意の脅威アクターは、クリプト・ジャッキング・スクリプトのようなマルウェアを、こっそりと挿入するのである。

友人からもらう子犬であり、無料のビールではない

無料というものは、なかなか魅力的な価格だ。購入の注文も不要だ。そのため、きわめて簡単に利用できる。また、無料は素晴らしい流通戦略としても機能する。しかし、無料が割に合わないこともある。ある組織がアプリケーションに依存し、それがクリティカルになった場合、迅速なパッチ適用や、適切なコンプライアンス、公式なサポートの関係を必要とするかもしれない。無償の OSS には保証がなく、それが大きな責任となり得る。アプリケーションのメンテナは、フルタイムの仕事を持っているため、週末の空き時間にコードを書き、修正を適用しているかもしれない。現実に、インターネットを動かす重要なソフトウェアのかなりの部分が、ボランティアによりメンテナンスされているという調査結果がある。

また、無償のコードの場合、何年も更新されないこともある。脆弱性が公開されたときに、あなたが書いた修正プログラムをマージする許可が、得られないかもしれない。もしコードが放棄され、コメントやリクエストを作者がチェックしなくなったら、あなたは行き詰まり、プロジェクトをフォークする以外に、選択肢がなくなるかもしれない。急激なフォークは混乱を生み出し、自身の問題を引き起こす可能性がある。

それは JWT Go という、人気のある Golang ライブラリで起こったことだが、Golang エコシステム全体の依存関係ツリーに入り込んでしまった。JWT Go は、最も人気があり、重要なオープンソース・プロジェクトである Kubernetes にさえ含まれていたのだ。JWT Go に脆弱性が出現したときに、誰もが初めて、メンテナが JWT Go を放棄していることに気づいた。同じバグに対して異なるパッチを適用した、複数のフォークされたバージョンが現れた。そして、カオスが続いた。

ボランティアのメンテナに対して資金を提供するよう、企業が求めることは、よくあることだ。そのためのプログラムとして、GitHub Sponsors/Open Collective/Tidelift などがある。これらの制度は有用だが、十分ではない。少額の資金を渡すだけで、より安全なコードと、プロ級のメンテナンスが得られるわけではない。たとえフルタイムの給与を提供したとしても、しっかりとサポートされた安全なコードには結びつかないかもしれない。

透明性という幻想的な利益

OSS の透明性は本物だが、そのコードが常に監査やレビューを受けているというのは幻想である。たしかに、ソースコードは配布され、公開されている。しかし、その量が膨大であるため、あなたが使っている全てのコードをレビューすることは不可能だ。何百万行/何千万行ものコードを使用しているのであれば、時間もなければ、十分な視線も存在しないだろう。

たとえコード・レビューに対して、かなりのリソースを費やしていたとしても、問題や脆弱性を見逃すことは容易に生じる。また、プロジェクトに対して悪意のコントリビュータが、マルウェアなどの悪質なペイロードを隠しこむことも、かなり簡単なことだ。つまり、ソースコードをレビューすることで、すべてのリスクを排除することはできない。ほとんどの OSS コードにおいて、それが使用されているときには、他の団体や開発者によりコンパイルされたパッケージとして実行されているのだ。

さらに、対象となるパッケージの中身が、監査したソースコードと同じものであるという保証もない。npm や Maven のようなパッケージ・リポジトリでは、脅威アクターたちによる、改ざんされたビルドの挿入や、パッケージの乗っ取りと記載されていないコードの挿入などが生じている。現実に、このような攻撃がよく見受けられるのだ。

CodeCov インシデントは、最近に生じた、より悪質な例の1つである。このユニット・テストにおけるコード・カバレッジを、チェックするための無料のサービスは、インストールに BASH スクリプトを使用していた。このスクリプトにより攻撃者は、コードの秘密を盗み出し、それをエクスポートするマルウェアを挿入していた。それらの秘密は、npm や Maven でパッケージを公開するために必要なトークンである可能性があり、それらの秘密を公開することで、それらのパッケージは危険にさらされることになった。

別の例では、PHP プロジェクトのソースコード配布を管理する、PHP サーバーが侵害されたことで複数のコミットが商事、ソースコード・リポジトリに悪意のコードが注入された。このインシデントは短時間で解決されたが、攻撃者がコード・レビューやセキュリ・ティプロセスをバイパスして、ソースコードをダイレクトに改ざんできることを実証した。

すべてが失われたわけではない

オープンソースとサプライチェーンのセキュリティを向上させる、革新的な取り組みが活発化している。SBOM は受け入れられつつあり、CI/CD パイプラインやビルドシステムから SBOM を自動的に生成することが容易になりつつある。Sigsource と呼ばれる、暗号によるコード署名を容易にするための新しいイニシアチブは、コード署名に対する障壁を取り除くことを目的としている。ソースコードの出所問題を root から攻撃することで、サプライチェーンを侵害しようとする意図は、ユビキタス・コード署名により遥かに困難なものになるだろう。

最後になるが、Open Source Security Foundation は、大手のテクノロジー企業から数千万ドルの資金を集め、また、個々の OSS に対する助成金を提供するなど、この仕組を強固にサポートする体制を構築しているところである。これらの動きは、アプリケーションにおける OSS 依存関係の、ユーザー企業による容易な監査/追跡/信頼を実現し、OSS サプライチェーンを強固なものに変革するものだ。つまり、OSS コードが、開発者の手元からプロダクション環境へと移動する、サプライチェーン全体が強固になるという明るい未来を指し示している。

Secure Software Summit におけるセッションは、以下で参照できる。https://www.techstrongevents.com/Secure-Software-Summit

淡々と、Open Source Software (OSS) サプライチェーンの現状について語り、その論点を整理してくれる、とても有り難い記事です。そして実感するのは、世界中の政治も経済も、そのすべてが、このプラットフォームの上に構築されているという現実です。二宮尊徳の言葉に、「道徳なき経済は罪悪であり 経済なき道徳は寝言である」というのがありますが、少なくとも OSS は、罪悪でもなければ寝言でもありませんね。ほんと、たいしたものです。

%d bloggers like this: