【コラム】オープンソースの終焉が来ているのだろうか？

Shaun O’Meara,Dragonfly

3年前

本稿の著者Shaun O’Meara（ショーン・オメーラ）氏は、MirantisのグローバルフィールドCTO。企業のITインフラストラクチャの設計と構築において20年間、顧客と仕事をしてきた。

ーーー

数週間前、ミネソタ大学の研究者らにより「偽善者のコミット」と彼らが呼ぶものをLinuxカーネルに投入するメソッドが展開されたという憂慮すべきニュースがLinuxコミュニティを揺るがした（ただし結果的には完全に実行されなかったことが明らかになっている）。その主意は、検知が困難な振る舞いを配布し、それ自体には意味はないが、後に攻撃者によって整合されることで脆弱性が顕在化し得るというものだった。

その後すぐに、ある意味同じように憂慮すべきことだが、大学が少なくとも一時的にカーネル開発へのコントリビューションを禁じられたことが発表された。続いて、研究者らが公式に謝罪した。

脆弱性の発見と開示は往々にして厄介なものだが、世界最大かつ最も重要なオープンソースプロジェクトに対して、技術的に複雑な「レッドチーム」プログラムを実行するのは、少々やりすぎだと感じる。こうした振る舞いが爆発的な広がりを持つ可能性があることを理解しないほど、研究者や研究機関が無知であるとか、怠慢であるなどとは考えにくい。

同様に確かなこととして、メンテナーとプロジェクトガバナンスは、ポリシーを強化し、時間の浪費を回避する義務があり、常識的観点では、脆弱性を含まないカーネルリリースの生成に努めることが推奨されている（そしてユーザーが要求している）。しかしメッセンジャーを排除することは、少なくともいくつかの要点を見落としているように思われる。つまり、これは単なる悪意によるものではなく研究に基づくものであり、技術的、体系的な緩和を必要とする、ある種のソフトウェア（および組織）の脆弱性を明らかにしようとするものだということだ。

「偽善者のコミット」に端を発した不慮の事象は、拡張されたオープンソースエコシステム全体とそのユーザーを脅かす、あらゆる面において関連性のあるトレンドの兆候だと思う。このエコシステムは長い間、規模や複雑性、そしてFOSS（フリーソフトウェアとオープンソースソフトウェア）が人間による各種の活動において重要性を増していることにまつわる、数々の問題と格闘してきた。この複雑に絡み合った諸問題を見ていこう。

最大規模のオープンソースプロジェクトは現在、大きなターゲットを掲げている。
その複雑さとペースは、従来の「コモンズ」アプローチや、さらに進化したガバナンスモデルで対応できる規模を超えて拡大している。
互いにコモディティ化する方向に進化している。例えば、分散アプリケーションのために「Linux」と「Kubernetes」のどちらを「オペレーティングシステム」として扱うべきかを明確にすることはますます難しくなっている。営利組織はこれに注目し「フルスタック」ポートフォリオとナラティヴを中心に再編成を始めている。
そうすることで、一部の営利組織は、FOSS参加という従来型パターンを歪め始めている。多くの新機軸が現在進行中である。一方で、資金調達や、FOSSへの人員コミットメントなどのメトリクスは減少傾向にあるようだ。
OSSプロジェクトとエコシステムはそれぞれ異なる方向性で順応しており、場合によっては、営利組織が居心地の良さを感じたり、参加から恩恵を受けることが難しくなっている。

一方で、脅威のランドスケープは進化し続けている。

攻撃者は巨大化し、巧妙化し、高速化するとともに持続性を増しており、長期にわたるゲームやサプライチェーンの破壊などにつながっている。
攻撃はこれまで以上に財務的、経済的、政治的に収益性を高めている。
ユーザーは以前にも増して脆弱になり、多くのベクターにさらされている。
パブリッククラウドの利用が増えるにつれて、技術的および組織的なモノカルチャーの新たな層が生まれ、攻撃を可能にし正当化する可能性がある。
オープンソースソフトウェアから部分的または全体的に組み立てられた複雑な商用オフザシェルフ（COTS）ソリューションは、そのコンポーネント（およびインタラクション）にアクセスできる、悪質な攻撃者によく理解された複雑な攻撃サーフェスを生成する。
ソフトウェアのコンポーネント化は、新たな種類のサプライチェーン攻撃を可能にする。
そして、組織が非戦略的な専門知識を排除し、設備投資を運用コストにシフトさせ、セキュリティのハードワークをクラウドベンダーやその他の事業体に依存するように進化する中で、これらすべてが起こりつつある。

結果として、Linuxカーネルの大規模かつ絶対的な重要性を持つプロジェクトの多くは、大きな変化をもたらす巨大な脅威モデルに立ち向かう準備が整っていない状況にあると言えるだろう。私たちがここで考察している特定のケースでは、研究者たちは比較的少ない労力で侵入候補サイトをターゲットにし（静的分析ツールを使い、コントリビュータの注意を必要としていることがすでに確認されているコードの単位を評価する）、メールで非公式に「修正」を提案し、信頼性が高く、高頻度のコントリビュータとして確立されている彼ら自身の評判を含む多くの要因を活用して、脆弱性コードをコミットされる寸前の状態にした。

これは、堅牢で安全なカーネルリリースを作成するためにこれまで非常にうまく機能してきた信頼システムの「内部者」による重大な裏切り行為だった。信頼を悪用すること自体が状況を変え、それに続く暗黙の要件、つまり体系的な緩和で相互の信頼を支えるということが大きく浮かび上がってくる。

しかし、このような脅威にどう対処すればいいのだろうか。ほとんどの場合、正式な検証は事実上不可能である。静的解析では巧妙に設計された侵入を明らかにできない場合がある。プロジェクトのペースを維持しなければならない（修正すべき既知のバグがある）。そして、こうした脅威は非対称的だ。典型的な言い方をすれば、ブルーチームはすべてに対して防御する必要があり、レッドチームは一回成功すれば良い。

改善の機会がいくつか存在する。

単一培養の広がりを制限する。Alva LinuxやAWSのOpen Distribution of ElasticSearchなどは、広く使われているFOSSソリューションを無料でオープンソースにしていることもあるが、技術的な多様性を注入しているという点からも優れている。
人的要因への完全な依存を緩和し、営利企業に専門知識やその他の資源を提供するインセンティブを与えることを目的として、プロジェクトのガバナンス、組織、資金調達を再評価する。ほとんどの営利企業はオープンソースへのコントリビューションを、そのオープン性ゆえに、またオープンソースにもかかわらずオープンではない場合でも歓迎するであろうが、多くのコミュニティにおいて、既存のコントリビュータの文化を変える必要があるかもしれない。
スタックを簡素化し、コンポーネントを検証することで、コモディティ化を促進する。適切なセキュリティ責任をアプリケーション層に押し上げる。

基本的に私がここで主張しているのは、Kubernetesのようなオーケストレータはあまり重要ではなく、Linuxはそれほどインパクトを持たない、ということだ。最後に、ユニカーネルのようなシステムの使用を形式化することに向けて、できる限り早く進むべきである。

いずれにしても、オープンソースの継続に必要なリソースを企業と個人の両方が提供することを確保する必要がある。