LFとOpenSSF、OSSのセキュリティを向上させる具体的な計画を日本で発表

The Linux Foundation（LF）が配下のOpen Source Security Foundation（OpenSSF）と共同で、都内でイベントを開催した。これは2022年5月12、13日にアメリカ、ワシントンDCで開催されたOpen Source Security Summit IIというイベントで発表されたプランに関する日本向けの説明会という形で、日本のパートナー、政府機関などに向けて行ったものだ。このプランはオープンソースソフトウェアのセキュリティを高度化するための3つの目的、その目的を支える10の具体的な計画をストリームと呼んで構成されている。

プレス向け質疑応答に答えるLFのJim Zemlin氏

この計画書のポイントは、以下に示した3つの目的に対して10の計画が紐付けられているという点で非常に具体的な実行計画になっているところだ。

• セキュアなOSSの作成
• 脆弱性の検出と修復方法の強化
• エコシステムでのパッチ適用応答時間の短縮

その目的とプランの詳細な説明の前に、前書きとして書かれていることも紹介しよう。

エグゼクティブサマリーでは、現代のソフトウェアサプライチェーンがオープンソースソフトウェア（OSS）に大きく依存していることを示し、開発されるソフトウェアには約70％から90％の割合でOSSが含まれているとしている。その上で複雑なソフトウェアサプライチェーンに対するセキュリティを向上させるためには、事後対応から事前対応に変えること、つまりシフトレフトを行う必要があると説明。そして、OSSのサプライチェーンを体系的に強化することが費用対効果の面で有効であると強調している。

また、すべてのソフトウェアにはバグが含まれていると想定するべきだし、OSSを開発しているチームと協力することが重要だと解説し、OSSの開発にはメンテナーとコントリビューターが存在することを改めて書き記している。セキュリティの観点において、メンテナーはプロジェクトに対して悪意のあるソフトウェアが紛れ込まないように努力する最前線の防衛線であると説明している。ここで、コントリビューターとメンテナーを明確に異なるものであると明記したのは、単なるコードを書く、パッチを書く、ドキュメントを書くというコントリビューターの役割とは違い、メンテナーにはプロジェクトの運営を守る責任者という役割があることを明確にしていると言える。

アジャイルなソフトウェア開発ではプロジェクトマネージャーではなくプロダクトマネージャーが必要だということが言われて久しいが、ここではメンテナーはプロダクトではなくプロジェクトを維持する責任を持つ者という意味になるだろう。例えば新しいECサイトを開発するプロジェクトの場合、アウトプットであるサイトをプロダクトと位置付けてソフトウェアサプライチェーンを高速に回すことがアジャイル開発の方法論だ。OSSの場合、特にそのソフトウェアがシンプルな機能を実現することを目指し、単体で価値を産み出すというよりも他のOSSと連携して使われることによって価値を作り出すものであるならば、プロダクトの価値という視点だけではなくそのプロジェクトを持続させる努力が必要になる。

ビジネスの観点ではOSS単体の持つ価値は表現しづらく、アジャイル開発で作られたソフトウェアの価値は測りやすいという違いも、OSSにはプロジェクトマネージャーが、商用のためのソフトウェアであればプロダクトマネージャーが必要ということに集約されるのかもしれない。OSSにおいては一般的に、コントリビューターにコード／パッチの作成を強制する力がない一方で、企業内での開発であればデベロッパーがコード／パッチを書くのは被雇用者としては当然の義務だという違いも大きい。それほどにメンテナー（プロジェクトマネージャー）はコミュニティの維持と継続に力を注ぎ、コントリビューターがコードを書き続ける環境を作ることに努力するべきということだろう。これはApache Software Foundationがマントラとして標榜する「Community over Code」とも通じる、アウトプットよりもそれを産み出す人々を重視するという発想といえる。

