オープンソースの脆弱性を、
問題になる前に。
Open Source Component Analysis & Response
OSCARはビルドのたびにSBOM（ソフトウェア部品表）を収集し、サービスに含まれるオープンソースコンポーネントに既知の脆弱性がないかを継続的にチェックします。画面は自国語で表示され、「Criticalの脆弱性があるプロジェクトは？」とAIに普段の言葉で質問するだけで答えが得られます。
高リスクのプロジェクト 重大度別の脆弱な部品
新規検出 直近12週
- loan-batchCVE-2021-44228 · log4j-core 2.14.1Critical
- payment-apiCVE-2022-22965 · spring-beans 5.3.17Critical
ダッシュボード全プロジェクトのリスクをひと目で
AI問い合わせ質問するだけ。メニューを覚える必要なし
自社サービスの中身を、今すぐ説明できますか？
Log4Shellのようなオープンソースの脆弱性が公表されると、最初に問われるのは決まって「うちは使っているのか？」です。各チームが手作業でライブラリ一覧を洗い出している間も、時間は攻撃者に味方します。OSCARはその答えをあらかじめ用意しておきます。
| 項目 | これまで | OSCAR導入後 |
|---|---|---|
| 頻度 | 年1回の手作業による点検。その間に出た新しい脆弱性は見逃される | ビルドのたびにSBOMをアップロードし、新しい脆弱性の公表時にも再チェック |
| 方法 | 人がライブラリ一覧を目視で確認。漏れが出やすい | コンポーネント一覧を機械が脆弱性データベースと照合（名前・バージョン・ハッシュ） |
| 対応の速さ | 「使っているか」の確認だけで数日 | CVE 1件から影響を受ける全プロジェクトを即座に特定 |
| 画面 | 英語のみのツールで、業務部門には読みにくい | ローカライズされたUI。ライセンス全文は原文の隣に翻訳を表示 |
| 問い合わせ | 必要な表を得るためにメニューやフィルターを覚える | AIに普段の言葉で質問。47個のツールが検索を担当 |
画面イメージ
脆弱性を見つけるのは始まりにすぎません。OSCARはそれを読める形にし、誰が何をアップロードしたかを記録し、コンポーネントがどこから入り込んだかをたどります。以下の画面は架空のデータです。
└ spring-boot-starter-log4j2
└ log4j-core 2.14.1
主な機能
OSCARは実績あるオープンソースの分析エンジン（OWASP Dependency-Track）を改変せずに使い、その周りにチームが必要とする機能を加えます。
SBOMを自動生成 — 3種類のビルドに対応
Mavenはpomプラグイン、npmはアップロードスクリプト、Antやpom.xmlのない手動ビルドはssemsbom CLIで。ビルドが終わるとすぐにSBOMがアップロードされます。
継続的な検出
NVD、GitHub Advisory、OSV、Sonatype OSS Index、Trivyを併用。新しい脆弱性が公表されると、既存のコンポーネント一覧も再チェックします。
自然言語AI（MCP）
プロジェクト・脆弱性・コンポーネント・ポリシー・ライセンス・SBOMを扱う47個のツールをMCPで提供。ClaudeなどのAIクライアントや社内LLMから質問できます。
ローカライズUI · ライセンス翻訳
韓国語UIを標準搭載し、ライセンス全文はLLMによる翻訳を原文の隣に表示。社内LLM（Ollama、LM Studio）またはGeminiから選べます。
アップロード履歴 · 標準タグ
各SBOMを誰が、いつ、どのプロジェクトにアップロードしたかを記録。チーム・サービス種別・技術・ビルドツール・アプリケーションサーバーの標準タグで、数百のプロジェクトを整理できます。
素性の不明なレガシーJARも識別
ファイル名、pom.properties、MANIFEST、グループ推定、Vendor-Id、（任意で）Maven Centralのハッシュ照会の6段階で名前とバージョンを復元します。確信が持てない場合は推測しません。
導入と利用の流れ
開発者が新しいツールを覚える必要はありません。ビルドに1ステップ加えるだけで、結果は画面やAIから確認できます。
自社サーバーに導入
分析エンジンとデータベースはDocker、ゲートウェイとUIはTomcat 11で動作します。すべて社内ネットワークの中で完結します。
SBOMステップを追加
pomにはプラグイン、npmにはスクリプト、Antビルドにはssemsbomを1行。以降はビルドのたびに自動でアップロードされます。
脆弱性データを受信
脆弱性データベースは定期的に取り込みます。閉域網では、ネットワーク連携で受信方向だけを開放すれば済みます。
見る · 聞く · 直す
ダッシュボードでリスクを把握し、AIに影響範囲を尋ね、分析状態（調査中、影響なし）を記録します。
仕組み
すべての経路はOSCARゲートウェイ1か所を通ります。UI・ビルド・AIが分析エンジンを直接呼ぶことはないため、ゲートウェイで翻訳や履歴を付け加えられ、エンジンは手を加えずにアップグレードできます。
- 分析エンジンは改変しません。OSCARはOWASP Dependency-Trackの公式リリースをそのまま動かし、その前段のゲートウェイでレスポンスを変えます。エンジンをアップグレードしてもOSCARには影響しません。
- 翻訳はUIではなくゲートウェイで行います。そのため画面・AI・APIクライアントのいずれも、同じ翻訳済みテキストを受け取ります。
- MCPサーバーは各ユーザーのPCで動作します。AIクライアントが起動し、発行されたAPIキーでゲートウェイに接続します。AIはそのキーで許可された操作しかできません。
- 破線は受信方向のみです。脆弱性データはエンジンに流れ込みますが、コンポーネント一覧が社外に出ることはありません。
Dependency-Track 4.13
OWASPのオープンソース · Docker。SBOM分析、脆弱性・ポリシー・ライセンスの評価。
Java 21 · Tomcat 11
リクエスト中継、ライセンス翻訳、アップロード履歴。ローカライズUIと合わせて提供。
MCPサーバー · ツール47個
STDIOで動く単一のJava jar。Claude Desktop、Claude Codeなど各種MCPクライアントで使えます。
CycloneDX 1.5 · PURL
SBOMの国際標準（ECMA-424）。コンポーネントをPURLで識別し、脆弱性データと照合します。
セキュリティの原則
セキュリティツールが新たなリスクになってはならないため、まず次の線を引きました。
- 自社サーバーに導入するため、コンポーネント一覧や分析結果を外部クラウドに渡しません。
- アップロードするのはソースコードではなくコンポーネント一覧（SBOM）です。名前・バージョン・ハッシュのみです。
- 外部との接続は脆弱性データの取り込みだけなので、閉域網での承認も進めやすくなります。
- ライセンス翻訳に社内LLM（Ollama、LM Studio）を使えば、翻訳対象のテキストさえ社外に出ません。
- AIはツールを呼び出すだけで、独自に判断しません。回答は常にエンジンのデータに基づきます。
- AIのアクセスには専用のAPIキーを使い、そのキーの権限（参照、アップロードなど）を超えることはできません。
- 翻訳に失敗しても原文は表示されます。翻訳が原因で情報が消えることはありません。
- エンジンは実績あるオープンソースを改変せずに使い、OSCARはその前段に薄い層を加えるだけです。
動作要件
OSCARの稼働に必要なものです。
- 自社サーバー上のDocker（分析エンジン、PostgreSQL）とTomcat 11（Java 21）。分析エンジンには十分なメモリ（数GB以上）が必要です。
- 脆弱性データを受信するための、インターネットからの受信経路。閉域網では、ネットワーク連携で必要なアドレスのみを許可してください。
- SBOMはビルドで生成されるため、パイプライン（Maven、npm、Ant、手動ビルド）にSBOMステップを追加できる必要があります。
- メタデータを持たない商用・自社製のJARは識別できず、脆弱性照合の対象から漏れる場合があります。
- AI問い合わせにはMCP対応クライアントが必要です。社内LLMはツール呼び出し（Tool Calling）に対応している必要があります。
- ライセンスの翻訳は参考用です。法的な判断は原文に従ってください。