ソフトウェアは「供給品」ではない

編集者注：Snykのオープンソース・オープンスタンダード戦略ディレクター、Daniel Appelquistが執筆した以下の論考では、「サプライチェーンセキュリティ」という用語の起源と、今日のオープンソースソフトウェア開発プロセスに適した表現なのかを考察します。

この文章を書くきっかけになったのは、Thomas DepierreによるMastodonへの投稿を読んだことでした。

この投稿は、最近ずっと気になっていたことに触れていました。ソフトウェアセキュリティについて語るとき、私たちはソフトウェアサプライチェーンや、ソフトウェア部品表（SBOM）といった関連概念について多くの時間を費やしています。この比喩は、産業分野の用語に由来します。経済や製造業の仕組みについて語り慣れている人にとって、サプライチェーンという概念はなじみ深いものです。そのため、ソフトウェアについて、とりわけ依存関係が幾重にも重なるオープンソースソフトウェアについて語る際に、業界の多くの人がこの比喩に飛びついたのも無理はありません。依存関係のような概念を知らない人にも、現代のソフトウェア開発を説明できる簡潔な表現だからです。

しかし、多くの有用な比喩と同じように、これは正確ではなく、適用できる範囲にも限りがあります。サプライチェーンの比喩が指すのはメンテナーだけでなく、ライブラリがオープンソースプロジェクトに届くまでのエコシステム全体と、その間にあるすべてのものです。たとえば、npmレジストリは「供給」元の一つであり、GitHub Actionsマーケットプレイスもその一つです。

オープンソースの世界を一つの連続したコミュニティとして捉える人もいます。しかし実際には、オープンソースは非常に細分化されています。オープンソースには企業寄りの側面があり、「オープンソース／産業複合体」と呼ばれることもあります。この側面には、サプライチェーンをめぐる用語がまったく適切でしょう。一方、対極にあるフリーソフトウェア運動は、「ソフトウェアサプライチェーン」という概念を自らの考え方に反するものと捉えるでしょう。その間には、非常に幅広い立場があります。

Thomasが投稿で的確に指摘しているように、オープンソースソフトウェアの依存関係には、実際のサプライヤー契約は伴いません。その意味で、OSSの開発者は上流プロジェクトへのサプライヤーではありません。「サプライチェーン」という比喩を使うと、誤解を招くおそれがあります。たとえば、オープンソースソフトウェアプロジェクトのメンテナーが企業から法的通知や書簡を受け取るケースです。実際、Log4jの問題が起きた際にも、まさにこのようなことがありました。オープンソース開発者のDaniel Stenbergは、Curlプロジェクトでの基礎的な取り組みで知られていますが、書簡を受け取りました。善意からではあったものの、企業の調達チームはDanielをサプライヤーとして扱い、厳しい期限を設けて、CurlでのLog4jの使用状況に関するデータの提出を求めたのです。サービスレベル契約を含む契約で定められた厳格なサプライヤー関係であれば、こうした連絡も適切かもしれません。しかし、オープンソースの文脈では、まったく適切ではありません。

ソフトウェアサプライチェーンをめぐる用語や考え方は、特にソフトウェアの依存関係やオープンソースの仕組みに詳しくない政策立案者やその他の意思決定者に伝えるうえで、今でも非常に有用だと思います。しかし、この比喩が通用する範囲には限りがあります。この言葉を使う際には、オープンソースの依存関係はサプライヤー契約ではないこと、そして何よりも、自分たちをそのように捉えていないオープンソースソフトウェア開発者のコミュニティ全体が存在することを、念頭に置く必要があります。業界全体でソフトウェアセキュリティの水準を高めるという目標を達成するには、ソフトウェアセキュリティの複合体は、サプライチェーンという考え方になじまない人々やコミュニティも受け入れる、大きな傘でなければなりません。

では、この問題にどう対処すればよいのでしょうか。状況によっては、少し異なる用語を採用することを検討すべきだと思います。一般的なオープンソース開発者コミュニティについて語る場合は、「ソフトウェア依存関係チェーン」という用語のほうが適切かもしれません。あるいは業界として、ソフトウェアサプライチェーンという言葉で何を意味し、何を意味しないのかを、オープンソース開発者に明確に説明する必要があります。