oss-analyzer

GitLab CI と GitHub Actions 向けの 100% オープンソースのコード解析スイート（セキュリティとコンプライアンス）— SCA、SAST、シークレット、ライセンスを、単一のバージョン管理されたポリシーで駆動します。多言語リポジトリ（Go、Rust、Java/JVM、Python、JS/TS、C/C++）に対応。SaaS は不要で、コードが第三者に送信されることもありません。

はじめに

oss-analyzer は CI においてリポジトリのセキュリティとコンプライアンスをゲートします。スキャナを実行し、単一のバージョン管理されたポリシーを適用して単一の判定を下し、HTML ダッシュボードとマージリクエストレポートを提供します。

flowchart LR
    repo["Your repository"]
    subgraph checks["Scanners: they collect, never block"]
        deps["Dependencies<br/>Syft SBOM<br/>Grype, OSV-Scanner"]
        licenses["Licenses<br/>license gate on the SBOM<br/>policy-licenses.yml"]
        code["Code<br/>Semgrep<br/>policy-semgrep.yml"]
        secrets["Secrets<br/>Gitleaks, whole git history<br/>policy-gitleaks.toml"]
        iac["Dockerfiles, IaC<br/>Trivy"]
        headers["SPDX headers<br/>REUSE"]
    end
    policy{{"Policy<br/>thresholds, modes, exceptions<br/>policy-global.yml"}}
    verdict(["One verdict: pass or block<br/>dashboard, merge request reports"])

    repo --> deps & licenses & code & secrets & iac & headers --> policy --> verdict

policy-* ファイルは、security/ フォルダ内にあるあなたの設定です。各ファイルは任意であり、oss-analyzer のデフォルトを補完します（oss-analyzer のカスタマイズを参照）。

すべての検出結果は 1 つのダッシュボードに集約されます。以下は意図的に脆弱性を持たせたデモプロジェクトでの表示です（590 件の検出結果、うち 333 件がブロッキング）：

実行方法は 3 通りあり、いずれも同じポリシーと同じレポートを使用します：

GitLab CI/CD コンポーネント

include:
  - component: gitlab.com/thalesgroup/oss-analyzer/[email protected]

以上です。gitlab.com 上では、コンポーネントは gitlab.com/thalesgroup/oss-analyzer の CI/CD カタログで公開されており、これはこのリポジトリの読み取り専用コピーです。自前のプロジェクトしか含めることができないセルフマネージドインスタンスでは、そのプロジェクトをそこにミラーリングし、インスタンス上のパスでインクルードしてください。イメージは registry.gitlab.com/thalesgroup/oss-analyzer（OSA_IMAGE_REPOSITORY）に残り、コンポーネントのコミット SHA でタグ付けされます。分析はマージリクエスト、デフォルトブランチ、スケジュール、タグに対して test ステージで実行されます。ブロックできるのは osa_report_aggregate ジョブのみです。ダッシュボードは MR パイプラインウィジェット内で OSS security dashboard としてリンクされ、MR の Reports タブには検出結果（Security scan、Code Quality）が表示されます。

• イメージは公開レジストリ（Docker Hub、ghcr.io）から固定バージョンで取得されます。レジストリミラーを使用する環境では、OSA_<TOOL>_IMAGE 入力を上書きしてください — Container images を参照。
• 設定: 組織のデフォルトがそのまま適用されます。カスタマイズするには、security/policy-global.yml、policy-licenses.yml、policy-semgrep.yml、policy-gitleaks.toml のいずれかを追加し、差分のみを記述してください — Customizing oss-analyzer を参照。
• 共通入力:

      inputs:
        OSA_DISTRIBUTION_MODEL: distributed   # saas | distributed | oss_library
        OSA_MODE: audit                       # onboarding: report everything, never block
        OSA_JOB_NEEDS: ["build"]              # wait for your build first
  

  各入力はコンポーネントのCI/CD Catalogページおよび templates/analyze.ymlに記載されています。
