本稿は、筆者が、ORTコミュニティの皆さまにORT公式Slack等で共有いただいた内容と、公開されているドキュメント・リポジトリ情報を参照しつつ、2025年のORT周辺トピックを整理したものです。公式見解ではありません。
2025年は、ORTを個別プロジェクトの解析ツールとして使うだけでなく、組織スケールの運用に接続するための周辺整備が前進した一年として捉えられます。本稿では、その中でも「サービス化(ORT Server)」「自動化(CI統合)」「新Pythonライブラリ(python-ort)」「ビジネスユーザーワークグループ」の4点に絞ってまとめます。
0. ORTとは何か
OSS Review Toolkit(ORT)は、FOSS(Free and Open Source Software)に関するポリシー運用を自動化し、依存関係管理を支えるためのツールチェーンです。依存関係の把握から、ライセンス・セキュリティ情報の整理、ポリシー評価、レポート/SBOM出力までを、工程として組み合わせて実行できるように設計されています。
ORTが公式に挙げているユースケースとしては、例えば次のようなものがあります。
- CycloneDX / SPDX などのSBOMや、配布物に添付するアトリビューション文書の生成
- Policy as Code によるライセンス・脆弱性・エンジニアリング標準などの自動チェック
- 依存を含むソースコードアーカイブの生成(ライセンス要件への対応や保全用途)
ORTは複数のサブツールで構成されています。全体像は「依存関係の解析 → 必要な情報の収集 → ルール評価 → 出力」という流れで理解すると把握しやすいです。
- Analyzer:依存関係とメタデータの特定
- Downloader:対象と依存のソースコード取得
- Scanner:ライセンス・著作権表記などのスキャン
- Advisor:脆弱性などの助言情報の取得
- Evaluator:ポリシー(ルール)評価
- Reporter:レポートやSBOM等の出力
関連リンク:
- ORT(GitHub): https://github.com/oss-review-toolkit/ort
- Getting Started / Tutorial: https://oss-review-toolkit.github.io/ort/docs/getting-started/tutorial
0.1 設定とルールの置き場所(ort-configとEvaluator Rules)
ORTは「組織のルールをどう表現して回すか」が重要になります。公式の設定・キュレーション用リポジトリとして ort-config が公開されており、curations(パッケージキュレーション)や、evaluator.rules.kts(評価ルール)などが集約されています。
- ort-config: https://github.com/oss-review-toolkit/ort-config
- Evaluator Rules(Kotlin DSL): https://oss-review-toolkit.github.io/ort/docs/configuration/evaluator-rules
1. ORT Server:組織運用に向けた参照実装
2025年のトピックとしてまず挙げたいのがORT Serverです。Eclipse Apoapsisプロジェクトとして、ORTをクラウド上でサービスとして提供するためのスケーラブルなサーバ実装(参照実装)として位置づけられています。
ORT Serverのドキュメントでは、REST APIによる他ツール連携が明示されており、リポジトリ、シークレット、ユーザーなどの管理や、ORT実行結果の取得をAPI経由で行えると説明されています。これにより、既存のDevOpsパイプラインやCI/CDに組み込む導線が作られています。
また、Eclipseプロジェクト情報として、Kubernetes統合を前提としたスケーラブル構成、Keycloakによる認証・ロール管理、中央DBによるデータ蓄積と横断分析といった要素が挙げられています。
導入検討の入口:
- ORT Server(Docs): https://eclipse-apoapsis.github.io/ort-server/
- ORT Server(GitHub): https://github.com/eclipse-apoapsis/ort-server
- Eclipse Apoapsis(Project Info): https://projects.eclipse.org/projects/technology.apoapsis
2. CI統合:Forgejo追加とGitHub/GitLabの継続強化
CI統合は、ORTを継続的に実行するための実装の入口になります。2025年は、Forgejoを含む選択肢が拡がり、主要プラットフォーム向けの整備も進んでいます。いずれも「ライセンス/セキュリティ/ベストプラクティスのチェック」や「レポート/SBOM生成」をワークフローとして取り込みやすい形で提供されています。
2.1 Forgejo(Forgejo Actions)
Forgejo Actions向けのアクションが公開されています。デフォルトではUbuntu系runnerでORTの配布アーカイブをダウンロードして実行する想定で、対象プロジェクトに応じて必要なパッケージマネージャをrunnerに用意する、という説明になっています。また、必要に応じてDockerでの実行も選択肢として提示されています。
- Forgejo Action: https://github.com/oss-review-toolkit/ort-ci-forgejo-action
READMEでは、例えば次のようなシナリオが整理されています。
- 特定パッケージマネージャに限定して解析する
- ラベルを付与して文脈(製品、組織、配布形態など)を保持する
- ポリシー違反やセキュリティ指標に応じてジョブを失敗させる
- プライベートリポジトリや複数リポジトリ(matrix)に対応する
- グローバル設定やDB(PostgreSQL)などを組み込む
2.2 GitHub Actions
GitHub Actions向けのアクションも提供されています。READMEでは「例示はmainブランチ参照だが、本番導入ではタグ参照が推奨」と明記されており、運用時はタグ固定で使うのが前提になっています。
- GitHub Action: https://github.com/oss-review-toolkit/ort-ci-github-action
READMEに列挙されているシナリオ例(抜粋)は次の通りです。
- 解析対象のパッケージマネージャを限定
- ラベル付与
- ポリシー違反/セキュリティ指標でfailさせる
- プライベートリポジトリ対応
- 複数リポジトリをmatrixで回す
- カスタムのグローバル設定、カスタムDockerイメージ、PostgreSQL連携
参考として、ワークフロー内の利用は概ね次の形になります(タグは例です)。
- name: Run ORT
uses: oss-review-toolkit/ort-ci-github-action@v1
2.3 GitLab CI
GitLabではテンプレートとして提供され、includeで取り込む設計が基本です。成果物(結果)をartifactとして保存する例も明示されています。
- GitLab CI Template: https://github.com/oss-review-toolkit/ort-ci-gitlab
最小構成は次のような形です。
include:
- https://raw.githubusercontent.com/oss-review-toolkit/ort-ci-gitlab/main/templates/ort-scan.yml
stages:
- ort
ort-scan:
stage: ort
extends: .ort-scan
artifacts:
when: always
paths:
- $ORT_RESULTS_PATH
GitLab側でも、パッケージマネージャ限定、ラベル付与、プライベートリポジトリ対応、カスタム設定/Dockerイメージなど、運用上の典型シナリオが整理されています。
3. python-ort:ORTレポートのシリアライズを支えるライブラリ
python-ortは、OSS Review Toolkitが生成したレポートを、デフォルトのモデルを用いてシリアライズするためのpydanticベースのライブラリです。まだα版で開発中ですが、今後開発が進めばレポートをPython側で扱えるようになり、例えばダッシュボード集計、データ基盤への取り込み、社内向けの定型レポート生成などに接続しやすくなったりするかもしれません。
- python-ort(PyPI): https://pypi.org/project/python-ort/
4. Business User Working Group(BU WG)提案
機能とは別軸の動きとして、利用者側の関与を整える提案があります。ort-governance リポジトリで、Business User Working Group(BU WG)設立を求める提案が公開されています。
提案文では、例えば次のような目的が挙げられています。
- 技術とビジネスの橋渡し(大規模利用者の課題を整理し、技術議題をビジネス利用者の言語へ翻訳する)
- 導入ジャーニーとオンボーディング文書の整備(PoCから社内展開、必要な役割・ワークフローの記述まで)
- 採用者の可視性向上と、コミュニティへの関与経路の明確化
- コミュニティ成長と持続性(アウトリーチや資金・運営面の支援)
- サービスプロバイダ/ベンダ/コンサルの健全な関与モデル整理
参加条件として「ORTの利用者または利用予定であること」「ORTと競合するコンプライアンスソリューション販売が主要収益でないこと」「Linux Foundation会員である必要はないこと」なども記載されています。今後この提案がどのように実現されていくかに注目です。
謝辞
本稿の作成にあたり、ORTコミュニティの皆さまにSlack上で情報提供と論点の示唆をいただきました。ORT Server、CI統合、今後の方向性に関するコメントは、本稿の整理にあたり大変参考になりました。ご協力に感謝いたします。
参考リンク
-
ORT(GitHub): https://github.com/oss-review-toolkit/ort
-
ORT Server: https://eclipse-apoapsis.github.io/ort-server/
-
Eclipse Apoapsis(Project Info): https://projects.eclipse.org/projects/technology.apoapsis
-
BU WG提案: https://github.com/oss-review-toolkit/ort-governance/issues/43
-
python-ort: https://pypi.org/project/python-ort/
-
ort-config: https://github.com/oss-review-toolkit/ort-config
-
CI統合