公開日
OSSセキュリティ強化戦略:ツール活用、評価フレームワーク、Googleによる実践ガイド

オープンソースソフトウェア(OSS)の利用は、今やソフトウェア開発において欠かせないものとなっています。しかし、その利便性と引き換えに、サプライチェーンを通じたセキュリティリスクも増大しています。 2021年のLog4Shell 、 2024年初頭のXZ Utilsへの攻撃 など、大規模なセキュリティインシデントは、OSSサプライチェーンの脆弱性を浮き彫りにし、その対策が急務であることを示しています。
これらのインシデントは、悪意のある攻撃者がOSSプロジェクトの依存関係に不正なコードを混入させることで、そのOSSを利用する多数のシステムやアプリケーションに影響を及ぼす可能性があることを示しています。これは、個々の組織だけでなく、社会全体のセキュリティを脅かす重大な問題です。
本記事では、OSSサプライチェーンのセキュリティを強化するための実践的な戦略として、ツール活用、評価、貢献の3つの側面から詳細に解説します。
1. OSSセキュリティ強化を加速する主要ツール
OSSサプライチェーンのセキュリティを向上させるためには、まず現状を把握し、リスクを可視化することが重要です。ここでは、そのための強力なツールとして、OpenSSFが提供するScorecard、GUAC、そしてその他の有用なツールを紹介します。
1-1. セキュリティリスク可視化ツール:OpenSSF Scorecard
OpenSSF Scorecard は、OSSプロジェクトのセキュリティ状態を自動的に評価し、スコアとして可視化するツールです。GitHubリポジトリ上で公開されているOSSプロジェクトに対して、セキュリティに関するベストプラクティスがどの程度実施されているかを 複数の項目で評価 します。
Scorecardの主なチェック項目:
チェック項目 | 評価基準 | スコアが低い場合の改善策例 |
---|---|---|
Binary-Artifacts | リリース成果物にバイナリアーティファクトが含まれていないか | ビルドプロセスを見直し、ソースコードから成果物を生成するようにする。 |
Branch-Protection | メインブランチやリリースブランチが保護されているか(例:マージ前のレビュー必須化、ステータスチェックの合格必須化) | GitHubのブランチ保護ルールを設定し、承認された変更のみがマージされるようにする。 |
CI-Tests | プルリクエストやコミット時に自動テストが実行されているか | CI/CDパイプラインを設定し、プルリクエストやコミット時に自動テストを実行するようにする。 |
CII-Best-Practices | OpenSSF Best Practices Badge Program バッジを取得しているか | OpenSSF Best Practicesバッジの取得を目指し、プロジェクトのセキュリティプラクティスを改善する。 |
Code-Review | コード変更がマージされる前に、第三者によるレビューが実施されているか | コードレビュープロセスを導入し、全ての変更に対して第三者によるレビューを必須とする。 |
Contributors | 過去1ヶ月間にコントリビューターが3人以上いるか | コミュニティへの参加を促進し、コントリビューターを増やす。 |
Dangerous-Workflow | GitHub Actionsのワークフローに潜在的なセキュリティリスク(例:スクリプトインジェクション脆弱性、信頼できないソースからのコード実行)が存在しないか | ワークフロー定義をレビューし、潜在的なセキュリティリスクを排除する。 |
Dependency-Update-Tool | 依存関係を自動的に更新するツール(例:Dependabot、Renovate)が使用されているか | DependabotやRenovateなどの依存関係更新ツールを導入し、依存関係を常に最新の状態に保つ。 |
Fuzzing | ファジングテストが実施されているか | OSS-Fuzzなどのファジングツールを導入し、定期的にファジングテストを実施する。 |
Maintained | プロジェクトが過去90日間アクティブにメンテナンスされているか(過去90日間に少なくとも1回のコミットがあるか) | プロジェクトのメンテナンスを継続し、定期的にコードの更新やイシューへの対応を行う。 |
Packaging | プロジェクトがパッケージマネージャー(例:npm、PyPI)で公開されているか | プロジェクトをパッケージマネージャーで公開し、利用者が容易にインストールできるようにする。 |
Pinned-Dependencies | 依存関係が特定のバージョンに固定(ピンニング)され、ハッシュ値で検証されているか | 依存関係のバージョンを固定し、ハッシュ値で検証することで、不正なパッケージの混入を防ぐ。 |
SAST | 静的アプリケーションセキュリティテスト(SAST)ツールが使用されているか | CodeQLなどのSASTツールを導入し、コードの静的解析を実施する。 |
Security-Policy | プロジェクトにセキュリティポリシーが定義され、公開されているか | セキュリティポリシーを策定し、リポジトリのSECURITY.mdファイルなどで公開する。 |
Signed-Releases | リリース成果物がデジタル署名されているか | リリース成果物にデジタル署名を行い、利用者が成果物の真正性を検証できるようにする。 |
Token-Permissions | GitHub Actionsのワークフローで使用されるトークンの権限が最小限に設定されているか | ワークフローで使用されるトークンの権限を必要最小限に制限し、攻撃対象領域を削減する。 |
Vulnerabilities | 既知の脆弱性が存在しないか。 | 脆弱性データベース(例:OSV, NVD)を参照し、既知の脆弱性を修正する。脆弱性スキャナを導入する。 |
Scorecardは、これらのチェック項目に基づいて、0から10までのスコアを算出します。スコアが高いほど、セキュリティのベストプラクティスが実施されていることを意味します。
Scorecardの利用方法:
Scorecardは、以下の3つの方法で利用できます。
- CLIツール: コマンドラインからScorecardを実行し、特定のリポジトリのスコアを確認できます。
- GitHub Actions: リポジトリに scorecard-action のGitHub Actions拡張を設定することで、定期的にScorecardを実行し、スコアの推移を監視できます。
- Web UI(ビジュアライザー): Scorecard Visualizer を使用して、ブラウザ上でプロジェクトのスコアを視覚的に確認できます。
GitHub Actionsとして利用する例 - Scorecardを定期的に実行し、結果を可視化
Scorecard Visualizerの表示例 - 各チェック項目のスコアと総合スコアが一目でわかる
Scorecardを活用することで、OSSプロジェクトのセキュリティ状態を容易に把握し、改善すべき点を特定することができます。
1-2. 大規模評価を実現するScorecard Monitor
多数のOSSプロジェクトを利用している場合、それぞれに対して個別にScorecardを実行するのは大変な作業です。そこで活用したいのが、 Scorecard Monitor です。
Scorecard Monitorは、複数のリポジトリに対して一括でScorecardを実行し、結果を集約・監視するための仕組みです。
Scorecard Monitorのメリット:
- 効率化: 多数のリポジトリのセキュリティ状態を一元的に管理できます。
- 継続的な監視: 定期的にScorecardを実行することで、セキュリティ状態の変化をいち早く検知できます。
- 柔軟な設定: YAMLファイルで監視対象を柔軟に定義できます。例えば、組織内の全リポジトリや、特定のキーワードを含むリポジトリなどを指定できます。
1-3. 依存関係の可視化とリスク分析:GUAC
GUAC (Graph for Understanding Artifact Composition) は、ソフトウェア部品表 (SBOM) などの情報から、ソフトウェアの依存関係をグラフ構造で可視化するツールです。
GUACの主な機能:
- 依存関係グラフの生成: SBOMなどのデータソースから、ソフトウェアコンポーネント間の依存関係をグラフとして生成します。
- 依存関係情報の拡充: 依存関係にあるOSSプロジェクトについて、Scorecardのスコアや脆弱性情報などを収集し、グラフに統合します。
- リスク分析の支援: 依存関係グラフを分析することで、リスクの高いOSSプロジェクトや脆弱なパスを特定できます。
GUACの活用例:
- あるOSSプロジェクトに脆弱性が発見された場合、GUACを用いることで、そのOSSに依存する他のプロジェクトを迅速に特定できます。
- 依存関係グラフを可視化することで、複雑な依存関係を容易に理解し、潜在的なリスクを把握できます。
GUACを利用することで、複雑な依存関係を視覚的に把握し、サプライチェーンリスクをより詳細に分析することが可能になります。
1-4. その他の有用ツール:GitHub API, MITRE Hipcheck, Phylum.io, OSV-Scanner
OSSセキュリティ評価には、上記で紹介したツール以外にも有用なツールが存在します。
- GitHub API: GitHub APIを利用することで、リポジトリに関する様々な情報を取得できます。例えば、コミット履歴、プルリクエスト、イシューなどを取得し、プロジェクトの活動状況やセキュリティ対策の実施状況を分析できます。
- MITRE Hipcheck : リポジトリのメタデータを分析し、セキュリティリスクを評価するツールです。例えば、プロジェクトの活動状況、メンテナーの数、セキュリティポリシーの有無などを評価します。
- Phylum.io : OSSパッケージのセキュリティリスクを評価するサービスです。パッケージの依存関係、脆弱性、ライセンス情報などを分析し、リスクスコアを提供します。
- OSV-Scanner : 特定のコミットやタグ、ハッシュ値における既知の脆弱性を特定するのに役立ちます。
これらのツールを組み合わせることで、OSSプロジェクトのセキュリティ状態を多角的に評価し、より精度の高いリスク分析を行うことができます。
2. OSS-P4/R:包括的な評価フレームワーク
ここでは、米国防総省(DoD)の基準に基づいたOSS評価フレームワークである「OSS-P4/R」について解説します。OSS-P4/Rは、OSSプロジェクトをプロジェクト(Project)、プロダクト(Product)、プロテクション(Protection)、ポリシー(Policy) の4つの観点から評価し、その結果を レポート(Report) として出力する包括的なフレームワークです。
2-1. OSS-P4/R:DoD基準に基づく包括的評価
OSS-P4/Rは、Unified Platform (USCYBERCOM)とCarnegie Mellon Software Engineering Instituteによって開発されたOSS評価フレームワークであり、DoDにおけるOSSの安全な利用を支援することを目的としています。
OSS-P4/Rでは、OSSプロジェクトを以下の4つの観点(P4)から評価します。
- プロジェクト (Project): プロジェクトの健全性、活動状況、コミュニティの規模などを評価します。
- 例:プロジェクトが活発にメンテナンスされているか、十分な数のコントリビューターがいるか、など。
- プロダクト (Product): ソフトウェア自体のセキュリティ機能や品質を評価します。
- 例:既知の脆弱性が存在しないか、セキュアコーディングのベストプラクティスが適用されているか、など。
- プロテクション (Protection): 開発プロセスにおけるセキュリティ対策を評価します。
- 例:コードレビューが実施されているか、静的解析ツールが導入されているか、など。
- ポリシー (Policy): セキュリティポリシーやガバナンスに関する方針を評価します。
- 例:明確なセキュリティポリシーが定義され、公開されているか、セキュリティインシデント対応計画が策定されているか、など。
OSS-P4/Rレポートのサンプル:
評価項目 | スコア | 詳細 | リスク判定 |
---|---|---|---|
プロジェクト健全性 | 8/10 | プロジェクトは活発にメンテナンスされており、多数のコントリビューターが参加しています。 | 低 |
脆弱性 | 6/10 | いくつかの既知の脆弱性が存在しますが、修正パッチが提供されています。 | 中 |
コードレビュー | 9/10 | 全てのコード変更に対して、厳格なコードレビューが実施されています。 | 低 |
セキュリティポリシー | 4/10 | セキュリティポリシーは定義されていますが、公開されていません。 | 中 |
総合評価 | 6.75/10 | 一部にリスクが存在するものの、全体としてはセキュリティ対策が実施されています。ただし、セキュリティポリシーの公開が必要です。 | 中 |
OSS-P4/Rのレポートは、OSSプロジェクトのセキュリティ状態を包括的に把握し、リスクの所在を明確化するのに役立ちます。また、評価結果に基づいて、改善のための優先順位を決定し、効果的な対策を講じることが可能になります。
2-2. OSS-P4/Rによる評価プロセスの実際
OSS-P4/Rを用いた評価は、以下のステップで実施されます。
- データ収集: GitHub API、Scorecard、MITRE Hipcheck、Phylum.ioなどのツールを用いて、OSSプロジェクトに関するデータを収集します。
- データ分析: 収集したデータを分析し、4つの評価軸(P4)に基づいて、各項目のスコアを算出します。
- レポート生成: 評価結果をレポート(R)として出力します。レポートには、各評価項目のスコア、詳細情報、推奨される改善策などが記載されます。
- リスク判定: レポートの結果に基づき、OSSプロジェクトのセキュリティリスクを総合的に判定します。
以下に、OSS-P4/Rによるレポーティングの概要図を示します。
OSS-P4/Rによる評価プロセス - 各ツールからデータが収集・分析され、リスク判定が行われる
2-3. 評価結果の活用と継続的改善
OSS-P4/Rの評価結果は、OSSプロジェクトのセキュリティ向上に活用されることが重要です。具体的には、以下のステップで活用します。
- リスクの特定: レポートで示された各評価項目のスコアと詳細情報を確認し、セキュリティ上のリスクを特定します。
- 優先順位付け: リスクの深刻度、発生可能性、影響範囲などを考慮して、対応の優先順位を決定します。
- 改善計画の策定: 特定されたリスクを軽減するための具体的な改善計画を策定します。例えば、脆弱性の修正、セキュリティポリシーの策定、コードレビューの強化などが挙げられます。
- 改善策の実施: 策定した改善計画に基づき、具体的な対策を実施します。
- 継続的モニタリング: 改善策の実施後も、定期的にOSS-P4/Rによる評価を実施し、セキュリティ状態を継続的にモニタリングします。
OSS-P4/Rは、OSSプロジェクトのセキュリティ状態を包括的に評価し、改善のための指針を提供してくれる強力なフレームワークです。評価結果を適切に活用し、継続的な改善サイクルを回すことで、OSSサプライチェーンのセキュリティを向上させることができます。
3. Google事例から学ぶ、OSSセキュリティへの貢献
ここでは、GoogleのOpen Source Security Team(GOSST)が実施した、OSSセキュリティ向上への貢献事例を紹介します。GOSSTの取り組みから、OSSコミュニティと協働し、セキュリティを向上させるためのヒントを学びましょう。
3-1. GOSSTの取り組み:200のOSSプロジェクトへの貢献
Google Open Source Security Team(GOSST)は、OSSエコシステムのセキュリティ向上を目的とした専門チームです。GOSSTは、2023年に、特に重要度が高いと判断した約200のOSSプロジェクトを対象に、セキュリティ改善のための貢献活動を実施しました。
GOSSTは、以下の基準に基づき、支援対象となるプロジェクトを選定しました。
- 重要度: OpenSSF Criticality Score などを参考に、OSSエコシステムにおける重要度を評価しました。
- 活動状況: プロジェクトが活発にメンテナンスされており、コントリビューターが活動していることを確認しました。
- 改善の余地: OpenSSF Scorecardのスコアが低く、セキュリティ改善の余地が大きいプロジェクトを優先しました。
これらの基準に基づき、GOSSTは約200のOSSプロジェクトを選定し、セキュリティ向上に向けた支援活動を開始しました。
3-2. メンテナーとの協働:GOSSTの行動指針
GOSSTは、OSSプロジェクトのメンテナーと協働する際に、以下の5つの行動指針を定めています。
- 貢献は対話である: 貢献は一方的なものではなく、メンテナーとの対話を通じて行うべきである。
- GOSSTは、メンテナーの意見を尊重し、押しつけがましい提案は行いません。
- OpenSSF Scorecardの実行結果を共有する際も、あくまで現状把握と問題提起に留め、判断はメンテナーに委ねます。
- コンテキストが重要: プロジェクトの背景や状況を理解した上で、貢献を行うべきである。
- GOSSTは、コントリビューションガイドラインを確認し、過去の議論を参照するなど、プロジェクトのコンテキストを理解するよう努めます。
- 人間らしく接する: メンテナーも人間であり、敬意を持って接するべきである。
- GOSSTは、自動化されたメッセージではなく、人間が個別に、かつ丁寧にコミュニケーションを取ることを重視します。
- 忍耐強く: OSSプロジェクトは、それぞれ異なるペースで運営されていることを理解し、忍耐強く対応する。
- GOSSTは、メンテナーからの反応が遅い場合でも、催促したり急かしたりせず、辛抱強く待ちます。
- 透明性を保つ: 自身の所属や立場、貢献の目的を明確に伝える。
- GOSSTは、Googleの従業員であることを明示し、貢献の目的がOSSエコシステムのセキュリティ向上であることを説明します。
これらの行動指針は、OSSコミュニティと良好な関係を築き、効果的な貢献を行うために非常に重要です。
3-3. GOSSTの貢献内容と成果
GOSSTは、主に以下のようなセキュリティ改善策をOSSプロジェクトに提案・実施しました。
- GitHub Actionsの権限最小化: ワークフローで使用される権限を必要最小限に制限することで、攻撃対象領域を削減しました。
- 依存関係のピンニング: 依存関係のバージョンを固定(ピンニング)し、ハッシュ値で検証することで、不正なパッケージの混入を防ぎました。
- 依存関係更新の自動化: Dependabotなどのツールを用いて、依存関係の更新を自動化し、常に最新の状態を保てるようにしました。
- セキュリティポリシーの策定支援: プロジェクトがセキュリティポリシーを策定し、公開するのを支援しました。
これらの貢献活動の結果、約90%の提案が受け入れられ、対象となったOSSプロジェクトのOpenSSF Scorecardのスコアが平均5.4から7へと向上しました(2023年末時点)。これは、OSSエコシステム全体から見ても上位11%に入る高い水準です。
以下は、GOSSTによる貢献前後のScorecardスコアの分布の変化を表す図です。
また、GOSSTの活動は、一部のプロジェクトにおいて、メンテナー自身のセキュリティ意識の向上にも繋がりました。例えば、あるプロジェクトのメンテナーは、GOSSTからの提案をきっかけに、他の関連リポジトリに対しても同様のセキュリティ改善を実施しました。
特筆すべき事例:Jia Tan氏
2024年初頭に発覚したXZ Utilsへの攻撃は、Jia Tan(JiaT75)と名乗る攻撃者(またはその協力者)が、長期間にわたってプロジェクトに深く関与し、信頼を得た上で、バックドアを仕込んだものです。皮肉なことに、このJia Tan氏は、GOSSTが2023年に実施した貢献活動において、3つのセキュリティ改善提案を承認していました。この事例は、攻撃者が巧妙にプロジェクトに潜入し、セキュリティ対策を回避する可能性があることを示しており、OSSセキュリティの難しさを物語っています。この事実から、善意のセキュリティ向上活動に見せかけて、悪意のある行動を隠蔽するリスクも存在することが示唆されます。
参考情報:
- Thomas Depierre氏のブログ記事「 I am not a supplier 」は、OSSメンテナーと利用者の関係性について考える上で非常に参考になります。
- OpenSSF のウェブサイトには、OSSセキュリティに関する様々な情報が掲載されています。
- Scorecard や GUAC のドキュメントには、ツールの詳細な使い方や設定方法が記載されています。
- OSSF Best Practices Working Group では、OSSセキュリティのベストプラクティスに関する議論が行われています。
まとめ:OSSセキュリティは全員参加で
OSSサプライチェーンのセキュリティリスクは、今後ますます増大していくことが予想されます。これらのリスクに対処するためには、個々の組織の努力だけでなく、OSSコミュニティ全体での取り組みが不可欠です。
本記事では、OSSセキュリティ強化のための実践的な戦略として、ツール活用、評価、貢献の3つの側面から詳細に解説しました。
- ツール活用: OpenSSF ScorecardやGUACなどのツールを活用することで、OSSプロジェクトのセキュリティ状態を効率的に評価し、リスクを可視化することができます。
- 評価: OSS-P4/Rのような包括的な評価フレームワークを用いることで、OSSプロジェクトを多角的に評価し、リスクの所在を明確化することができます。
- 貢献: GOSSTの事例から学び、OSSプロジェクトのメンテナーと協働し、セキュリティ向上に貢献しましょう。
OSSセキュリティは、特定の誰か任せにするのではなく、開発者、ユーザー、セキュリティ専門家など、全ての関係者が当事者意識を持って取り組むべき課題です。本記事が、その一助となれば幸いです。
Webサービスや社内のセキュリティにお困りですか? 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください!
参考資料:
- Scorecard at Scale: Old and New Possibilities for Lifting Security on All Repositories - Jeff Mendoza, Kusari & Stephen Augustus, Cisco Systems, Inc.
- Assessing Open Source Software Projects in the Software Supply Chain - Scott Hissam, Carnegie Mellon Software Engineering Institute & Joshua “CoCo” Crisp, Unified Platform (USCYBERCOM)
- Supply-Chain Security, Outside in: What Helping ~200 Projects Improve Their Security Looks Like - Pedro Nacht & Diogo Teles Sant’Anna, Google