Data Cloud Summit セッション内容を公開しました

Data Cloud Summit 本登録開始Data Cloud Summit は、データ駆動型のビジネスへの変革に不可欠な、データ分析・基盤ソリューションに特化したオンライン セミナーです。本イベントでは、BigQuery、Cloud Spanner など Google Cloud のデータ分析・データベース製品の最新情報、製品 Deep Dive のセッションを Google Cloud のエンジニアがお届けします。そして、お客様セッションでは、NTT コミュニケーションズ株式会社、デサントジ…

HTTPS の採用を増やすために

この記事は Google Chrome チーム、Shweta Panditrao、Devon O’Brien、Emily Stark による Chromium Blog の記事 “Increasing HTTPS adoption” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ブラウザが（HTTP でなく）HTTPS でウェブサイトに接続すると、ネットワーク上の盗聴者や攻撃者は、その接続で共有されるデータ（個人情報やそのページ自体など）を傍受したり改変したりできなくなります。ウェブのエコシステムにとって、このレベルのプライバシーとセキュリティは不可欠です。そのため、Chrome では HTTPS のサポートを広げるための取り組みを継続しています。
ありがたいことに、HTTPS の採用はここ数年で大幅に増加しています。また、ほとんどのオペレーティング システムで、Chrome が読み込むページの 90% 以上が HTTPS になっています。しかし、HTTPS をウェブの優先プロトコルにし、HTTPS をサポートしていない残りのウェブでユーザーの保護を強化するために、まだできることがあります。そこで今回は、この領域での今後の作業についてお知らせします。

HTTPS ファーストの世界をオプトインする

M94 以降の Chrome は HTTPS ファースト モードを提供します。このモードでは、すべてのページ読み込みが HTTPS にアップグレードされ、HTTPS をサポートしないサイトを読み込む際には、ページ全体に警告が表示されます。このモードを有効にすると、可能な場合には常に HTTPS でサイトに接続し、HTTP でサイトに接続する前には警告が表示されることが保証されます。エコシステムからのフィードバックに基づき、将来的には、すべてのユーザーで HTTPS ファースト モードをデフォルトにする予定です。Mozilla も、将来的に Firefox のウェブ ブラウジングを HTTPS 専用モードにする予定であることを発表しました。

鍵アイコンの実験

HTTPS ファーストの未来に向かうにあたり、ブラウザがサイトを HTTPS で読み込んでいることを示すために使われることが多い鍵アイコンの再検討も行っています。とりわけ、Google の調査によると、実際に安全なのは接続のみであるにもかかわらず、ユーザーはこのアイコンを信頼できるサイトとみなすことがわかっています。最近の調査では、鍵アイコンの意味を正しく認識できたのは、回答者の 11% だけでした。Chrome の M93 では、この混乱を減らすための試みとして、アドレスバーの鍵アイコンをこれまでよりも中立的なページ情報の入口に置き換える実験をする予定です（下の例を参照）。この実験により、重要なプライバシーとセキュリティの情報や、ページ情報で提供されるコントロール（サイトのパーミッションなど）が見つけやすくなることを期待しています。重要なのは、HTTPS がサポートされていないサイトで「保護されていない通信」のインジケーターが表示される点は変わらないことです。また、この実験には、オプトアウトを希望する組織のためのエンタープライズ ポリシーも含まれています。いずれの場合も、全面的にリリースを行う場合は、事前にお知らせします。

HTTP ウェブのユーザーを保護する

今後のバージョンの Chrome でユーザーが HTTPS ファースト モードを採用することを楽しみにしていますが、その一方で、Chrome の HTTP 接続のサポートを継続し、安全でない接続を使用しているときに常にユーザーを保護して通知をするための追加策を実施します。新機能を安全なオリジンに限る、安全でないオリジンで充実した機能を使えなくするといったこれまでの取り組みの続きとして、ウェブ プラットフォームのさまざまな機能を評価して HTTP ウェブページで制限すべきかどうかを判断する作業に着手する予定です。

