Log4j が明らかにしたもの:ソフトウェアの依存関係と SBoM のすすめ

Log4j Highlights Need for Better Handle on Software Dependencies

2022/01/04 DarkReading — 新しい年を迎えたが、サイバー・セキュリティ業界は、またしてもソフトウェア・サプライチェーン・セキュリティの悪夢がもたらす、長期化が予測される問題に直面している。アプリケーション・セキュリティのゼロデイ問題が多発した1年の最後に生じた、Log4j の脆弱性 (Log4Shell) の問題は、2021年のテーマに沿ったブックエンドのようなもので、SolaWinds がスタートさせた年を、同じようなかたちで締め括る。

これらのインシデントがもたらした現実的な影響は、数え切れないほどの視点を提供し、企業の IT チームに教訓を与えた。おそらく、多くの企業にとって最も重要な教訓は、自社のソフトウェア・ポートフォリオの中で、どのようなコードが実行されているかを真に理解し管理するためには、膨大な作業をこなす必要があるということだ。前述の SolarWinds インシデントと同様に、Log4j の騒動は、エンタープライズ・ソフトウェアに、如何に数多くの隠れたソフトウェア依存関係が存在するのかを明示した。そして、これらの依存関係が十分に理解されていない場合には、根本的欠陥を排除することが極めて困難であることを浮き彫りにした。

それは、ソフトウェアにおけるマイクロサービス化やコンポーネント化などの、現代の開発技術の自然な流れに起因している。つまり、現在のソフトウェアの多くは、オープンソースやサードパーティのプレハブのようなコードで構成されているのだ。ソフトウェア・エンジニアはアプリケーションごとに、新しいコードを書いて車輪を再開発するのではなく、既存のライブラリやパッケージを組み合わせて、アプリケーションを実行するコードベースの大部分を作成している。

Sonatype が発表した 2021 State of Software Supply Chain Report によると、2021年には 2兆2,000億個以上のオープンソース・パッケージが、オンライン・リポジトリからダウンロードされ、世界中の開発者の作業に利用されている。そのダウンロード数は、前年比で 73%増となっている。

このようなアプローチは、開発作業をより迅速かつ予測可能なものにする。しかし、Log4j などの基盤となるコンポーネントに脆弱性が発見された場合には、連鎖的なリスクの伝搬がもたらされる。大きな問題の1つは、プレハブのような大量のライブラリやオープンソース・プロジェクトが互いに依存しており、数層におよぶ依存関係の連鎖が生じていることだ。そのため、間接的な依存関係が存在し、Apache のようなオープンソースのエコシステムにおける様々なプレイヤーが連携しなければ、企業の防御担当者による対応が困難な状況となっている。

Google の Open Source Insights Team による最新の調査によると、Apache Log4j ライブラリの脆弱性の影響を受ける Java パッケージの 80% は、ダイレクトにアップデートすることが不可能であり、欠陥に対処するためには各種のプロジェクト・チーム間での調整が必要になるとのことだ。そのため、今回のソフトウェアの脆弱性がもたらす広範なリスクを排除するためには、アプリケーション・セキュリティや開発の専門家たちが、何年もの時間を費やすことになる。

セキュリティとソフトウェアの専門家たちが Log4j の危機的状況から抜け出し、2022年に向けての優先順位を決め始めるとき、昨年の出来事をきっかけに、Software Bills of Material (SBoMs) によるトラッキングと、依存関係管理の規律強化が、より広く推進されることが期待される。

ReversingLabs の Chief Software Architect である Tomislav Pericin は、「SBoMはソフトウェアの成分表のようなものであり、アプリケーションで使用されているコンポーネントや依存関係を特定するための、正式な方法を提供する」と述べている。

Pericin は、「SBoM は、ソフトウェア・パッケージの依存関係を知るための重要な手段だ。その価値が重要なのは、ソフトウェア・インベントリの作成が可能になることで、攻撃や脆弱性が発生したときに、問題が生じる場所/アップデートを入手する場所/オフラインにすべきものなどを、尋ねられる環境が得られることだ。そして、もちろん、悪魔は細部に宿るものとなる。多くの SBoM は、いまだに手動で作成/管理されています。ソフトウェアの変更頻度やアプリケーションの量などを考えると、個人が SBoM を維持して最新の状態に保つのは難しいだろう」を述べている。

SBoM の作成および標準化は、成熟の最中にある。昨年にバイデン政権は、サイバー・セキュリティに関する大統領令で、連邦政府機関に提供されるソフトウェアの開発者に対して、そのソフトウェアに SBoM を提供することを義務付ける文言を盛り込んだ。その直後に、米国の電気通信情報局 (National Telecommunications and Information Administration) は、SBoM の最小要素を詳細に記した文書を発表した。その一方で、Linux Foundation などの業界団体は、世界的な SBoM の実施状況を把握するための調査を行っている。つまり、アプリケーション・セキュリティの専門家や、サイバー・セキュリティのリーダーたちは、今日のソフトウェア開発環境におけるリスクを管理するために、SBoM のトラッキングに磨きをかける方法を見つける必要があるということだ。

Invicti Acunetix の Head of Engineering である Nicholas Sciberras は、「最近のアプリケーションでは、オープンソースやサードパーティ製コンポーネントが広く使用されているため、SBoM がサイバー回復力の基礎的な要素になっている」と述べている。

Log4j 問題の本質を整理する記事です。文中でも参照されている Google の調査結果ですが、それを読んだ多くの人々が感じたはずです。これは、セキュリティの問題というよりも、いまのソフトウェアの在り方の問題なのだと。それにより、この業界は急成長を遂げましたが、たいへんな問題を抱えていることに、いま気づいたわけです。これは、単に Log4j だけの問題ではありません。2021年6月の「アプリケーションに含まれる Third-Party ライブラリの 79% が更新されていない?」という記事ですが、これを読めば問題の広さと深さが分かるはずです。そして、根本的な対策の柱として、SBOM (Software Bill of Materials) が浮上してきたわけです。→ Log4j まとめページ

%d bloggers like this: