ソフトウェアサプライチェーンセキュリティのアルファとオメガ
アルファ・オメガプロジェクトはオープンソースソフトウェアのセキュリティを改善します。良いスタートですが、それだけでは不十分かもしれません。
アルファオメガプロジェクトとは何ですか？その目的は「オープンソースソフトウェアのサプライチェーンセキュリティを向上させるために、プロジェクトのメンテナと協力して、オープンソースコードにまだ発見されていない新しい脆弱性を体系的に探し、それを修正する」ことです。これはオープンソースセキュリティの向上にとって重要です。
これを実現するために、Linux Foundationのパートナーグループであるオープンソースセキュリティファウンデーション（OpenSSF）、Google、Microsoftが力を合わせて、セキュリティ専門家と協力し、自動化されたセキュリティテストを活用してオープンソースのセキュリティを向上させる。MicrosoftとGoogleは、アルファ・オメガプロジェクトに初期投資として500万ドルを提供する。
ソフトウェアサプライチェーンのセキュリティは不可欠になっています。SolarWindsのソフトウェアサプライチェーン攻撃、Log4jの脆弱性、npmの不正コード挿入事件など、主要なセキュリティ問題はすべてソフトウェアサプライチェーンの脆弱性に起因しています。
ハッカーや国家の敵対者は、広く展開されているオープンソースプロジェクトを主要な標的としています。最近では、新しい脆弱性が公開されると、それが悪用されるまでの時間は数時間の問題です。たとえば、広く使用されているLog4jライブラリの問題は、多くの組織を危機的な状況に追い込み、攻撃される前にアプリケーションを更新するために急いでいました。
問題の別の部分として、ソフトウェアチェーンセキュリティ会社CodeNotaryの製品VPであるジャック・アバウトブルが指摘するのは、この作業のために開発者やメンテイナーに支払うことです。彼は尋ねます："自社のソフトウェアで使用されていることに気づいたが、今まで支払ったことがないオープンソースのメンテイナーに"回答を要求する"というメールを送ったフォーチュン500企業について聞いたことがありますか？私たちは聞きました。そして、それは面白いとは思いませんでした。この話は、ソフトウェア供給チェーンを安全にする方法についての最も明白な真実、すなわちメンテイナーに支払うことを示しています。 OpenSSFが始めたようなプロジェクトやイニシアティブは、オメガソフトウェアのメンテナに支払うための資金が確保されない限り、決して完了することも完全に実現することもありません。それがないと、結果的にはメンテナのコードの穴をさらに見つけることになり、同じ存在しない報酬のために、メンテナが働く時間が減るどころか増えるだけです。
アルファ・オメガプロジェクトは、オープンソースのコードの脆弱性を見つけ、それらが攻撃される前に修正することで、これらすべてをスキップすることを目指しています。彼らの成功を願っています。
アルファ...
アルファは、最も重要なオープンソースプロジェクトのメンテナーと連携します。具体的には、アルファはOpenSSFの重要プロジェクト保護作業部会によって選ばれた、スタンドアロンプロジェクトとコアエコシステムサービスの両方をカバーします。これを実現するために、アルファは専門家の意見とデータの両方を使用します。これには、OpenSSFの重要度スコアやハーバードの「センサス」分析などのオープンソースセキュリティプロジェクトからのデータが含まれます。
これらの選定されたプロジェクトに対して、Alpha チームのメンバーは、セキュリティのギャップを理解し対処するためのカスタマイズされた支援を提供します。これには、脅威モデル作成、自動化されたセキュリティテスト、ソースコード監査、発見された脆弱性の修正支援が含まれます。そのベストプラクティスは、一部は OpenSSF スコアカードおよびベストプラクティスバッジの基準から引き出されます。
...とオメガ
プロジェクトのオメガ側は、まず10,000以上の広く展開されたオープンソースプログラムを特定することから始まります。それが完了したら、プロジェクトのチームはプログラムのコードに対して自動セキュリティ分析とスコアリングを適用します。最後に、オメガのチームはメンテナンスコミュニティに対して修正ガイダンスを提供することでフォローアップします。
これは決して簡単ではありません。オメガは、重要なセキュリティ脆弱性を特定するために、自動化された方法とツールを使用します。これを実現するために、開発者はテクノロジー、クラウド規模の分析、発見を優先するセキュリティアナリスト、そして重要な脆弱性をプログラムのステークホルダーに機密に報告するプロセスの組み合わせを使用します。これを実現するために、オメガは専任のソフトウェアエンジニアチームを使用します。彼らは誤検知率を減少させ、新しい脆弱性を特定するために継続的に取り組むでしょう。
自社のセキュリティチームがあっても、Googleのインフラストラクチャ担当VPでありフェローであるエリック・ブリューワーが指摘したように、「重要なオープンソースソフトウェアのロングテール、この努力の『オメガ』は常に最も難しい部分です—それはかなりの資金と忍耐が必要であり、その規模によって脆弱性を追跡し、理想的には修正するための広範な自動化を促進するでしょう。自動化を可能にすることは、オープンソースのセキュリティにとって最大の改善の一つとなるでしょう。」
「オープンソースソフトウェアは、現代社会の重要なインフラの重要な要素です。したがって、私たちはそれと私たちのソフトウェアサプライチェーンを安全に保つために必要なすべての措置を講じなければなりません。」と、OpenSSFのゼネラルマネージャーであるブライアン・ベールンドルフ氏は述べました。「アルファ・オメガは、脆弱性を積極的に発見し、修正し、防止することでオープンソースプロジェクトのセキュリティを直接向上させることによって、この取り組みをオープンで透明性のある方法で支持しています。」
Microsoft AzureのCTOであるMark Russinovich氏は、「すべてがうまくいけば、Alpha-Omegaは、メンテナーとの直接的な関与を通じて、また最先端のセキュリティツールを使用して重大な脆弱性を検出して修正することにより、主要なオープンソースプロジェクトに保証と透明性を提供します」と述べています。この重要な取り組みについて、業界のパートナーやオープンソースコミュニティと協力できることを楽しみにしています。」
疑問が残る
しかし、これで十分なのでしょうか？アバウトブルはそうは思っていません。技術的に、アバウトブルはアルファ・オメガのシグストア技術（特にコサインとレコール）やその財政的および人員リソースがこの仕事に適していないことを懸念しています。「まず、コサインは証明書と鍵に基づいています - 古代の技術です。もし、数十億のアーティファクトに証明書を使って署名したとしたら、その証明書が侵害された場合はどうなるのでしょうか？あなたはすべての資産の信頼を取り消しに戻りますか？さらに、実際の信頼のルートがどうにかして侵害された場合はどうなるのでしょうか？真剣な質問があり、その答えを見つける必要があります。」
Aboutboulは、プロジェクトの変更不可能で改ざん抵抗のある台帳として意図されているRekorが、その役割を果たすには十分でないのではないかと懸念しています。これは、「Rekorは、その基盤となる追加専用データ構造にGoogleのTrillianを使用し、MySQLまたはMariaDBとRedisが必要です。その結果、脆弱性の余地が生まれます。ここでは動いている要素が多すぎるため、より多くの要素が関与することは、より多くの要素を信頼しなければならないか、実際には信頼する必要がないということを意味します。」
最後に、技術的な側面について、アバウトブルはレコールが「重要: このインスタンスは現在、最善の努力に基づいて運用されています。通知なしにログを削除し、リセットします。時間をかけて安定性を向上させ、SLOを公開します。」と言っていると指摘します。うわっ！
Aboutboulは、オープンソースの不変データベースであるimmudbに依存することによって、これらの問題に対処しています。なぜでしょうか？CodeNotaryは「immudb自体が不変データベースであり、外部のインフラストラクチャに依存していないため、疑念の余地はなく、リスクの余地もありません。immudbに入るものは、改ざん防止と検証可能な方法でimmudbに保存されます。」と言っています。
技術の他に、アバウブルは対処する必要があると考える二つの重要な問題があります。第一に、「500万ドルという金額は多くのように聞こえます（実際そうですが）、この使命を実行するには取るに足らない額のように思えます。オープンソースがグローバルなソフトウェア供給チェーンに深く浸透していることは圧倒的です。例えば、Linuxカーネルなど、潜在的なアルファプロジェクトを検討し始めると、その努力だけでほぼ全ての資金を使い果たす可能性があります。それでは、すべてのオメガプロジェクトにどうやってアクセスしますか？」
とはいえ、アバウトブルはアルファ・オメガが良い大きな前進であることに同意しています。しかし、アバウトブルはいくつかの優れたポイントを指摘しています。結局のところ、ここでの大問題は開発者やメンテナンス担当者へのお金です。好きか嫌いかにかかわらず、オープンソースのセキュリティに対する支払いを優先する必要があります。