オープンソースのJavaライブラリApache Log4j 2に、悪名高いLog4Shellエラーメッセージの脆弱性が専門家によって発見されたのは、ほぼ1年前のことでした。この脆弱性は、攻撃者が開発者やエンドユーザーのシステムに悪意のあるコードを忍び込ませるための、オープンソースソフトウェアのバックドアの最近の例の一つに過ぎませんでした。それ以来、Log4jShellの脆弱性を悪用しようとする試みは数千万件に上ります。
参照：イランの国家と連携した脅威アクターがサイバースパイ活動とキネティックキャンペーンで新たな被害者を狙う（TechRepublic）
専門家が2023年の主要なセキュリティ課題としてソフトウェア供給を挙げているのに対し、Log4j現象、そして2020年12月に発生した、より広く知られているSunburstマルウェアの侵入（通称SolarWinds攻撃）は、プロセスの保護がいかに困難であるかを浮き彫りにしています。商用ソフトウェアの大部分は社内で開発されたものではなく、GitHubなどに存在するLog4jのようなフリーソフトウェアやオープンソースソフトウェアパッケージの無法地帯から派生したものです。
オープンソースソフトウェアの依存関係には依存関係がある
庭師がたった1本のツタの植物を摘み取ろうとするのと同じように、FOSSエコシステムからコードをインポートするアプリケーション開発者は、GitHubなどのリポジトリから提供される外部パッケージがしばしば推移的な依存関係をもたらすため、期待以上のコードを手に入れることがよくあります。これらは、FOSSパッケージと他のオープンソースコードとの間に存在する二次的、三次的な関係であり、出所不明で開発者には見えず、本質的に信頼できず、潜在的に危険な、いわば「隠れた」ルートのようなソフトウェアシステムを構成します。
参照:パスワードマネージャーの不適切な使用は個人情報盗難の危険にさらす(TechRepublic)
Endor Lab の Station 9 による「依存関係管理の現状」と題した新しい調査では、すべての脆弱性の 95% が、開発者によって選択されたのではなく、間接的にプロジェクトに取り込まれたオープンソース コード パッケージで発見されていることが明らかになりました。
「ある指標によると、開発者がソフトウェアプロジェクトに持ち込む依存関係1つにつき、平均77～78個の推移的依存関係が存在すると言われています」と、Endor Labsの共同創業者兼CEOであるVarun Badhwar氏は述べています。「さらに、発見された脆弱性の95%は、これらの推移的依存関係、つまり開発者が持ち込んだものから派生したものに存在します。私たちは、これらすべてを自社の環境内で追跡し、これらのパッケージがどのアプリで使用されているかを把握する必要があります。」
Endor Labs のセキュリティ研究者 Henrik Plate 氏は、ソフトウェアの作成は今では BMW を組み立てるようなものだと指摘した。
「どこか別の場所から多様な部品を取り出し、それを組み立てているのです」とプレート氏は語った。
バドワール氏は、典型的な現代のアプリケーションのコードのうち80%から90%は「自分たちが書いたコードではなく、借りてきたコードであり、誰から借りてきたのかさえ分からない」と述べた。「攻撃者はこのことを理解しています。オープンソースソフトウェアはソフトウェアサプライチェーンのセキュリティの基盤となるでしょう。ですから、この問題について市場をより深く理解してもらう必要があります。」
彼は、ソフトウェア部品表フレームワークは正確な依存関係情報を提供するように設計されているにもかかわらず、実際にはほとんど提供されていないと指摘しました。特に、ある依存関係レベルではそれほど正確ではない推移的な依存関係については、正確な情報を提供していません。
参照:マイクロソフトがソフトウェア部品表に関する大統領令に準拠するために情報を公開する方法(TechRepublic)
議会は、オープンソースソフトウェア（FOSS）セキュリティ問題の緊急性を認識し、2022年9月にオープンソースソフトウェア保護法案（Securing Open Source Software Act）を提出しました。この法案は、CISAに対し、「政府、業界、オープンソースソフトウェアコミュニティのフレームワークとベストプラクティスを組み込んだ、オープンソースソフトウェアコンポーネントのリスク評価のためのフレームワークを公開する」ことを強く求めました。しかし、法案提出以来、進展は見られません。
重要なオープンソースソフトウェアはどれですか?
Log4jの調査員たちは、エンタープライズソフトウェアにとって最も重要なFOSSパッケージについてコンセンサスが得られているかどうかを把握しようと試みました。これらのパッケージは、最も多くの開発者や下流のユーザーに最も多く使用され、最も幅広い機能を持ち、依存関係を通じて最も潜在的なリスクにさらされる可能性のあるパッケージです。
これを実現するために、研究者らは、重要なプロジェクトを特定するための最も人気のある 2 つのコミュニティ イニシアチブである、Linux Foundation が支援する「Census II of Free and Open Source Software — Application Libraries」と Open Source Security Foundation の Criticality Score プロジェクトから重要度スコアを調査しました。
「我々は、これらのアプローチが収束するかどうか、つまり何が重要で何が重要でないかについて合意するかどうかを知りたかったのです」とプレート氏は述べた。
Census IIとOpenSSF Criticality Scoresのプロジェクトセットには、大きな重複はありませんでした。調査では、Census IIのパッケージの多くが同じプロジェクトから派生していること、そしてCensus IIのグループに含まれる264個のJavaベースパッケージがわずか169の異なるプロジェクトから派生していることが指摘されています（図A）。
図A
これは、10 年以上ソフトウェア サプライ チェーンのセキュリティ分野で働いてきたセキュリティ専門家であるニューヨーク大学タンドン校工学部のジャスティン カポス教授にとって、驚くべきことではありませんでした。
「実は、どのオープンソースプロジェクトが重要かという独自の分析を行ったのですが、そのデータを公開しないことに決めました。重要度を測るのに十分な確固とした指標を思いつかなかったからです」とカポス氏は述べた。「これは難しい問題です。」
Endor チームは次のことも発見しました。
- 最もよく使用されるオープンソース パッケージの半分は今年更新されず、30% は 2018 年より前に最後のリリースがありました。
- オープンソース ソフトウェア パッケージの最新バージョンに脆弱性がある可能性は 32% です。
- パッケージを最新バージョンにアップグレードした場合でも、既知の脆弱性が残る可能性が 32% あります。
- Census II のパッケージの 75% は、重要度スコアが 0.64 未満です。これは 0 から 1 までのスケールで、0 が最も重要度が低いことを意味します。
- 優先順位付けを行う際にセキュリティ メトリックのみを使用すると、脆弱性の可能性は 20% しか低減されません。
オープンソース：買主の責任
Badhwar 氏は、欠陥のあるソフトウェアが組織のインフラに浸透したらそれを排除する責任があるため、最終的には組織が FOSS 審査プロセスを主導することになるだろうと指摘した。
「国土安全保障省がLog4jの流出場所を突き止め、修復するまでに約3万3000時間かかりました」と彼は述べた。「すべての組織とソフトウェアベンダーは、自社環境内のすべてのコンポーネントと依存関係を追跡する必要があります。まずは、開発者がインターネットから持ち込んでいるものをソフトウェアレベルでインベントリとして生成することから始めましょう。」
プレート氏は、重要度は変化するため、その判断は外部委託できないと述べた。
「すべてのユーザーには独自のセキュリティ要件があります」と彼は述べた。「最終的には、開発組織が販売する商用ソフトウェアサービスと製品に対して責任を負うことになります。そのため、オープンソースコミュニティに単純にアウトソーシングすることはできないのです。」