ユーザーに最大限のセキュリティ強化を提供する変更に注力できるように、この領域で今後優先する作業は、以下の原則に従って判断します。

  • 安全でない接続を利用するサイトを、信頼するかどうか判断する際の情報提供を強化する
  • 安全でない接続では、サイトでセキュリティ ポリシーをオプトアウトできないように制限する
  • 安全でない接続で提供されたサイトのコンテンツを Chrome が保存する方法や期間を制限する

この原則に基づく行動予定の詳しい説明や、影響を受ける機能リストの改訂版は、Chromium Wiki で管理されています。また、今年中にさらに詳しい情報をお伝えする予定です。

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

オープンソース ソフトウェアのセキュリティ リスクを測定する: 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 評価に基づいて専用のセキュリティ健全性指標を改善する作業にも着手し、現在は 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 コミュニティと OpenSSF の皆さんに改めてお礼を申し上げます。メンテナンスしているプロジェクトで Scorecards を採用しスコアを改善したという方は、ぜひお知らせください。次にお会いするときまで、ぜひスコアの改善を続けてください！

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

Google 広告でスタンドアロン Gmail キャンペーンが読み取り専用に

この記事は Mike Cloonan による Google Ads Developer Blog の記事 “Standalone Gmail campaigns becoming read only in Google Ads” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。2021 年 7 月 8 日より、すべてのスタンドアロン Gmail キャンペーンが読み取り専用になりました。この日以降、新しいキャンペーンの作成、または既存キャンペーンでの広告グループの作成はできなくな…

アセットベースの拡張機能: 可用性の更新と新しい ValueTrack パラメータ

この記事は Andrew Burke による Google Ads Developer Blog の記事 “Asset-based Extensions: Updated Availability and new ValueTrack Parameter” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


以前にお知らせしたように、すべての広告拡張機能は新しいアセットベースの拡張機能に移行します。そのため、実装の拡張機能サポートをアップデートして、既存のフィードベースの拡張機能をアセットベースの拡張機能に移行する必要があります。提供終了に関する重要な日付については、移行スケジュールをご覧ください。

変更内容

現在、以下のアセットベースの拡張機能タイプがすべてのアカウントで利用できます。

Google Ads API のアセットベースのイメージ拡張機能は、当初は今年中にリリースするスケジュールでしたが、2022 年まで利用できない見込みとなりました。利用できるようになった際には、フィードベースのイメージ拡張機能の提供終了タイムラインをアップデートしたものを、このブログと拡張機能移行ドキュメントで公開します。

なお、新しい {extensionid} ValueTrack パラメータは、2021 年 6 月 24 日から利用できるようになりました。このパラメータを使うと、アセットベースの拡張機能でクリックを追跡できます。アセットベースの拡張機能の {extensionid} パラメータは、既存のフィードベースの拡張機能の {feeditemid} パラメータの動作と同じです。

必要になる作業

自分のアカウントのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能を、Google Ads API を利用してアセットベースの拡張機能に移行してください。今後も拡張機能を変更できるように、この作業はできる限り早く行うことをお勧めします。2021 年 10 月 20 日に、コールアウト、プロモーション、サイトリンク、構造化スニペットのフィードベースの拡張機能はアセットベースの拡張機能に自動的に移行されます。近日中に、Google 広告クライアント アカウント単位でオプトアウトをし、この自動移行の対象から外せるようになります。オプトアウトのプロセスが利用できるようになったときは、このブログでお知らせします。最新の関連情報は、拡張機能移行ガイドをご覧ください。なお、AdWords API ではアセットベースの拡張機能がサポートされない点に注意してください。

