日本や世界では人種差別による同化政策によって、いまも2週間にひとつの割合で先住民族の言語が死に絶えている。そんななかニュージーランドのマオリ語の放送局は、貴重な音声データをビッグテックやグローバル企業に明け渡すのではなくマリオの人々のために役立てようと、独自に機械学習による自動音声認識ツールの開発に乗り出している。いまや言語の再生と復興に力を注ぐ他の先住民コミュニティにも拡がる音声データの「脱植民地化」を追う。
…
Would the math work if Databricks were valued at $38B?
Databricks, the open-source data lake and data management powerhouse has been on quite a financial run lately. Today Bloomberg reported the company could be raising a new round worth at least $1.5 billion at an otherworldly $38 billion valuation. That price tag is up $10 billion from its last fundraise in February when it snagged […]
Webiny nabs $3.5M seed to build serverless development framework on top of serverless CMS
Webiny, an early-stage startup that launched in 2019 with an open-source, serverless CMS, had also developed a framework to help build the CMS, and found that customers were also interested in that to help build their own serverless apps. Today, Webiny announced a $3.5 million seed round to continue developing both pieces. Microsoft’s venture fund […]
The Perl Foundation is fragmenting over Code of Conduct enforcement
“I’m fresh out of ideas with regards to handling toxicity in the Perl community.”
Stingle is a privacy-focused, open source photo backup application
The mobile app encrypts your photos before uploading them to the cloud.
Software downloaded 30,000 times from PyPI ransacked developers’ machines
Expect to see more of these “Frankenstein” malware packages, researchers warn.
Summit invests $215M into Odoo, an open-source business management software developer, at a $2.3B+ valuation
Odoo is the first unicorn out of Wallonia, the region in Belgium where it is based.
オープンソース ソフトウェアのセキュリティ リスクを測定する: Scorecards の V2 をリリース
この記事は Google Open Source Security チーム、Kim Lewandowski、Azeem Shaikh、Laurent Simon による Google Online Security Blog の記事 “Measuring Security Risks in Open Source Software: Scorecards Launches V2” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
オープンソース プロジェクトの「リスクスコア」を生成する自動セキュリティ ツール、Scorecards プロジェクトの貢献者の皆さんは、昨秋のリリース以降、たくさんのことを成し遂げています。この度は、Open Source Security Foundation コミュニティとともに、Scorecards v2 についてお知らせします。新しいセキュリティ チェックを追加して評価対象のプロジェクト数を拡大し、そのデータを簡単に分析できるようにしています。
現在、多くのソフトウェアがオープンソース プロジェクトを利用しています。そのため、依存関係が安全かどうかを簡単に判断する方法が必要です。Scorecards は、プロジェクトのサプライ チェーンを管理する際に、変化を続けるパッケージを継続的に評価するために必要な煩雑さや手作業を軽減するために役立ちます。ユーザーは、依存関係がもたらすリスクを自動的に評価し、そのデータを使って情報に基づいてリスクを受け入れるかどうかを判断したり、代替のソリューションを評価したり、メンテナンス担当者と協力して改善したりできます。
リスクの特定
昨秋より、Scorecards のカバレッジは拡大しています。Google が今年提唱した Know、Prevent、Fix フレームワークに従って優先順位付けをし、いくつかの新しいチェックを追加しました。
悪意のある貢献者
悪意のある貢献者や侵害されたアカウントによって、コードに潜在的なバックドアが紛れ込む可能性があります。こうした攻撃は、コードレビューによって軽減できます。新しい Branch-Protection チェックを使うと、プロジェクトでコードをコミットする前に別のデベロッパーによるコードレビューを必須にすることができます。GitHub API の制限のため、現在、このチェックはリポジトリ管理者のみが実行できます。サードパーティ リポジトリの場合は、これよりも情報が少ない Code-Review チェックを代わりに利用できます。
脆弱なコード
デベロッパーやピアレビューの最大限の努力にもかかわらず、脆弱なコードがソース コントロールに紛れ込み、検出されないままになることがあります。そのため、継続的にファジングや静的コード解析をし、開発ライフサイクルの早い段階でバグを発見できることが重要です。そこで、CI/CD システムの一部として、プロジェクトがファジングや SAST ツールを使っているかどうかを検出するチェックを追加しました。
ビルドシステムの侵害
GitHub プロジェクトで一般的に使われる CI/CD ソリューションは、GitHub Actions です。このアクション ワークフローの危険なところは、信頼できないユーザー入力を扱ってしまう可能性があることです。つまり、攻撃者は悪意のある pull リクエストを作成することで、特権 GitHub トークンにアクセスし、それを使ってレビューを経ずに悪意のあるコードをリポジトリにプッシュすることができます。Scorecard の Token-Permissions 防止チェックは、このリスクを緩和するため、GitHub トークンをデフォルトで読み取り専用にし、GitHub ワークフローが最小権限の原則に従っていることを検証します。
悪質な依存関係
どんなソフトウェアでも、依存関係が弱いほど安全です。これは当たり前に思えるかもしれませんが、依存関係を知るための第一歩は、依存関係を宣言し、その依存関係にも依存性を宣言させることです。この起源情報があれば、ソフトウェアのリスクを評価し、そのリスクを低減できます。残念ながら、よく目にするアンチパターンがいくつかあり、それによってこの起源の原則が崩れています。1 つ目のアンチパターンは、バイナリのチェックインです。プロジェクト内のバイナリ コンテンツを簡単に検証またはチェックする方法はないからです。Scorecards は、これを評価する Binary-Artifacts チェックを提供します。
もう 1 つのアンチパターンは、スクリプトで curl | bash を使って動的に依存関係をプルすることです。暗号化ハッシュを使うと、依存関係を既知の値に固定することができます。その値が変更されると、ビルドシステムはそれを検知してビルドを拒否します。依存関係がある場合、依存関係の固定は便利です。これはコンパイル時だけでなく、Dockerfiles や CI/CD ワークフローなどにも当てはまります。Scorecards は、Frozen-Deps チェックによってこのアンチパターンをチェックします。このチェックは、最近の CodeCov 攻撃のような悪意のある依存関係攻撃を軽減する際に役立ちます。
ハッシュを固定したとしても、依存関係で脆弱性の修正が発生すると、ハッシュを更新する必要があります。dependabot や renovatebot といったツールは、ハッシュの確認と更新をする機会を与えてくれます。Scorecards の Automated-Dependency-Update チェックは、デベロッパーがそのようなツールを使って依存関係を更新していることを検証します。
重要なのは、依存関係として取り込む前に、そのプロジェクトの脆弱性を把握することです。Scorecards の新しい Vulnerabilities チェックでは、脆弱性アラート システムをサブスクライブしなくても、この情報が提供されます。
影響力の拡大
現時点で、Scorecards プロジェクトは、50,000 を超えるオープンソース プロジェクトのセキュリティ基準を評価する規模になっています。このプロジェクトを拡大するため、アーキテクチャの大幅な再設計をし、水平スケーラビリティと高いスループットを実現する PubSub モデルを採用しました。この全自動ツールでは、定期的に重要なオープンソース プロジェクトを評価し、毎週更新されるパブリック BigQuery データセットを通して Scorecards チェック情報を公開しています。
このデータは、bq コマンドライン ツールで取得できます。次の例は、Kubernetes プロジェクトのデータをエクスポートする方法を示しています。リポジトリの URL を置き換えると、別のプロジェクトのデータをエクスポートできます。
|
$ bq query –nouse_legacy_sql ‘SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo=”github.com/kubernetes/kubernetes”‘ |
分析対象となるすべてのプロジェクトの最新データをエクスポートしたい方は、こちらの手順をご覧ください。
インターネットはどの程度基準を満たしているか
対象プロジェクトの Scorecards データは、最近発表された Google Open Source Insights プロジェクトに含まれており、OpenSSF Security Metrics プロジェクトでも公開されています。これらのサイトのデータからは、Kubernetes などの広く使われているパッケージであっても、埋める必要がある重要なセキュリティ ギャップがまだ存在することがわかります。
また、Google のデータ分析・視覚化ツールの 1 つである Google データポータルで Scorecards データを分析してみました。次の図は、実行されたチェックと、50,000 個のリポジトリに対する合格 / 失格の結果の内訳です。
ご覧のように、これらの主要プロジェクトのセキュリティを向上するには、たくさんの作業が必要です。多くのプロジェクトには、継続的なファジングが行われていない、脆弱性報告のセキュリティ ポリシーが定義されていない、依存関係が固定されていないなどの問題があり、これらは一般的な問題のごく一部にすぎません。業界が一丸となってこういった幅広いセキュリティ リスクへの認識を高め、すべての人に利益をもたらすような改善をする必要があります。
実際の Scorecards
いくつかの大規模プロジェクトが Scorecards を採用し、その経験について継続的にフィードバックを行っています。以下に、実際に Scorecards を使った例をご紹介します。
Envoy
以前、Envoy のメンテナンス担当者がプロジェクトに Scorecards を採用し、それを新しい依存関係を導入する際のポリシーに組み込んだ過程についてお話ししました。それ以降、新しい依存関係を Envoy に導入する pull リクエストは、依存関係のメンテナンス担当者からの承認が必要になりました。担当者は Scorecards を使い、一連の基準に照らして依存関係を評価します。
以前、Envoy のメンテナンス担当者がプロジェクトに Scorecards を採用し、それを新しい依存関係を導入する際のポリシーに組み込んだ過程についてお話ししました。それ以降、新しい依存関係を Envoy に導入する pull リクエストは、依存関係のメンテナンス担当者からの承認が必要になりました。担当者は Scorecards を使い、一連の基準に照らして依存関係を評価します。
それに加えて、Envoy は独自の Scorecards 評価に基づいて専用のセキュリティ健全性指標を改善する作業にも着手し、現在は C++ の依存関係を固定し、Python の依存関係には pip ハッシュを要求しています。さらに、継続的インテグレーション フローで Github のアクションも固定しています。
以前、Envoy は依存関係についての Scorecards データを CSV として出力するツールを作成し、その結果から表を作成していました。
現在はプロジェクトのデータが増えましたが、Envoy では依存関係についての最新の Scorecard 情報を自動生成し、次のようなドキュメントで公開できるようになっています。
Scorecards
Scorecards 自体のスコアも改善しました。たとえば、CodeCov スタイルの攻撃を防ぐため、依存関係をハッシュで固定するようにしました（Docker 依存関係、ワークフロー依存関係など）。また、この推奨テンプレートに基づいてセキュリティ ポリシーも含めました。
参加する
Scorecards コミュニティが拡大を続けるのを楽しみにしています。現在、このプロジェクトは 23 名のデベロッパーの貢献を受けています。Scorecards の新機能やスケーリングの作業を行ってくださった Azeem、Naveen、Laurent、Asra、Chris に感謝します。
この楽しい作業に参加したい方は、初めての方向けの Issue をご確認ください。
特定のプロジェクトで Scorecards を実行する際にサポートを受けたい方は、GitHub で pull リクエストを送り、こちらにプロジェクトを追加してください。
最後になりますが、私たちにはさまざまなアイデアがあり、追加したいチェックもさらにたくさんありますが、ぜひ皆さんの意見を聞きたいと思っています。Scorecards の次のバージョンで期待するチェックをお知らせください。
次のステップ
次に示すのは、私たちが特に期待している大きな拡張です。
- Scorecards バッジ – コンプライアンスを証明する GitHub バッジ
- CI/CD および GitHub コードスキャン結果との統合
- Allstar プロジェクトとの統合 – セキュリティ ポリシーを強制するための GitHub アプリ
このプロジェクトの成功に貢献してくださった Scorecards コミュニティと OpenSSF の皆さんに改めてお礼を申し上げます。メンテナンスしているプロジェクトで Scorecards を採用しスコアを改善したという方は、ぜひお知らせください。次にお会いするときまで、ぜひスコアの改善を続けてください！
Reviewed by Eiji Kitamura – Developer Relations Team<!—->
オープンソースの統合脆弱性スキーマのご紹介
この記事は 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 をいくつかの主要なオープンソース エコシステムに展開するための新たなマイルストーンをお知らせします。その対象となるのは、Go、Rust、Python、DWF です。この展開により、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 などの脆弱性と、パッケージ マネージャーのパッケージ名や一連のバージョンを自動的に照合することは困難。
- どんなオープンソース エコシステムの脆弱性も記述でき、エコシステムの独自ロジックがなくても処理できる。
- 自動システムにも人間にも使いやすい。
このスキーマが、すべての脆弱性データベースをエクスポートできる形式の定義となることを期待しています。一元的に利用できる形式があるということは、脆弱性データベース、オープンソース ユーザー、セキュリティ研究者が簡単にツールを共有し、オープンソース全体の脆弱性情報を利用できるということです。つまり、誰でもオープンソースの脆弱性を完全に把握でき、簡単に自動化も行えるので、検知や修正にかかる時間も短くなります。
現状
脆弱性スキーマの仕様は何度かの反復を経ており、最終版に近づくにあたって、さらなるフィードバックを求めています。現在、たくさんのパブリックな脆弱性データベースがこの形式でエクスポートできるようになっており、さらに多くのデータベースで作業が進行中です。
- Go パッケージの Go 脆弱性データベース
- Cargo パッケージの Rust アドバイザリ データベース
- PyPI パッケージの Python アドバイザリ データベース
- Linux カーネルやその他の一般的なソフトウェアの脆弱性の DWF データベース
- OSS-Fuzz で発見された C/C++ ソフトウェアの脆弱性の OSS-Fuzz データベース
OSV サービスもこれらすべての脆弱性データベースの集約をしており、ウェブ UI から参照できます。同じ既存 API を使い、コマンド 1 つで照会することもできます。
|
curl –X POST –d \ ‘{“commit”: “a46c08c533cfdf10260e74e2c03fa84a13b6c456”}’ \ “https://api.osv.dev/v1/query”
curl –X POST –d \ ‘{“version”: “2.4.1”, “package”: {“name”: “jinja2”, “ecosystem”: “PyPI”}}’ \ “https://api.osv.dev/v1/query” |
脆弱性データベースのメンテナンスの自動化
質の高い脆弱性データを作るのも困難な作業です。OSV ではすでに自動化が行われていますが、それに加えて、脆弱性データベースをメンテナンスするための自動化ツールを構築し、そのツールをコミュニティの Python アドバイザリ データベースの作成に役立てました。この自動処理では、既存のフィードを受け取り、パッケージと正確に照合し、検証済みの正確なバージョン範囲を含むエントリを生成します。人間の介入は最低限にとどめられています。このツールは、既存の脆弱性データベースが存在しないエコシステムや、継続的なデータベースのメンテナンスがほとんどサポートされていないエコシステムにも展開する予定です。
参加する
この形式についてフィードバックを提供し、この形式を採用してくれた、すべてのオープンソース デベロッパーに感謝します。今後もオープンソース コミュニティと連携し、さらに開発を進めるとともに、すべてのエコシステムに広く採用を促してゆきたいと思います。この形式の採用に興味がある方は、公開仕様へのフィードバックをお願いいたします。
Reviewed by Eiji Kitamura – Developer Relations Team<!—->