オープンソース プロジェクトをサプライ チェーン攻撃から守る

この記事は Google オープンソース プログラム オフィス、Anne Bertucio による Google Open Source Blog の記事 “Protect your open source project from supply chain attacks” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


米国の大統領令から鍵署名パーティまで、2021 年はサプライ チェーンのセキュリティが取りざたされる一年になっています。オープンソースのメンテナンス担当者がプロジェクトのサプライ チェーン全体の攻撃面や脅威ベクトルについて知れば、克服できないと感じて打ちひしがれるかもしれません。朗報なのは、2021 年がサプライ チェーン セキュリティ ソリューションの一年でもあったということです。行うべき作業はまだ多く残されており、既存のソリューションも多くの改善の余地を抱えています。しかし、サプライ チェーンを強化してセキュリティ侵害を防ぐために、今すぐプロジェクトに適用できる予防措置があります。

All Things Open 2021 の参加者は、クイズゲームを通してサプライ チェーンのセキュリティに関するベスト プラクティスを学びました。このブログ投稿では、クイズの問題と解答、そして予防措置の選択肢を紹介します。また、この投稿はサプライ チェーン攻撃からオープンソース プロジェクトを守りたい方向けの初心者向けガイドにもなります。以降で紹介する推奨事項は、SLSA フレームワークや OpenSSF Scorecards の重要事項に従っており、その多くは Allstar プロジェクトを使って自動的に実装できます。

典型的なソフトウェア サプライ チェーンと、その接続点で発生する可能性がある攻撃の例
典型的なソフトウェア サプライ チェーンと、その接続点で発生する可能性がある攻撃の例

Q1 : デベロッパー アカウントの乗っ取りを防ぐためにするべきことは何ですか？

  1. 正解 : 多要素認証を利用する（可能ならセキュリティ キー）
  2. コア メンテナンス担当者向けの共有アカウントを利用する
  3. パスワードはすべて rot13 で記述する
  4. IP 許可リストを利用する

理由と解説 : 悪意のある人物がデベロッパー アカウントにアクセスできる場合、既知の貢献者になりすまして悪意のあるコードを送信する可能性があります。貢献者には、commit を送るプラットフォームだけでなく、メールなどの貢献に関連するアカウントに対して、多要素認証（MFA）を使うことを推奨しましょう。可能であれば、MFA の方式でお勧めなのはセキュリティ キーです。

Q2 : 悪意のある commit をマージしないために、するべきことは何ですか？

  1. 正解 : すべての commit で、commit の作成者以外の誰かによるレビューを必須とする
  2. すべての commit に対して自動実行テストをする
  3. すべての commit に対して ‘bitcoin’ という単語をスキャンする
  4. 1 年以上前からアカウントを使っている貢献者からの commit のみを受け付ける

理由と解説 : セルフマージ（一方的な変更とも呼ばれます）には、1）貢献者のアカウントを乗っ取った攻撃者がプロジェクトに悪意のあるコードを注入する可能性がある、2）善意の貢献者が意図しないセキュリティ リスクを含む commit をマージする可能性がある、という 2 つのリスクがあります。悪意のあるコードの送信や意図しない脆弱性を回避するために役立つのが、身元が明らかで信頼できる別の人の目です。可能であれば、GitHub のブランチ保護設定などを使い、自動要件として設定しましょう。Allstar などのツールも、この要件の適用に役立ちます。これは、SLSA レベル 4 に対応します。

Q3 : CI/CD パイプラインで使うシークレットはどのように保護しますか？

  1. 正解 : シークレット マネージャー ツールを利用する
  2. シークレットへのアクセスを管理するメンテナンス担当者を任命する
  3. シークレットを環境変数に保存する
  4. シークレットを別のリポジトリに保存する