作成した任意のアセットベースの拡張機能で、クリックを追跡する {extensionid} ValueTrack パラメータを利用できるようになっています。{feeditemid} パラメータはアセットベースの拡張機能のクリックには適用されません。また、{extensionid} はフィードベースの拡張機能のクリックには適用されません。クリックの原因を正しく確認できるように、現在 {feeditemid} ValueTrack パラメータを利用している URL をアップデートし、新しい {extensionid} ValueTrack パラメータも含める必要があります。つまり、同じ URL に {feeditemid} と {extensionid} の両方を設定します。ただし、クリックのソースに基づいて、どちらか片方のみにデータが入ることになります。

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

– Google Ads API チーム、Andrew Burke
Reviewed by Thanet Knack Praneenararat – Ads Developer Relations Team

<!—->

Google 広告の絞り込み部分一致の変更予定について

この記事は  David Wihl による Google Ads Developer Blog の記事 “Broad match modifier upcoming changes in Google Ads” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。2021 年 2 月 4 日に、フレーズ一致と絞り込み部分一致（BMM）の変更についてお知らせしました。この投稿で説明したように、現時点で、すべての Google 広告の言語がアップデートされ、新しい…

WordPress で AMP を使って簡単に優れたページ エクスペリエンスを実現する方法

この記事は Alberto Medina による The AMP Blog の記事 “An Easier Path to Great Page Experiences Using AMP for WordPress” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Core Web Vitals という取り組みの目的は、ウェブで優れたユーザー エクスペリエンスを実現するうえで欠かせない品質シグナルに関するガイドを一元的に提供することです。Core Web Vitals は、Google が新しいページ エクスペリエンス ランキング シグナルを計測する際の土台です。これにより、Google 検索で使われる一連のランキング要素に、ユーザー エクスペリエンスが加わることになります。

優れたページ エクスペリエンスの基準を満たすサイトを構築して管理するには、さまざまな要素を考慮して対応することが必要です。サイトオーナーは、測定ツールや自動化ツールの機能を活用してガイドやサポートを得ることができます。サイトの Core Web Vitals を計測するさまざまなツールがあります。また、AMP などの他のツールでも、すぐに使える幅広いパフォーマンス最適化やベスト プラクティスが用意されているので、パフォーマンスのよいウェブサイトを簡単に構築するうえで役立ちます。WordPress プラットフォームを使ってコンテンツを作成、公開している方なら、WordPress の公式 AMP プラグインを使うと、サイトでシームレスに AMP を利用できます。 

この投稿では、WordPress の公式 AMP プラグインを使って構築したウェブサイトのパフォーマンスに注目し、サイトの Core Web Vitals を最適化する際にさらに考慮すべき側面について説明します。また、ガイダンスを得るための AMP プラグイン サポート チャンネルも紹介します。

AMP プラグインの活用

AMP プラグインのランディング ページである amp-wp.org は、AMP プラグイン自体を使って構築されました。つまりこのサイトは、プラグインですぐに利用できる最適化とベスト プラクティスのメリットをすべて享受しています。たとえば、AMP はコンテンツのずれが起きない設計になっているので、通常は CLS の最適化について心配する必要はありません。AMP ページ エクスペリエンス ガイドを使って、このサイトのページ エクスペリエンス関連の動作を確認してみましょう。

ステップ 1: 分析ツールの実行

まず amp.dev/page-experience に移動し、サイトの URL を入力して [Analyze] をクリックします。

ツールが実行され、サイトでさまざまなパフォーマンス テストが行われる間、しばらく待ちます。このツールは、対象ページのページ エクスペリエンスに関連するさまざまな特徴を確認します。

ステップ 2: 結果の解析

すべてのテストが終了すると、AMP ページ エクスペリエンス ガイドにその旨が表示され、サイトの状態について簡潔な概要を確認できます。ご覧のように、amp-wp.org のページ エクスペリエンスは優れていることがわかります。

結果ページを下にスクロールすると、それぞれの Core Web Vital 指標の詳細を見ることができます。

