セキュリティ

Googleが提案するオープンソースプロジェクトのセキュリティを高めるための「Know, Prevent, Fix」とは?


多くのソフトウェア開発プロジェクトで、ソースコードを商用・非商用を問わず無償での利用・修正・頒布することを認めるオープンソースが採用されていますが、オープンソースのソフトウェアには一定のセキュリティリスクがつきまといます。Googleが公式セキュリティブログで、オープンソースソフトウェアの脆弱(ぜいじゃく)性について、「Know, Prevent, Fix(知る、防ぐ、修正する)」というフレームワークを提唱しています。

Google Online Security Blog: Know, Prevent, Fix: A framework for shifting the discussion around vulnerabilities in open source
https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html

Open source: Google wants new rules for developers working on 'critical' projects | ZDNet
https://www.zdnet.com/article/open-source-google-wants-new-rules-for-developers-working-on-critical-projects/

オープンソースのプロジェクトは有志によって自由に開発が行われます。そのため、品質は必ずしも保証されておらず、確かなサポートも存在しません。Googleはオープンソースソフトウェアが背負うセキュリティリスクに対応するためのフレームワークとして、以下の3点を提案しました。

◆1:ソフトウェアの脆弱性について「知る」
まず、脆弱性のメタデータを利用可能なすべてのデータソースから捕捉することが重要だとGoogleは訴えています。たとえば、どのバージョンで脆弱性が発生したのかを知ることは、ソフトウェアが影響を受けるかどうかを判断するために役立ちます。

また、オープンソースソフトウェアの脆弱性を追跡するためには、脆弱性に関する情報の業界標準的な枠組みが必要だとGoogleは訴えました。脆弱性を扱う情報の形式が業界内で統一されれば、複数の脆弱性データベースにまたがって共通の手法を用いることができるため、脆弱性の追跡が容易になります。

さらにGoogleは、ほとんどの脆弱性がソフトウェアのソースコードそのものよりも、ライブラリやパッケージとの依存関係にあると指摘。特にJavaやJavaScriptで書かれたソースコードは何千ものライブラリやパッケージと依存関係にあることが多いため、脆弱性を探ることは非常に困難なものとなります。そのため、Googleは「ソフトウェアの依存関係を正確に追跡することが重要」としていますが、実際に手作業で監視を行うのは非現実であるため、このプロセスは自動化するべきだと述べています。


◆2:新しい脆弱性が追加されることを「防ぐ」
新しい脆弱性が追加されないようにするためにはテストや分析ツールの使用が望ましいですが、それ以前の問題として、新しい脆弱性が追加されないための防止策も重要。そのために、Googleは「新しい依存関係を決定する際のリスクを把握する」「開発プロセスの改善」の2つを挙げました。

ライブラリやパッケージとの依存関係を構築することには一定のリスクがあり、依存関係を一度構築してしまうと、時間が経過してソフトウェアのバージョンが進むにつれて削除することが難しくなります。そのため、新しくライブラリやパッケージを利用するためには、あらかじめ導入によるリスクを把握することが重要だとGoogleは説いています。

また、多くの脆弱性は開発プロセスにおけるセキュリティ意識が低いことから発生しているとGoogleは指摘。「開発に携わる人が全員2要素認証を採用しているか」「定期的なビルドとテストを継続的インテグレーションを採用しているか」「ファジングは実施しているか」など、開発プロセス上でのセキュリティリスクを減らすための策を講じる必要性があるとGoogleは述べました。


◆3:脆弱性を「修正する」
Googleは開発プロジェクトで脆弱性を修正するためには「他の人がコードにどのように手を入れたのか」「プロセスのどこで止まっているのか」「脆弱性修正の責任が誰にあるのか」「説明責任が誰にあるのか」を把握する必要があると主張し、脆弱性の発見や修正を通知する仕組みも求められるとしています。

そして、脆弱性の修正で最も厄介なのがバージョン要件です。Googleは新しいバージョンだけではなく古いバージョン、特に最もよく使われているバージョンの脆弱性を修正することも重要であり、理想は広く使われているバージョンすべてを修正すべきだと説いています。ただし、すべてのバージョンの修正を手作業で行うのは困難なので、1つのバージョンが修正された場合、他のバージョンの修正を自動で行うシステムも役立つだろうと、Googleは述べました。


ただし、オープンソースの開発時にマルウェアなどを仕込まれる「サプライチェーン攻撃」に対処するには、上記の問題では対応できない場合もよくあります。Googleは、重要なソフトウェアをオープンソースで開発する場合、「ソフトウェアのコードに勝手な変更を加えず、必ずチェックを受ける」「第三者に独立したコードレビューを要求する」「プロジェクトのオーナーとメンテナーは決して匿名であってはならない」「オーナーとメンテナーによる2要素認証」「ビルドプロセスの透明性と信頼性の維持」などが求められると訴えています。

この記事のタイトルとURLをコピーする

・関連記事
無料で超高性能なメディアプレイヤー「VLC」開発プロジェクト「VideoLAN」オープンソース化から20周年 - GIGAZINE

WebRTCの標準規格入りを標準化団体のW3CとIETFが宣言 - GIGAZINE

GoogleのVRお絵かきソフト「Tilt Brush」がオープンソース化される - GIGAZINE

Amazonがライセンス変更した「Elasticsearch」をフォークしオープンソース版として提供続行することを決定 - GIGAZINE

オープンソースの著作権を巡るElasticとAmazonとの闘い - GIGAZINE

中国のオープンソースプロジェクトを取り巻く環境とは? - GIGAZINE

in ソフトウェア,   セキュリティ, Posted by log1i_yk

You can read the machine translated English article here.