理由と解説 : 「多層防御」というセキュリティの考え方は、複数の異なる防御レイヤーを設けてシステムやシークレット * などの機密データを守ることを指します。シークレット マネージャー ツール（GCP ユーザーの Secret Manager や、HashiCorp Vault、CyberArk Conjur、Keywhiz など）を使うと、ソースコードにシークレットをハードコードする必要はなくなり、集中管理や機能の監査を実現できます。また、シークレットの漏洩を防ぐ認可レイヤーを導入することにもなります。

* 機密データを CI システムに保存する場合は、それが CI/CD のためだけに使われることや、パスワードや ID マネージャーに格納するほうが適したデータではないことを確認してください。

Q4 : CI/CD システムを不正利用から守るためにするべきことは何ですか？

  1. 正解 : 最小権限の原則に従ったアクセス制御を行う
  2. すべての pull リクエストと commit に対して結合テストを行う
  3. すべての貢献者に GitHub のロール “Collaborators” を設定する
  4. ローカルで CI/CD システムを実行する

理由と解説 : デフォルトでプロジェクト リポジトリに対して「必要最低限のアクセス」を付与することで、意図しないアクセスと不正利用の両方から CI/CD システムを守ることができます。テストを行うことは重要ですが、デフォルトですべての commit と pull リクエストに対してレビュー前にテストを実行すると、CI/CD システムのコンピューティング リソースの意図しない不正利用につながる可能性があります。

Q5 : ビルド中のセキュリティ侵害を避けるためにするべきことは何ですか？

  1. 正解 : ビルドの定義や構成を build.yaml などのコードで定義する
  2. コードを侵害する時間を攻撃者に与えないように、可能な限りビルド時間を短縮する
  3. ビルドシステムには LEGO ブランドの部品だけを使い、代替品は認めない
  4. 攻撃者の手がかりとなるものを残さないように、ビルドログを削除する

理由と解説 : 手動でビルド手順を実行すると、意図しない構成ミスが紛れ込む可能性があります。しかし、ビルド スクリプト（ビルドやビルドの手順を定義した build.yaml などのファイル）を使えば、手動でビルドする必要はなくなります。加えて、悪意のある人物がビルドを改ざんしたり、レビューされていない変更を紛れ込ませたりする機会を減らすことにもなります。これは、SLSA レベル 1～4 に対応します。

Q6 : 依存関係の利用前評価はどのように行うべきですか？

  1. 正解 : Scorecards や deps.dev などのツールを使ってリスクと推移的な変更を評価する
  2. パッケージ URL の隣に表示される小さな「鍵」アイコンをチェックする
  3. GitHub で最低 1,000 個のスターが付いている依存関係のみを利用する
  4. メンテナンス担当者が一度も変更されていない依存関係のみを利用する

理由と解説 : 1 つの決定的な手法でパッケージが「良い」か「悪い」かを判断することはできません。セキュリティ プロファイルや許容できるリスクは、プロジェクトごとに異なります。プロジェクトにとって依存関係が「安全」であるかどうかを判断するうえで役立つのは、依存関係やどのような変更が推移的に取り込まれるかの情報を集めることです。Open Source Insights（deps.dev）などのツールは、最初のレイヤーと推移的依存関係をマッピングしてくれます。一方の Scorecards は、セキュリティ ポリシー、MFA、ブランチ保護の使用有無など、複数のリスク評価指標に基づいてパッケージのスコアを算出します。

使っている依存関係を把握できたら、定期的に Open Source Vulnerabilities などの脆弱性スキャンツールを実行します。そうすることで、常に最新のリリースやパッチについての情報を得ることができます。多くの脆弱性スキャンツールは、アップグレードの自動適用にも対応しています。

Q7 : ビルドが自分の意図したビルドであることを保証する（すなわち、検証する）ために、何をするべきですか？

  1. 正解 : 来歴の認証を生成できるビルドサービスを利用する
  2. 最新の commit をチェックし、信頼できるコミッターのものであることを確認する
  3. ステガノグラフィーを使ってプロジェクトのロゴをビルドに埋め込む
  4. リリースのたびに適合テストを行う