この結果は、パブリッシャーとしてうれしい内容です。AMP が提供するすべてのパフォーマンス最適化とベスト プラクティスにリソースを費やす必要がなく、サイトのパフォーマンスが優れているからです。

CWV をさらに最適化する

自動化ツールを使って Core Web Vitals に影響するたくさんの要素に対処するときは、期待される内容を理解することが重要です。私たちの調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。つまり、AMP などのツールを使うことで、目的の達成に向けて大きく前進することができますが、追加の作業をしてさらにサイトを最適化する必要があるかもしれません。

さらに最適化が必要になるのは、以下のような場合です。

  • ページのヒーロー要素の指定が適切でない場合、一部の最適化が行われません。 
  • 場合によっては、広告によって効率が低下し、読み込み時間が増加して、ページの CWV に影響することがあります。この点を意識し、パフォーマンスが優れた広告ソリューションを使う必要があります。
  • 最初のビューポートに表示される場所に重い埋め込み要素がある場合、ページの初期読み込みが遅くなります。
  • サイトで必要となる主要なイメージの最適化が行われていない可能性があります。

amp-wp.org の場合、スコアは高いものの、AMP ページ エクスペリエンス ガイドにはさらにサイトを改善できる 2 つの推奨事項が表示されています。たとえば、読み込み速度（LCP）を改善するために、ページのヒーロー イメージを適切にマークすることが推奨されています。

これは、ページのヒーロー要素（イメージなど）に data-hero 属性を付けることで、簡単に実現できます。これを行うと、AMP プラグインは自動的にヒーロー イメージをサーバーでレンダリングするようになるので、Largest Contentful Paint（LCP）指標が改善され、ページの CWV スコアが上昇します。

サポートを受ける場所

WordPress の公式 AMP プラグインなどのツールを活用しても Core Web Vitals のパフォーマンスが向上しない場合は、WordPress.org サポート フォーラムを通してプラグインをサポートしているチームに相談したり、質問したり、結果を共有したりできます。皆さんを最大限にサポートいたします。

さらに詳しく知りたい方は、AMP や WordPress の公式 AMP プラグインのサイトをご覧ください。また、こちらの動画シリーズでは、WordPress の AMP プラグインの全貌について、解説や知見をご覧いただくことができます。パフォーマンスやページ エクスペリエンス全般についてさらに詳しく知りたい方は、Google 検索セントラルや web.dev のドキュメントをご覧ください。技術的に有用な情報が多数掲載されています。

投稿者 : Google、AMP と WordPress デベロッパー アドボケート、Alberto Medina

Reviewed by Chiko Shimizu – Developer Relations team<!—->

Google Ads API で Call Only Ads を Call Ads に置換

この記事は Bob Hancock による Google Ads Developer Blog の記事 “Call Ads Replace Call Only Ads in the Google Ads API” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。Google Ads API v8 で、Call Only Ads が Call Ads に置き換わります。AdWords API v201809 と Google Ads API v6 と v7 では、引き続き Cal…

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

この記事は 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 などの脆弱性と、パッケージ マネージャーのパッケージ名や一連のバージョンを自動的に照合することは困難。
  • どんなオープンソース エコシステムの脆弱性も記述でき、エコシステムの独自ロジックがなくても処理できる。
  • 自動システムにも人間にも使いやすい。

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

現状


脆弱性スキーマの仕様は何度かの反復を経ており、最終版に近づくにあたって、さらなるフィードバックを求めています。現在、たくさんのパブリックな脆弱性データベースがこの形式でエクスポートできるようになっており、さらに多くのデータベースで作業が進行中です。

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<!—->

AdWords API の URL パフォーマンス レポートと自動プレースメント パフォーマンス レポートのサポート終了について

この記事は Fei Xiang による Google Ads Developer Blog の記事 “Deprecating Url Performance Report and Automatic Placements Performance Report in the AdWords API” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。アップデート（6 月 21 日）: サポート終了日が延長され、2021 年 9 月 13 日になりました。 2021 年 9 月 13…