「メンテナーはプロダクトマネージャーか？ プロジェクトマネージャーか？」という議論は、それぞれのOSSプロジェクトによっても異なるだろうし、そのプロジェクトの生い立ちにも関わる問題だ。企業が強力にバックアップしているOSSと個人のアイデアからコミュニティが醸成されたOSSでは違いがあっても当然だろう。これはプロジェクトに関わるエンジニアが自問するべき命題かもしれない。

10の実行計画であるストリームについては「OpenSSFコミュニティの専門家の小さなチームによる数週間の取り組みから得られた成果」であるという。それを叩き台にしてデューデリジェンスを実施、その上で実際の作業を行える組織や個人を探し、それを委託するという形式を採るようだ。そのため目的に賛同し、実際に作業を行える組織や個人からの参加を募りつつ、ここで集められた予算を使っていくという形になる。ただし、スタートの時点で計画そのものが変更されることもあるとしている。またOpenSSFのTAG（Technical Advisory Group）が支援を行うことも明記されているため、ストリームが自主的にガバナンスを行うという意味でもないことには留意するべきだろう。すべてのストリームがLF及びOpenSSFの管理下にあるという意識が必要だ。

OpenSSFのエグゼクティブディレクター、Brian Behlendorf氏

この中から、ストリーム2の「リスク評価用パブリックダッシュボードの開設」に注目したい。これはOSSコンポーネントを対象にリスク評価用のダッシュボードを提供するという計画だ。リスクを回避するためにOSSの開発が適切に行われているか？ を評価すると同時に「ソフトウェア構成分析（SCA：Software Composition Analysis）によって、依存関係にあるコンポーネントの脆弱性を追跡し、アップストリームのコンポーネントのバグが他のコンポーネントにどのように影響するかを明らかにします」という。

注目すべき点は、エンドユーザーにとっては脆弱性に気付くことができると同時に、メンテナーにとってはプロジェクトにリスクが少ないことを外部に発信することで安心感を醸成できるということだろう。これにはLFがOpenSSFに引き継いだCII（Core Infrastructure Initiative）のベストプラクティスバッジがそのまま利用されるようだ。このダッシュボードは、LFの既存のプラットフォームLFX SecurityとLFX Insightsプラットフォーム上に構築することを予定している。「資金を得ることができれば、この取り組みの初期段階で、最も費用対効果の高い、適切なスターティングポイントが選択されるよう、多くのアプローチが公に議論され、検討されます」とあるように、このストリームにはまだ資金の提供元が確保されているわけではないという点に注意したい。予算はどこから出るのか？ という当然の疑問については、記事の最後にQ＆Aの形式でOpenSSFから届いた回答を紹介しているので最後まで読んでほしい。

次に注目したいのは、ストリーム3で示されたソフトウェアリリースにおけるのデジタル署名を加速させるという計画だ。具体的にはOSSのデジタル署名のためのツールであるSigstoreを使って、関連するすべてのコンポーネントについて署名を行うことで、そのソフトウェアの出所が確認されることを実現する。またメンテナー向けのトレーニングも行うことが明記されており、ここでも何をするのか？ だけではなく、どうやってそれを実現するのか？ という視点が明らかになっている。Sigstoreを公共財として位置付けることの必要性を説明し、現在はPurdue大でホストされている認証局などを、より広範囲の利用が可能になる安全なバックエンドを確立するというのがこのストリームの目的となる。その際には、Let's EncryptをホストしているISRG（Internet Security Research Group）とも議論を進めながらということになる。

次に注目したいのは、ストリーム4のメモリーセーフに関する計画だ。これはCやC++といったメモリーセーフではないプログラミング言語で書かれたOSSを、RustやGoと言ったメモリーセーフな言語で書き換えるという作業を指している。これはISRGが推進しているProssimoというイニシアティブをそのまま利用する方向のようだ。

ProssimoについてはISRGのSarah Gran氏にインタビューした記事を参照されたい。Gran氏はこのストリームの作成者の一人だろう。

参考：ISRGが推進するメモリーセーフなソフトウェアを増やすための地道なプログラムProssimoを紹介