理由と解説 : ビルドの出所（ビルドの来歴）とアーティファクトを表示すると、ビルドが改ざんされていないことや、正しいものであることをユーザーに示すことができます。来歴にはさまざまな要素があります。こういった要素を実現する 1 つの方法は、来歴を表示するために必要なデータを生成と認証するビルドサービスを利用することです。これは、SLSA レベル 2～4 に対応します。

Q8 : レジストリからアーティファクトを選ぶ際に、求めるべきことは何ですか？

  1. 正解 : アーティファクトが暗号学的に検証可能な形で署名されていること
  2. アーティファクトが（墓から盗み出されて）呪われたものでないこと
  3. タイムスタンプ : 最新のアーティファクトのみを使う
  4. 公式認定 : 信頼できるブランドや標準化団体のロゴを探す

理由と解説 : 来歴の生成やビルドの署名は、自分のプロジェクトで行うべきことであるだけでなく（SLSA レベル 2～4）、他者のアーティファクトを使うときも、同じ証明を求めるべきです。ロゴなどのブランドに基づく認定形態は偽造可能で、タイポスクワッティングによって正当性を偽装できます。署名などの偽造できない証明を求めるようにしてください。たとえば Sigstore は、OSS プロジェクトでビルドに署名したり、他者のビルドを検証したりする際に役立ちます。

プロジェクトのセキュリティ改善は継続的な取り組みです。ここで紹介した推奨事項の中には、プロジェクトですぐに採用するのが現実的ではないものもあるかもしれません。しかし、プロジェクトのセキュリティ向上のために行える手順はすべて、正しい方向に向かう一歩です。
オープンソース プロジェクトのセキュリティに関連するリソース :

  • SLSA : サプライ チェーンのセキュリティ レベルに関するフレームワーク
  • Scorecards : セキュリティのベスト プラクティスの使用状況を測定
  • Allstar : セキュリティのベスト プラクティスを強制する GitHub アプリ
  • Open Source Insights : オープンソース プロジェクトの依存関係の視覚化と検索
  • OSV : オープンソース用の脆弱性データベースと自動化インフラストラクチャ

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

モダンシステムにおける検証可能な設計について

この記事はプロダクション セキュリティ チーム、Ryan Hurst による Google Online Security Blog の記事 “Verifiable design in modern systems” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ソフトウェアの設計方法や構築方法は絶え間なく進化しています。現在、私たちは、セキュリティをソフトウェアに最初から組み込むものとして考えていますが、そのソフトウェアへの信頼を最小限に抑える新たな方法も模索し続けています。それを実現する方法の 1 つは、ソフトウェアが行ったことを暗号学的な確実性をもって確認できるようにソフトウェアを設計することです。

この投稿では、この暗号学的な確実性を実現する際に役立つ、検証可能なデータ構造という考え方を紹介します。検証可能なデータ構造の既存の応用例や新しい応用例についても説明します。また、皆さん独自のアプリケーションでこの構造を活用していただくためのリソースも提供します。

 
検証可能なデータ構造とは、暗号学的な確実性によって、そこに含まれているデータが正しいという合意を効率的に形成できるデータ構造です。

最も有名なのがマークル木です。マークル木が数十年にわたって使用されているのは、多くのレコードの中にデータの特定の部分が含まれていることを効率的に検証できるからです。そのため、ほとんどのブロックチェーンの基礎としても使われています。

このような検証可能なデータ構造は新しいものではありませんが、新しい世代のデベロッパーたちがこのデータ構造によって実現できる設計を発見することにより、採用が加速されています。

 
こういった検証可能なデータ構造を使えば、動作自体に検証可能性と透明性が組み込まれた要素を利用して、新たな種類のソフトウェアを構築できます。これは型強制に対する新たな形での防御になり、既存のエコシステムや新しいエコシステムにアカウンタビリティが導入されるとともに、規制機関、消費者、パートナーに対するコンプライアンスの実証も簡単になります。

