Google Cloud の Assured OSS サービス:審査済みの Open Source コンポーネントを提供

Google Cloud Aims to Share Its Vetted Open Source Ecosystem

2022/05/18 DarkReading — Google によるセキュリティ対策の恩恵を望む開発者は、Google の開発者がセキュリティ問題を検証し、パッチ適用を把握している、オープンソース・コンポーネントを利用するサービスを、まもなくサブスクライブできるようになる。この Assured Open Source Software (OSS) と名付けられたサービスは、頻繁なスキャンとコード解析により作成されたメタデータで補強される、新たな Supply chain Levels for Software Artifacts (SLSA) フレームワークに準拠する。したがって、Google の署名を受けた、オープンソース・パッケージのバージョンが提供されることになる。

Google Cloud の VP of Infrastructure であり、Google Fellow でもある Eric Brewer は、このサービスについて、多くの点で Red Hat や Ubuntu などが管理する Linux ディストリビューションと似ていると言う。

Eric Brewer は、「キュレーションされたバージョンを持つという考えは、新しいものではないが、これまで以上に重要性が増している。さらに、出所確認/メタデータ作成/スキャン/ファジング/ソースからのビルド、そして署名を、実際に行うことが重要であることを示したかった。それが正しいやり方である」と述べている。

先日には、Linux Foundation と Open Software Security Foundation が、40社近い企業の支援を受けて、オープンソース・ソフトウェアのセキュリティ確保に関する計画を発表した。その取り組みは、オープンソース製品の、安全性確保/脆弱性の発見・修正の改善/パッチ・サイクルの高速化という、3つの大項目における 10の個別イニシアチブにフーカスするものだ。

この取り組みにおいても、Google は主要スポンサーであり、Security ScorecardsAllStarsAlpha Omega Project などの、セキュリティにフォーカスする無数の取り組みに技術や仕様を提供してきた。そして、その1週後に発表された Assured OSS は、最終的に有料の商用サービスになると Brewer は言う。

Brewer は、「先週は、コミュニティに焦点をあてた話だった。それらをより良く、また、より使いやすくするためには、多くの異なる企業からの、多くの民間投資が必要であり、また、特に重要なコア部分については、多くの産業界の協力が必要である」と述べている。

Open source software requires companies to analyze and maintain commonly used components.
Open source software requires companies to analyze and maintain commonly used components. Source: Google Cloud blog

100K コアでのスキャン/ファジング/チェック

大半の企業は、独自のパッケージ管理システムを、プライベート・リポジトリとして維持している。しかし、Google の審査とセキュリティ・テストのレベルは、その数字で見ると重要であることが分かる。

Google は Assured OSS サービスを発表したブログポストで、10万個のプロセッサ・コアをベースにした巨大なインフラを用いて、最も人気の高い 500以上のパッケージを継続的にファジングするなどの、End-to-End のプロセスを持っていると述べている。また、SLSA フレームワークを通じて、SBOM (software bill of materials) とサプライチェーンの完全性チェックも提供するという。

また、Assured OSS フレームワークは、ソフトウェア・セキュリティ分析企業である Snyk とネイティブに統合される予定だ。

Google Cloud はブログで、「ほとんどの企業は、このような包括的なプログラムを、構築/運用するためのリソースや経験を持っていないと認識している。その代わりに、それぞれの開発チームは、サードパーティのソースコードやパッケージの入手先/構築方法/組織内での再配布方法などを、それぞれの目標/脅威リスクモデル/リソースに応じて個別に決定しているかもしれない」と述べている。

重複する取り組みがもたらす非効率的なリスク

吟味されたオープンソース・ソフトウェアの、精選されたコレクションを提供しているのは、Google だけではない。前述の Linux ディストリビュータに加え、Anaconda などの各サービサーが、ユーザー企業におけるパッチ適用と整合性の問題の管理を含む、吟味されたリポジトリを作成している。さらに、Snyk/Sonotype/Debricked といった企業も、オープンソースのプロジェクトやライブラリを、セキュリティ指標により評価する方法を提供している。

しかし、Google の新サービスは、上位 500 のパッケージについて分析を行うものであるため、複数の企業が重複した同様のサービスを提供し、人気がないが重要なパッケージが検証されないという可能性を提起している。Brewer は、「ある会社が見つけた脆弱性を、別の会社が見逃す可能性があるため、大半のケースにおいて冗長性は良い特性だが、ユーザー組織としては、より多くのパッケージをカバーすることが重要である」との認識を示している。

彼は、「つまり、オープンソースの性質上、すでに共有されているため、より協力していく必要性があると思う。最低限の調整として、同じパッケージを修正するのではなく、異なるパッケージを修正するようにする必要がある。それができないと、この世界に非効率が生じる」と述べている。

Google によると、Assured OSS は、2022年 Q3 にプレビューが可能になる予定だ。

このところ、GitHub などの OSS リポジトリがら、悪意のパッケージがダウンロードされ、開発環境がマルウェアに汚染されるという、「Heroku が語る先日の GitHub 攻撃:盗まれた OAuth トークンについて」や、「NPM の深刻なバグ:不正ライブラリを正規のものとして混入する問題が FIX」のようなインシデントをよく目にします。それに対処するために、4月7日には「Google と GitHub が協力:ソフトウェアの真正性確保によりサプライチェーン攻撃に対抗」という発表がありました。いくつかの試みが並行して走っているようですが、それらが連携して、安心して使えるリポジトリを実現してほしいと思います。なお、Google の SLSA に関しては、2021年6月の「Google が立ち上げる SLSA はサプライチェーンの完全性を護る新たなフレームワークだ」をご参照ください。また、カテゴリ Inventory も、ご利用ください。

%d bloggers like this: