Google は、検証済みの ID、コードレビュー、信頼できるビルドなどの要素に基づいてオープンソースのセキュリティを議論し、対処するためのフレームワークを提案しましたが、そのアプローチはオープンソース文化と相容れない可能性があります。
オープンソースソフトウェアのセキュリティは、インターネットの大部分が動作するLinuxカーネルから、開発者から隠された依存関係の連鎖を介して数百万ものウェブアプリケーションに組み込まれる小さなJavaScriptライブラリに至るまで、広く採用されているため、極めて重要です。最近発見されたsudoユーティリティのような脆弱性は、数百万ものシステムに影響を与えています。
Google のチームは、「オープンソース ソフトウェアのセキュリティに関する業界全体の議論と進歩を促進する」ことを期待して、この問題について長々と投稿しました。
「知る、予防する、修正する」と題されたこの投稿は、Google のインフラストラクチャ担当副社長 Eric Brewer、著名なエンジニア Rob Pike (Go 言語の共同設計者)、主席ソフトウェア エンジニア Abhishek Arya、オープンソース セキュリティのプログラム マネージャー Anne Bertucio、および製品マネージャー Kim Lewandowski が共同執筆しています。
Linux界のsudoに存在する10年前のバグは、ログインしたユーザーなら誰でもルート権限を取得できる可能性がある。
続きを読む
また、Google は、GitHub、GitLab、Intel、IBM、Microsoft、NCC Group、OWASP、Red Hat、VMware など多くの企業とともに、Linux Foundation の OpenSSF (Open Source Security Foundation) の創設メンバーでもあります。
新しい投稿では、OpenSSF の取り組みの一部、特にコード レビュー、静的分析、テストの使用、セキュリティ ポリシーの存在など、さまざまな基準に従ってプロジェクトのセキュリティを評価する自動ツールであるセキュリティ スコアカードについて言及しています。
Googleは、「オープンソースソフトウェアは、コードと依存関係がすべて公開されており、検査や検証が可能なため、セキュリティ面でのリスクは低いはずだ」と示唆したが、これは人々が「実際に見ている」場合にのみ当てはまると指摘した。
依存関係の問題により、数千ものパッケージが使用されており、そのセキュリティを把握することが困難になっています。「脆弱性の大部分に対処するには、根本的な変更に注力する必要があります」とチームは主張しました。
Googleは、一般的なオープンソースのリポジトリやパッケージマネージャーを完全に信頼していないことが判明しました。同社は「社内で使用しているすべてのオープンソースパッケージのプライベートリポジトリを保有していますが、すべてのアップデートを追跡するのは依然として困難です」と説明されています。
同社はこれを自動化するためのより優れたツールを模索している。この文書は、ソフトウェア業界全体の協力なしにはこれらの標準はほとんどの組織にとって実現不可能であることを認識した上で、同社自身の社内慣行に基づいているようだ。
同社の提案にはいくつかの詳細が含まれており、アイデアの一部は重要に分類されるオープンソース ソフトウェアのみを対象としていることが指摘されている。
- 脆弱性データベースの標準スキーマ。これにより、ツールが業界全体のデータをより適切に理解できるようになり、自動化が容易になります。
- 脆弱性が実際に発見された場合の通知システム。
- 重要なオープンソース ソフトウェアには、2 つの独立した当事者によるコードのレビューと承認なしには変更が加えられないこと。
- 重要なソフトウェアプロジェクトの所有者とメンテナーは匿名ではなく、公開または信頼できる機関を通じて検証済みのIDを持ち、2FAなどの強力な認証を使用していること。チームは、IDのための連合モデルの開発を提案しています。
- 重要なソフトウェアについては、Google 自身が Trillian で提案したようなソフトウェア パッケージと成果物の改ざんチェックを行います。
- 重要なソフトウェアの場合、ビルド サービスを提供してコンパイルされたパッケージに署名する信頼できるエージェントを備えた、証明済みのビルド システムが必要になります。
Google チームは、重要なソフトウェアに対する目標は「より面倒なものとなり、ある程度の抵抗に遭遇するだろうが、追加の制約はセキュリティにとって基本的なものだと信じている」と認めた。
頑張ってください、Google
Googleの提案は、ソフトウェアの脆弱性の仕組みと理由を徹底的に検討した結果と言えるでしょう。しかし、オープンソース文化の規範からは大きくかけ離れているようにも感じられます。提案された基準は、オープンソースプロジェクトの進行を遅らせ、官僚主義化を招き、プロジェクトを推進する意欲的な人々の一部を疎外することなく、プロジェクトに適用できるのでしょうか？
昨年のゼロデイ攻撃の4分の1は、不適切なソフトウェアセキュリティパッチが原因だった
続きを読む
「libpng、libjpeg-turbo、openssl、ffmpeg などのさまざまなプロジェクトのリーダーたちに、FOSS の世界で重要なソフトウェアであるという理由だけで、自分のプロジェクトに『一方的な』変更を加えることは許可されないと伝えてみてください」と、提案に対するコメントの 1 つに書かれていた。
また、より中立的な環境である OpenSSF のコンテキストで共同論文を作成するのではなく、Google が自社のオープンソース ブログにこの提案を掲載することを選択したのも、ある意味奇妙に思えますが、もちろん、このような結果になる可能性もあります。
Googleの提案は、先週OpenSSFの技術ビジョンで提示されたアイデアよりも厳格であるように思われます。これらのアイデアは、開発者が安全なコードを書きやすくすることに重点を置いています。しかし、SolarWindsへの攻撃では、侵害されたビルド環境が悪意のあるコードを挿入するために利用されましたが、Linux Foundationのオープンソース・サプライチェーン・セキュリティ担当ディレクターであるDavid Wheeler氏は、ビルド環境の強化について投稿し、Googleの懸念の一部を反映しています。
問題は、オープンソースの使用がセキュリティにどのような影響を与えるかだけでなく、セキュリティの要件がオープンソースにどのような影響を与えるかということです。®
