Ticker

6/recent/ticker-posts

Header Ads Widget

オープンソースの統合脆弱性スキーマのご紹介

この記事は Google Open Source Security チーム、Oliver Chang、Go チーム、Russ Cox による Google Online Security Blog の記事 "Announcing a unified vulnerability schema for open source" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google はここ数か月の間に、さまざまな側面からオープンソース セキュリティを強化するため、いくつかの取り組みを始めました。その重点領域の 1 つに、広範な手作業をすることなく、既知のセキュリティ脆弱性を特定し、それに対応する方法を改善することがあります。セキュリティ脆弱性に優先順位を付けて対応するには、正確な共通データ形式が欠かせません。特に、影響が及ぶ依存性にリスクを伝える場合にはそれが当てはまります。これにより、自動化が簡単になり、オープンソース ソフトウェアの利用者は、影響を受けるときに通知を受け取ったり、できる限り早くセキュリティの修正をしたりできるようになります。

2 月には、オープンソース ソフトウェアのデベロッパーとユーザーが脆弱性の優先順位付けの自動化や改善を行えるように、Open Source Vulnerabilities(OSV)データベースをリリースしました。この最初の取り組みは、OSS-Fuzz プロジェクトによる数千の脆弱性のデータセットを使用して行われました。OSV を実現して数百の重要なオープンソース プロジェクトに正確な脆弱性データを伝えることで、この形式の成功と実用性が証明され、プロジェクトの改善に役立つフィードバックが得られました。たとえば、Cloud API キー要件を取り下げたことで、多くのユーザーがさらに簡単にデータベースを使えるようになりました。コミュニティの反応からも、この取り組みをさらに進めることへの幅広い関心が感じられました。

この度、OSV をいくつかの主要なオープンソース エコシステムに展開するための新たなマイルストーンをお知らせします。その対象となるのは、GoRustPythonDWF です。この展開により、4 つの重要な脆弱性データベースが 1 つに集約されるので、ソフトウェア デベロッパーが影響を受けるセキュリティ問題を追跡したり、それに対応したりする処理が改善されます。この取り組みは、最近の国家サイバーセキュリティ向上に関する米国大統領令とも一致します。この大統領令では、国家インフラストラクチャを強固にするため、脅威情報を共有するにあたっての障壁を取り除く必要性が強調されています。今回の共有脆弱性データベースの展開は、すべてのユーザーにとってより安全なオープンソース環境の構築に向けた重要な一歩です。
 
脆弱性を正確に記述するシンプルな統合スキーマ

オープンソース開発と同じように、オープンソース脆弱性データベースも分散モデルに従っており、多くのエコシステムや組織が独自のデータベースを作成しています。それぞれが独自のフォーマットで脆弱性を記述しているので、複数のデータベースの脆弱性を追跡するクライアントは、それぞれのデータベースをまったく別々に扱う必要があります。そのため、データベース間で脆弱性を共有するのも困難です。

Google Open Source Security チームと Go チーム、そして幅広いオープンソース コミュニティは、脆弱性を記述するシンプルな脆弱性交換スキーマを開発しています。これは、オープンソース エコシステム向けに一から設計されたものです。数か月前にこのスキーマに着手した後、パブリック フィードバックをリクエストし、たくさんのコメントをいただきました。その意見を反映した結果が、現在のスキーマです。

{

        "id": string,

        "modified": string,

        "published": string,

        "withdrawn": string,

        "aliases": [ string ],

        "related": [ string ],

        "package": {

                "ecosystem": string,

                "name": string,

                "purl": string,

        },

        "summary": string,

        "details": string,

        "affects": [ {

                "ranges": [ {

                        "type": string,

                        "repo": string,

                        "introduced": string,

                        "fixed": string

                } ],

                "versions": [ string ]

        } ],

        "references": [ {

                "type": string,

                "url": string

        } ],

        "ecosystem_specific": { see spec },

        "database_specific": { see spec },

}



この新しい脆弱性スキーマでは、オープンソースで脆弱性を管理するうえで、いくつかの重要な問題に対処することを目指しています。以下を満たす既存の標準形式は存在しないことがわかっています。

  • 実際のオープンソース パッケージ エコシステムのネーミングやバージョニングのスキームに厳密に一致するバージョン指定を強制する。たとえば、CPE などの既存のメカニズムでは、CVE などの脆弱性と、パッケージ マネージャーのパッケージ名や一連のバージョンを自動的に照合することは困難。
  • どんなオープンソース エコシステムの脆弱性も記述でき、エコシステムの独自ロジックがなくても処理できる。
  • 自動システムにも人間にも使いやすい。

このスキーマが、すべての脆弱性データベースをエクスポートできる形式の定義となることを期待しています。一元的に利用できる形式があるということは、脆弱性データベース、オープンソース ユーザー、セキュリティ研究者が簡単にツールを共有し、オープンソース全体の脆弱性情報を利用できるということです。つまり、誰でもオープンソースの脆弱性を完全に把握でき、簡単に自動化も行えるので、検知や修正にかかる時間も短くなります。

現状


脆弱性スキーマの仕様は何度かの反復を経ており、最終版に近づくにあたって、さらなるフィードバックを求めています。現在、たくさんのパブリックな脆弱性データベースがこの形式でエクスポートできるようになっており、さらに多くのデータベースで作業が進行中です。
OSV サービスもこれらすべての脆弱性データベースの集約をしており、ウェブ UI から参照できます。同じ既存 API を使い、コマンド 1 つで照会することもできます。

  curl -X POST -d \

      '{"commit": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"}' \

      "https://ift.tt/3gUbSRu"

    

  curl -X POST -d \

      '{"version": "2.4.1", "package": {"name": "jinja2", "ecosystem": "PyPI"}}' \

      "https://ift.tt/3gUbSRu"



脆弱性データベースのメンテナンスの自動化


質の高い脆弱性データを作るのも困難な作業です。OSV ではすでに自動化が行われていますが、それに加えて、脆弱性データベースをメンテナンスするための自動化ツールを構築し、そのツールをコミュニティの Python アドバイザリ データベース作成に役立てました。この自動処理では、既存のフィードを受け取り、パッケージと正確に照合し、検証済みの正確なバージョン範囲を含むエントリを生成します。人間の介入は最低限にとどめられています。このツールは、既存の脆弱性データベースが存在しないエコシステムや、継続的なデータベースのメンテナンスがほとんどサポートされていないエコシステムにも展開する予定です。


参加する


この形式についてフィードバックを提供し、この形式を採用してくれた、すべてのオープンソース デベロッパーに感謝します。今後もオープンソース コミュニティと連携し、さらに開発を進めるとともに、すべてのエコシステムに広く採用を促してゆきたいと思います。この形式の採用に興味がある方は、公開仕様へのフィードバックをお願いいたします。

Reviewed by Eiji Kitamura - Developer Relations Team


source https://developers-jp.googleblog.com/2021/07/blog-post.html

Post a Comment

0 Comments