メモリーセーフについてはRustが最初のプログラミング言語として言及されているが、GoとJavaについてもメモリーセーフな言語として認定しているようで、RustをホストするRust Foundationだけではなく、JavaについてはEclipse Foundationとの連携を検討しているという。Goについては独立した助成金を通じて行うと書かれているようにRustやJavaとは違う扱いになりそうである。

他にもOpenSSF内にセキュリティインシデントレシポンスチームを設立することや、OpenSSFのAlpha-Omegaプロジェクトを使うこと、年に1度のコードレビューを200のプロジェクトに対して行うことなど、全方位的なアプローチを取っていることが特徴だ。

SBoM（Software Bill Of Materials）についても言及しており、LFが推進するSPDXだけではなくOWASPが推進するCycloneDXとのロスのない変換の実現など、すでに顕在化しつつある複数のプロダクト間で存在する問題点をカバーする予定があることにも注目したい。

ただ、SBoMに関してはユーザーが利用するOSSに対する部品表が出力でき、脆弱性の有無が確認できるというだけではなく、そのOSSを開発するコミュニティの健全度を知ることが必要となるだろう。これはストリーム8で定義されている「クリティカルなOSSでありながら保守が不十分なソフトウェアを発見する」という計画が応用できるだろう。エンドユーザーにおけるSBoMに必要なのは、単に部品表として「自社の使っているOSSに脆弱性があるのか？」に加えて「活動が活発か？」「新しいリリースがあるのか？」を確認するためのダッシュボード的な使い方だろう。そのような視点のダッシュボードが出てくることに期待したい。

全体として興味深い内容が多く含まれた内容となっているため、ぜひ日本語訳の書面を確認して欲しい。かなり踏み込んだ内容となっており、基本となる人的コストの算定や初年度次年度の違いなどマーケティング担当ではない実際にソフトウェア開発を経験してきたエンジニアが書いたと思われる雰囲気を感じとれるはずだ。プランの名称が英語のMobilization Planから「動員プラン」という耳慣れない単語になっているが、「実際に実行する計画である」という意図が感じられる良い命名だと個人的には思っている。

動員プランの日本語訳（PDF）：OSS セキュリティのための動員プラン

ストリームごとの金額については以下の表を参照して欲しい。プランの12ページからの引用である。

10の実行プランの予算概要

最後にこの計画書についてOpenSSFに対して送った質問に対する回答も紹介したい。

Q1：10のそれぞれのプランの起案者というのは誰（どの会社？）なのか？

A1：動員プランの14ページに書いてある謝辞のリストに掲載されている人名がこのプランの作成者である（ISRG、WiproからRed Hat、Google、Microsoft、Ciscoからモルガンスタンレー、Purdue大学など多種多様な企業、組織が貢献しているが、どのプランについて誰が？ という部分についての回答はなかった）。

Q2：プランの実行を評価する仕組みが特に記載されていないが、年度ごとのレビューは誰（起案者？ OpenSSFのコミッティ？ 外部の第3者？）が行うのか？

A2：各ストリームの計画の中に初年度、次年度のレビュープランも含まれている（あくまでもレビューの仕組みが組み込まれるということで、誰が行うのか？については回答はなかった）

Q3：合計の予算となる初年度約90億円、次年度約100億円という金額はそもそもどこから出ているのか？

A3：各ストリームの作成者に実用的かつ野心的な発想で、既存の取り組みを拡大するか、OSSエコシステムの一部から他の部分に実証済みの手法を適用し、最初の2年以内に十分なリソースがあれば達成可能な意味のある目標を設定するアプローチを作るよう依頼した。その合計がこの金額である。前述のようにこれらのコストに影響を与える可能性のある多くの要因があるが、これらの目標を達成できるという高い信頼性を提供するため、必要な投資の大まかな規模を決定するために無駄がなく現実的なこれらのアプローチの予算を作成するように依頼した結果である（金額がどこから拠出されるのか？という質問への回答はなかった）。