Hands On Google は新しいオープンソース脆弱性データベースに大きな野望を抱いていますが、開始するには Google Cloud Platform アカウントが必要であり、導入を阻む可能性のある他の障害もあります。
チョコレートファクトリーは、オープンソースソフトウェアのセキュリティの現状に不満を抱いています。これは、同社の事業とクラウドプラットフォームがオープンソースコードに依存していることからも大きな問題です。同社は重要なオープンソースソフトウェアにおける規律とチェック体制の強化を求めており、多くのプロジェクトで、侵害されたコードや新たに発見された脆弱性から保護するために、独自のプライベートリポジトリを維持していることを明らかにしました。
セキュリティチームの提案の一つは、脆弱性データを管理する新しい方法であり、「利用可能なすべてのデータソースからの正確な脆弱性メタデータ」も含まれる。また、「新たに発見された脆弱性によって影響を受けるソフトウェアを迅速に把握するための、より優れたツール」も求められた。
同社は現在、オープンソース脆弱性 (OSV) データベースと API を作成することで、このニーズに応えている (少なくともそう期待している)。これにより、オープンソース プロジェクトの開発者やユーザーは、使用している特定のバージョンの欠陥を照会できる。
「各脆弱性について、バイセクトを実行し、バグを発生させたコミットと、それを修正したコミットを正確に特定します」とドキュメントには説明されています。データベースは現時点では小規模で、主にGoogle独自のOSS-Fuzzプロジェクトに基づいています。このプロジェクトは、バグを発見するために意図的にランダムな入力を導入するファジング手法を用いています。このプロジェクトは、275のオープンソースプロジェクトで25,000件以上のバグを発見しています。実際、GoogleはもともとOSS-Fuzz専用にOSVを開発しており、その起源は今回公開された内容からも明らかです。
GoogleがOSVを社内のOSS-Fuzzプロジェクト以外と連携させた場合にどう機能させるかを示した、部分的に野心的な図
OSVの主要機能の一つは、二分法の使用です。これは、コードのどの変更がバグを引き起こし、どの変更がバグを修正したかを識別する手法です。Googleは、オープンソースプロジェクトのメンテナーは「たとえ望んでも、脆弱性に関する徹底的かつ正確な情報を作成し公開する余裕が常にあるとは限らない」と述べています。OSVにバグを再現するテストケースを提供するだけで、影響を受けるコードのバージョンを正確に絞り込むことができるという考えに基づいています。
CVE（Common Vulnerabilities and Exposures）は148,882件のレコード数があり、OSVよりもはるかに多く、既にコミュニティに浸透しているのに、なぜOSVをわざわざ使う必要があるのでしょうか？ドキュメントには、「既存の脆弱性フィード（CVEなど）を集約する予定です。OSVはCVEを補完し、正確な脆弱性メタデータで拡張することで、クエリを容易にします」と記載されています。Googleのセキュリティチームは、「既存の脆弱性標準のバージョン管理スキーム（Common Platform Enumeration（CPE）など）は、バージョン／タグとコミットハッシュで構成されるオープンソースの実際のバージョン管理スキームと適切にマッピングされていません。その結果、下流の消費者に影響を与える脆弱性が見逃されてしまいます」と考えています。
まだ初期段階であり、現状ではプロジェクトメンテナーは自身のコードに関するデータベースの詳細を編集したり追加したりすることすらできません。ドキュメントには、「プロジェクトメンテナーがプルリクエストを作成することで、関連するOSVの脆弱性を編集できる方法を開発中です」と記載されています。
オープンAPIを期待して、データベースへのクエリ実行に関するスタートガイドの指示に従いましたが、すぐにGoogleの世界に迷い込んでしまいました。クエリを実行するには、開発者はGoogleにログインし、Google Cloud Platformにサインアップして、Cloud Platformプロジェクトを作成する必要があります。さらに、同じアカウントでGoogleグループに参加する必要がありました。そうしないと、APIを呼び出そうとするとエラーが発生します。
完全にサインアップすると、curlを使用してOSV APIをクエリできるようになりました。
次のステップは、APIを呼び出すための認証情報を作成し、生成されたAPIキーをコピーすることです。この時点で、キーの使用を特定のIPアドレスまたはアプリに制限するか、無制限に許可するかを決定する必要がありました。キーを取得したら、マップ、Cloud Vision、Speech to Text、カレンダー、スプレッドシートなどの他のGoogle APIと同じ方法で、APIをCloud Platformプロジェクトに追加できました。開発者はGoogle APIの利用規約に同意する必要があります。最後に、APIを有効化し、curlコマンドで呼び出して、Chromiumのバグの詳細をJSON形式で取得することができました。
「APIキーの要件は残念な要件だが、APIで許可されるより高いQPS（1秒あたりのクエリ数）と不正使用を防ぐために必要だ」とGoogleのソフトウェアエンジニア、オリバー・チャン氏は語った。
これらすべてに共通する問題は、OSVがオープンソースコミュニティに属するものではなく、たまたま半公開されているGoogle社内プロジェクトのように思われていることです。Googleが、OSVが所属するOpenSFF（Open Source Security Foundation）と連携してこれを実現していないのは奇妙です。データベースへのクエリを実行するためにユーザーにGoogle Cloud Platformへの登録やその他面倒な手続きを要求するのは、OSVの普及を促進する上であまり良い方法とは言えません。
こうした懸念はさておき、APIは良さそうです。開発ツールは、このAPIを使って「このアプリケーションで使用されているオープンソースライブラリの正確なバージョンにどのような脆弱性があるのか」という具体的な質問に答えることができます。しかし、その有用性は幅広い支持を得ることにかかっているため、こうした初期の障害は残念です。®