証明書の透明性は、検証可能なデータ構造の大規模な利用例の 1 つであり、ブロックチェーンを利用せずに、インターネットの中核インフラストラクチャを保護する方法です。私たちはこのパターンを使い、ウェブを破壊することなく、あらゆる人が利用する既存システムに透明性とアカウンタビリティを導入することができました。

 
残念なことに、検証可能なデータ構造とそれに関連するパターンの機能はあるものの、デベロッパーがスケーラブルな実稼働品質のシステムを設計、開発、デプロイするうえで利用できるリソースは多くありません。

このギャップに対処するため、Google が証明書の透明性の構築に使ったプラットフォームを汎用化し、他の種類の問題にも応用できるようにしました。このインフラストラクチャは、何年にもわたってこのエコシステムの一部として使われているので、よく理解されており、実稼働システムに安心してデプロイできます。
そのため、このプラットフォームは、医療、金融サービス、サプライ チェーンなどの領域のソリューションで活用されています。さらにこのパターンを応用し、Google のプロダクトやサービスの他の問題にも、透明性とアカウンタビリティの特性を適用しています。

その実現に向けて、2019 年にこのプラットフォームを使い、Go Checksum Database によって Go 言語のエコシステムにサプライ チェーンの整合性を導入しました。このシステムにより、デベロッパーは、Go のエコシステムをサポートするパッケージ管理システムが、意図的、恣意的、偶発的に誤ったコードを公開しても、それが見逃されることはないという確証を得ることができます。Go ビルドの再現性によって、ソース リポジトリにあるものがパッケージ管理システムにあるものと一致するという保証を得られるので、これは特に有力です。このソリューションは、ソース リポジトリからコンパイルされた最終アーティファクトまで、一貫して検証可能なチェーンを提供します。

このパターンのもう 1 つの活用例が、最近発表された Sigstore という Linux Foundation とのパートナーシップです。このプロジェクトは、オープンソース エコシステムへのサプライ チェーン攻撃が増え続けていることへの対応です。

サプライ チェーン攻撃が成立するのは、チェーンのリンク部分に弱点があるからです。ビルドシステム、ソースコード管理ツール、アーティファクト リポジトリなどのコンポーネントは、すべて重要な実稼働環境なので、それ相応に扱う必要があります。そのためには、まず、チェーン全体の出所を検証できるようにする必要があり、Sigstore の目的はこれを実現することです。

現在、私たちは、このパターンとツールを使って、デバイスのファームウェアで、ハードウェアによって強制されるサプライ チェーンの整合性を実現する作業をしています。これにより、ファームウェアのサプライ チェーンに透明性とアカウンタビリティが導入されるので、私たちが日々利用するスマートフォンなどのデバイスに対するサプライ チェーン攻撃が減るものと期待しています。

以上のすべての例で、検証可能なデータ構造を使い、サプライ チェーンでアーティファクトの整合性を保証しています。これにより、顧客、監査者、内部セキュリティ チームは、サプライ チェーンのすべての関係者がそれぞれの責任を果たしていることを確信できます。これは、サプライ チェーンの利用者の信頼を得るうえで役立ち、発覚する可能性が増えるため内部関係者による立場の悪用を阻止できます。また、アカウンタビリティが導入され、関連システムが継続的にコンプライアンス義務を果たせるようになります。

このパターンを使う場合、最も重要なタスクは、どのデータを記録するかを定義することです。そこで、分類とモデリングのフレームワークを作成しました。これは、以上で説明したシステムに検証可能性を組み込む際の設計に役立ちました。ご活用いただければ幸いです。
検証可能なデータ構造の詳細については、transparency.dev ウェブサイトや、皆さん独自のアプリケーションで使っていただけるようにまとめたツールやガイダンスをご覧ください。