• バックログのあるプロジェクト: OSA_MODE: audit はすべてを報告し、 何もブロックしません。OSA_GATE_SCOPE: new は新規のものだけをブロックし続けます。マージリクエストでは、 ターゲットブランチの最新の成功レポートにまだ含まれていないものだけがブロックされます。それ以外の場所では、検出結果はブロックせずに報告されます（そのためマージリクエストパイプラインが必要です）。詳細は 新規の検出結果のみを参照してください。
• MR サマリーコメント: OSA_ENABLE_MR_COMMENT: true は判定結果、 ブロック対象の検出結果、ダッシュボードリンクを1つのコメントとして投稿し、パイプラインごとに更新されます。これには、マスクされた OSA_GITLAB_TOKEN CI/CD 変数にプロジェクトアクセストークン（スコープ api、ロール Reporter）が必要です。
• Maven プロジェクト: Maven Central は共有ランナーをスロットリングするため、 解決された依存関係グラフが失われます。OSA_MAVEN_MIRROR_URL（例: アーティファクトリポジトリの Maven Central リモート）を、認証情報が必要な場合はマスクされた OSA_MAVEN_MIRROR_AUTH 変数とともに指定すると、代わりにミラー経由で解決されます — 既知の落とし穴を参照してください。
• バージョン: マイナーバージョンを固定してください（@0.4 はそのパッチを追従します）。0.x インターフェースは 1.0.0 まで変更される可能性があります。破壊的変更は マイナーバージョンを上げます。詳細は CHANGELOG.md を参照してください。

GitHub Actions 再利用可能ワークフロー

jobs:
  security:
    uses: ThalesGroup/oss-analyzer/.github/workflows/security.yml@<ref>
    with:
      oss-analyzer-repository: ThalesGroup/oss-analyzer
      oss-analyzer-ref: <ref>   # the same ref as in `uses:`

入力、権限、シークレットについては GitHub Actionsを参照してください。

CIを使わないローカル分析

CIを設定せずに、受信したプロジェクトアーカイブ（.zip、.tar.gz）またはフォルダを分析します:

security/scripts/analyze-archive.sh my-project.zip

レポートとHTMLダッシュボードは security-reports/<project-name>/ の下に出力されます — 詳細は Usage を参照してください。

ドキュメント

完全なドキュメントは security/README.md にあります: セットアップ、すべての入力と設定、レポート、既知の落とし穴について記載しています。 CHANGELOG.md にはバージョンが一覧されており、破壊的変更が最初に記載されています。

oss-analyzer を選ぶ理由

各関心事に対応する優れたオープンソーススキャナーは存在します: Semgrep、Gitleaks、 Syft、Grype、OSV-Scanner、Trivy、cdxgen、REUSE。チームに欠けているのは、 スキャナーをもう1つ追加することではなく、それらの間をつなぐ部分です。つまり、レポートの山ではなく 1つの判断、記憶ではなく文書化されたルール、 そしてCVEと同じくらい真剣に扱われるライセンスです。oss-analyzer はその部分を担います。

1回の分析で、ソフトウェア全体を

各実行では、出荷するものの3つの側面をまとめて検査します:

• 自社コード: SAST（Semgrep、レジストリパックと社内ルール）、 git履歴全体のシークレット（Gitleaks）、SPDX ヘッダー（REUSE）。
• 依存しているもの: 1つのSBOM（Syft、および Maven/Gradle 向けの cdxgen の解決済みグラフ）が、脆弱性スキャン（Grype、 OSV-Scanner をセカンドオピニオンとして併用）とライセンスゲートの両方に供給されるため、 セキュリティとコンプライアンスが同じコンポーネントリストを評価します。
• 提供するもの: DockerfileとIaC、およびビルドされたコンテナ イメージ（Trivy）。

際立っている点

• 1つの判定。 スキャナーは収集するだけですが、1つのジョブがそれらの 検出結果を重複排除し、ポリシーを適用して判断します。
• 盲点なし。 レポートを残さなかったスキャナーは検出結果と同様にブロックします: グリーンのパイプラインは、すべてがチェックされたことを意味します。
• ポリシー・アズ・コード。 しきい値、例外、ライセンスリスト、SASTおよび シークレットルールはリポジトリ内に置かれ、コードと同様にレビューされます。プロジェクトは 組織のデフォルトとの差分だけを記述します。
• 例外には期限がある。 各例外には理由、承認者、有効期限があり、 期限を過ぎると検出結果は再びブロックします。
• ライセンスを真剣に扱う。 許可／レビュー／拒否リストと SPDX 式は、SPDX が 定義するとおりに解釈されます（OR、AND、WITH）。
• 段階的な導入。 監査モード、またはマージリクエストが追加したものだけをブロックする設定により、 バックログを抱えるプロジェクトでも今日から始められます。
• どこでも同じエンジン。 GitLabコンポーネント、GitHubワークフロー、または フォルダや受信したアーカイブに対して実行するローカルスクリプト。
• ホスティング不要、再現可能。 サーバーなし、SaaSなし、コードを外部に送信しません。すべてのツールイメージは固定されているため、 あるバージョンは常に同じ方法で分析します。

比較

2026年10月時点のスナップショットで、各プロジェクトのドキュメントに基づきます。