Open Source Supply Chain Risk

オープンソースのサプライチェーンリスク MCP

ApifyForge で表示 | Apify Store で使用

---

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf）に追加します：

{
  "mcpServers": {
    "open-source-supply-chain-risk-mcp": {
      "url": "https://ryanclinton--open-source-supply-chain-risk-mcp.apify.actor/mcp"
    }
  }
}

---

MCP を通じたオープンソースのサプライチェーンリスク分析により、AI エージェントは 7 つのライブインテリジェンスソースにある CVE レコード、CISA KEV の悪用情報、メンテナーのバス係数スコア、タイポスクワッティング検出に直接アクセスできます。AI クライアントを離れることなく、SBOM グレードのリスクインテリジェンスを必要とするセキュリティエンジニア、DevSecOps チーム、AI 支援ワークフロー向けに構築されています。

この MCP サーバーは、GitHub、NVD、CISA KEV、Hacker News、StackExchange、ArXiv、Censys に並列でクエリを実行する 8 つの専門ツールを提供し、結果を型付きの OSS 依存関係ネットワークグラフに統合します。プロセス内キャッシュの有効期間は 5 分のため、同じパッケージへの繰り返しのクエリに追加費用はかかりません。会話中に同じライブラリを再度参照するインタラクティブな AI セッションでも、実用的に利用できます。

どのようなデータにアクセスできますか？

データ項目	ソース	例
📦 リポジトリのメタデータ、スター数、フォーク数、言語	GitHub	pallets/flask、スター数 68k、Python
🔒 CVSS スコア付きの CVE レコード	NVD	CVE-2024-45805、CVSS 9.1、重大
🚨 現在悪用されている脆弱性	CISA KEV	CVE-2021-44228（Log4Shell）、CISA BOD 22-01 の拘束対象
👤 メンテナーの身元とバス係数	GitHub	アクティブなメンテナー 1 人、最後のプッシュから 18 か月
⚠️ タイポスクワッティング候補	GitHub の相互参照	reqeusts と requests、レーベンシュタイン距離 1
💬 サプライチェーンインシデントに関する議論	Hacker News	「xz-utils のバックドアが 5.6.0 で発見」
❓ 開発者の移行と採用の動向	StackExchange	「requests から httpx への移行 — セキュリティ上の懸念」
🔬 学術的なセキュリティ研究論文	ArXiv	「PyPI におけるタイポスクワッティング：体系的な調査（2024）」
🌐 インターネットに公開されたインフラの露出状況	Censys	脆弱な Log4j バージョンを実行するホスト
📊 依存関係ネットワークグラフ	すべてのソース	ノードとエッジ：リポジトリ、メンテナー、CVE、KEV、議論
🏥 コミュニティ健全性指数	GitHub + HN + SE	フォーク数／スター数の傾向、Issue 対応率、0～1 のスコア
📋 SBOM 対応のリスクレポート	7 つすべてのソース	深刻度と CISA の修復手順で分類された調査結果

Open Source Supply Chain Risk MCP を使う理由

OSS サプライチェーンの手動監査は、費用がかかり、時間もかかります。セキュリティエンジニアが推移的依存関係 50 件を手作業でレビューし、NVD との照合、GitHub のコミット履歴の確認、PyPI での類似パッケージのスキャンを行うには、2～3 日かかります。CISA KEV は毎日更新されます。ArXiv では毎週新しい脆弱性研究が公開されます。手作業でこれに追いつけるチームはありません。

この MCP はプロセス全体を自動化します。AI エージェントが 1 つのツールを呼び出すだけで、7 つのライブソースに基づくスコア付きのグラフ連携リスク評価を 30 秒以内に取得できます。単一パッケージのリスクスコア、影響範囲、メンテナーの健全性を含む完全なデューデリジェンスワークフローの費用は $0.105 です。商用の代替サービスは、はるかに高額です。

• 常に最新のデータ — 呼び出し時にライブ API にクエリを実行します。5 分の TTL キャッシュにより、セッション中の重複課金を防ぎます
• API アクセス — Claude Desktop、Cursor、Windsurf、Cline、または任意の HTTP MCP クライアントから接続できます
• 並列実行 — Promise.all を使用して 7 つのデータソースすべてを同時に実行します。通常、30 秒以内に応答します
• 監視 — Apify プラットフォームが実行失敗を通知します。Webhooks により、重大な KEV の検出時に Slack に通知できます
• 連携 — Zapier、Make、LangChain、LlamaIndex、または任意の言語からの直接 HTTP 呼び出しに接続できます

機能

• 型付き OSS 依存関係ネットワークグラフ — 複数のソースから統合したデータをもとに、7 種類のノード（repo、maintainer、cve、kev、package、discussion、paper、host）と 6 種類のエッジ（depends_on、maintains、affects、discusses、researches、hosts）からなるグラフを構築します。1 回の実行で最大 80 リポジトリ、60 件の CVE、40 件の KEV に対応します
• メンテナーのバスファクター評価 — リポジトリごとに確認済みの maintains エッジを数えます。バスファクターは min(1, maintainerCount / 5) です。pushedAt／updatedAt メタデータを用いた 730 日間の放棄減衰モデルにより、アクティビティの新しさも加味します
• CVE の影響範囲推定 — 各 CVE／KEV ノードから、すべてのエッジタイプを通じて深さ 6 まで BFS でグラフをたどります。到達した repo: プレフィックス付きノードを数え、blastRadius を追跡対象リポジトリ総数に対する 0〜1 の割合で報告します
• CISA KEV との相互参照 — KEV ノードには固定の深刻度 0.95 が設定され、多要素リスクスコアの active_exploitation 要素に重み 0.9 が適用されます。CISA BOD 22-01 に準拠した修復ガイダンスを自動生成します
• 5 要素の重み付きサプライチェーンリスクスコア — 脆弱性への露出（30％）、バスファクター（20％）、悪用の活発さ（20％）、人気度／攻撃対象領域（15％）、コミュニティのシグナル（15％）。リスクレベルのしきい値は 0.75／0.50／0.25 です
• レーベンシュタイン距離によるタイポスクワット検出 — 検出されたすべてのリポジトリの短縮名を対象に、O(n²) のペアワイズ編集距離を計算します。距離が 1〜2 で、スター比率が 0.3 未満のペアを疑い度が高いものとしてフラグ付けします。疑い度の計算式は (1 - dist/3) * 0.5 + (1 - starRatio) * 0.5 で、「疑わしい」と判定するしきい値は 0.6 です
• コミュニティ健全性のインデックス化 — フォーク数とスター数の比率を感情の代理指標として、Issue 数とスター数の比率を対応品質の指標として使用し、さらに Hacker News／StackExchange の議論量を組み合わせて、リポジトリごとに 0〜1 の健全性インデックスを算出します
• セキュリティ研究動向の追跡 — ArXiv のタイトルと HN の投稿から 13 個のセキュリティトピックのキーワードを抽出します。トレンドスコアは直近 90 日間の論文数／論文総数です。正式な CVE 割り当ての通常 4〜8 週間前に現れる、開示前の脅威研究を明らかにします
• SBOM を考慮したレポート生成 — 検出事項を既知の悪用脆弱性、重大な CVE（CVSS ≥ 9.0）、バスファクターリスク（メンテナー ≤ 1）に分類します。深刻度順に並べ、各検出事項の根拠を示す文字列と、実行可能な修復の推奨事項を提示します
• プロセス内 5 分間キャッシュ — source:query をキーにした Map ベースの TTL キャッシュです。同一セッション内で同じパッケージに対する複数のツール呼び出しは、上流のデータを再利用してほぼ即時に結果を返します
• デュアル MCP トランスポート — 旧式クライアント向けの SSE トランスポート（/sse + /messages）と、最新のクライアント向けの Streamable HTTP（/mcp）に対応します。レディネスプローブ用の /health エンドポイントも提供します
• ツールごとのソース設定 — すべてのツールで sources 配列を指定できます。デフォルト値はツールごとに調整されており、generate_oss_risk_report では 7 つすべて、assess_research_security_landscape では arxiv + hackernews + stackexchange が使用されます

オープンソースのサプライチェーンリスクに関するユースケース

DevSecOps パイプラインのセキュリティゲート

プラットフォームエンジニアリングチームが、この MCP を Claude ベースのコードレビュ―エージェントに統合します。新しい npm 依存関係を追加する PR をマージする前に、エージェントはパッケージ名を指定して score_supply_chain_risk を呼び出します。スコアが 0.6 を超える場合、または関連する KEV ノードが 1 つでもある場合は、セキュリティ責任者が承認するまで PR をブロックします。ゲート全体は 30 秒以内に実行でき、チェック 1 回あたりの費用は $0.035 です。誤検知によるインシデントに比べて、はるかに低コストです。

SBOM 監査とベンダーリスク管理

SaaS ベンダーを評価する調達チームが、ベンダーの申告した主要な依存関係を対象に generate_oss_risk_report を実行するよう、AI アシスタントに依頼します。レポートには、CISA KEV に掲載されたサードパーティライブラリの脆弱性、放棄のリスクがある単独メンテナーのリポジトリ、CISA BOD 22-01 に沿った SBOM の修復手順が示されます。以前は手作業の調査に 1 週間かかっていたデューデリジェンスが、AI との 1 回の会話で完了します。

インシデント対応のトリアージ

Log4Shell クラスの新たな重大な CVE が公表されると、インシデント対応チームは CVE 識別子を指定して detect_vulnerability_propagation を呼び出します。影響範囲の分析により、影響を受けるパッケージに依存している内部リポジトリと、依存関係グラフを通じた伝播の深さが明らかになります。これにより、チームは緊急パッチが必要なシステムと、その優先順位をすぐに把握できます。

採用前のパッケージ審査

3 つの候補ライブラリを評価するエンジニアリングリードは、それぞれに対して assess_maintainer_risk を呼び出します。2 つはバス係数が 0.4 を超え、最近も活動があります。残る 1 つはメンテナーが 1 人だけで、最後のプッシュは 18 か月前、放棄リスクは 0.82 です。チームは、より健全な代替候補の 1 つを選びます。合計コストの $0.105 は、削減できるエンジニアリング時間に比べればごくわずかです。

サプライチェーン攻撃の早期警告

OSS エコシステムを監視するセキュリティ研究チームは、テクノロジースタックのキーワードを指定して、assess_research_security_landscape を毎週呼び出します。npm サプライチェーン攻撃に関する新しい ArXiv 論文が注目を集めたり、特定のパッケージをめぐる Hacker News の議論が急増したりすると、正式な CVE 公表前にアラートを受け取れます。研究論文の公表は、平均して CVE の割り当てより数週間先行します。

パッケージレジストリのタイポスクワット監視

レジストリのセキュリティチームは、detect_typosquat_indicators を使って、最近公開されたパッケージを人気パッケージのカタログと照合します。Levenshtein エンジンが、colourama（colorama に対するもの）や reqeusts（requests に対するもの）など、疑わしさのスコアが高い候補を検出します。フラグが付いたパッケージは、開発者のマシンに届く前に隔離され、手動で審査されます。

この MCP サーバーへの接続方法

1. Apify API トークンを取得します。 apify.com でサインアップし、アカウント設定からトークンをコピーします。無料プランには月額 $5 分のクレジットが含まれており、およそ 140 回のツール呼び出しに利用できます。

2. MCP クライアントにサーバーを追加します。 Streamable HTTP エンドポイント https://open-source-supply-chain-risk-mcp.apify.actor/mcp を使用します。トークンは Authorization: Bearer ヘッダーで渡します。クライアントごとの設定については、以下の API セクションを参照してください。

3. generate_oss_risk_report から始めます。 評価したいパッケージ名またはリポジトリ名を指定して呼び出します。レポートは 7 つのソースすべてを照会し、重大度順に並べた調査結果を 1 回の呼び出しで返します。

4. 用途に応じたツールで詳細を確認します。 レポートでリスクの高いメンテナーが見つかった場合は、assess_maintainer_risk を呼び出して追加調査します。KEV がある場合は、detect_vulnerability_propagation を呼び出して影響範囲を把握します。各用途に応じた呼び出しでは、ステップ 3 でキャッシュされた上流データが再利用されます。

MCP ツール

ツール	価格	デフォルトのソース	説明
map_dependency_network	$0.035	github, cve, kev, hackernews	OSS 依存関係グラフをマッピング：ノード、エッジ、接続数
assess_maintainer_risk	$0.035	github, cve, kev, hackernews	リポジトリごとのバス係数、放棄リスク、最終活動日
detect_vulnerability_propagation	$0.035	github, cve, kev, hackernews	依存関係グラフを BFS でたどり、CVE/KEV の影響範囲を特定
analyze_community_health	$0.035	github, cve, kev, hackernews	フォーク／スターの傾向、課題への対応、議論の量
score_supply_chain_risk	$0.035	github, cve, kev, hackernews, stackexchange	要因ごとの内訳を含む、5 要因の加重リスクスコア
detect_typosquat_indicators	$0.035	github, cve, kev, hackernews	Levenshtein 距離とスター比率による、パッケージペアごとのタイポスクワット分析
assess_research_security_landscape	$0.035	arxiv, hackernews, stackexchange	ArXiv 論文の動向とコミュニティでの議論の兆候
generate_oss_risk_report	$0.035	7 つすべてのソース	調査結果と推奨事項を含む、SBOM を考慮した包括的なレポート

ツールのパラメーター

すべてのツールは、同じ2つのパラメーターを受け取ります。

パラメーター	型	必須	デフォルト	説明
query	string	はい	—	調査するパッケージ名、リポジトリのスラッグ、またはOSSプロジェクト（例：log4j、pallets/flask、numpy）
sources	array of enum	いいえ	ツールによって異なります	クエリ対象のデータソース。選択肢：github、cve、kev、hackernews、stackexchange、arxiv、censys

入力例

単一パッケージのリスクスコア（最も一般的）：

{
  "query": "log4j",
  "sources": ["github", "cve", "kev", "hackernews", "stackexchange"]
}

すべてのソースを対象とした完全なSBOMリスクレポート：

{
  "query": "com.fasterxml.jackson.core:jackson-databind",
  "sources": ["github", "cve", "kev", "hackernews", "stackexchange", "arxiv", "censys"]
}

高速なタイポスクワットチェック（GitHubのみ）：

{
  "query": "requests",
  "sources": ["github"]
}

技術エコシステムの研究動向：

{
  "query": "npm supply chain",
  "sources": ["arxiv", "hackernews", "stackexchange"]
}

入力のヒント

• 正確なパッケージ名を使用してください — log4j-core は、java logging のような一般的な用語よりも正確なCVE照合結果を返します
• score_supply_chain_risk から始めてください — 詳細な分析が必要か判断できるよう、要因の内訳とともに0～1のスコアを返します
• KEVで確認済みのパッケージにのみ censys を追加してください — Censysへのクエリは他のソースより時間がかかるため、実際の悪用がすでに確認されているパッケージに限定してください
• 情報公開前の脅威ハンティングには arxiv を使用してください — 特定のエコシステム（npm、PyPI、Maven）に関する研究論文は、正式なCVE割り当ての4～8週間前に公開されることがよくあります
• 同じパッケージに対する呼び出しをまとめるよう、AIセッションを構成してください — 5分間のキャッシュにより、セッション中に同じクエリで2回目のツールを呼び出すと、上流のデータが再利用され、費用はイベント料金の$0.035のみになります

出力例

score_supply_chain_risk の応答

{
  "assessments": [
    {
      "entity": "apache/log4j",
      "riskScore": 0.8125,
      "riskLevel": "critical",
      "factors": [
        { "factor": "vulnerability_exposure", "weight": 0.30, "score": 1.0 },
        { "factor": "bus_factor",             "weight": 0.20, "score": 0.6 },
        { "factor": "popularity",             "weight": 0.15, "score": 0.12 },
        { "factor": "active_exploitation",    "weight": 0.20, "score": 0.9 },
        { "factor": "community_signal",       "weight": 0.15, "score": 0.3 }
      ]
    },
    {
      "entity": "apache/log4j-extras",
      "riskScore": 0.4830,
      "riskLevel": "high",
      "factors": [
        { "factor": "vulnerability_exposure", "weight": 0.30, "score": 0.4 },
        { "factor": "bus_factor",             "weight": 0.20, "score": 0.8 },
        { "factor": "popularity",             "weight": 0.15, "score": 0.35 },
        { "factor": "active_exploitation",    "weight": 0.20, "score": 0.1 },
        { "factor": "community_signal",       "weight": 0.15, "score": 0.7 }
      ]
    }
  ],
  "avgRisk": 0.6478,
  "criticalCount": 1
}

generate_oss_risk_report の応答

{
  "overallRisk": "critical",
  "reposScreened": 14,
  "findings": [
    {
      "category": "Known Exploited Vulnerabilities",
      "finding": "2 CISA KEV-listed vulnerability(ies) in OSS dependencies",
      "severity": "critical",
      "evidence": "CVE-2021-44228, CVE-2021-45046",
      "recommendation": "Immediate dependency update or mitigation per CISA BOD 22-01"
    },
    {
      "category": "Critical CVEs",
      "finding": "3 critical vulnerability(ies) affecting tracked repositories",
      "severity": "critical",
      "evidence": "CVE-2021-44228, CVE-2022-23302, CVE-2019-17571",
      "recommendation": "Emergency patching and dependency lockfile review"
    },
    {
      "category": "Bus Factor Risk",
      "finding": "5 repo(s) with single-maintainer bus factor",
      "severity": "high",
      "evidence": "log4j-extras, log4j-scan, log4j-detector",
      "recommendation": "Identify backup maintainers or fork critical single-maintainer dependencies"
    }
  ],
  "recommendations": [
    "SBOM audit and KEV remediation",
    "Automated dependency scanning in CI/CD",
    "Maintainer diversity programme for critical dependencies"
  ]
}

detect_typosquat_indicators の応答

{
  "indicators": [
    {
      "package": "reqeusts",
      "similarTo": "requests",
      "editDistance": 1,
      "starRatio": 0.0002,
      "suspicionScore": 0.8332
    },
    {
      "package": "colourama",
      "similarTo": "colorama",
      "editDistance": 2,
      "starRatio": 0.0041,
      "suspicionScore": 0.6620
    }
  ],
  "totalChecked": 28,
  "suspiciousCount": 2,
  "avgSuspicion": 0.4812
}

detect_vulnerability_propagation の応答

{
  "propagations": [
    {
      "cve": "CVE-2021-44228",
      "severity": 1.0,
      "affectedRepos": 11,
      "propagationDepth": 4,
      "blastRadius": 0.7857
    },
    {
      "cve": "CVE-2022-23302",
      "severity": 0.88,
      "affectedRepos": 3,
      "propagationDepth": 2,
      "blastRadius": 0.2143
    }
  ],
  "totalVulns": 5,
  "criticalCount": 2,
  "avgBlastRadius": 0.3820
}

出力フィールド

score_supply_chain_risk

フィールド	型	説明
assessments[].entity	string	リポジトリ名（最大50文字）
assessments[].riskScore	number	重み付けされた総合リスクスコア、0～1
assessments[].riskLevel	string	low / medium / high / critical
assessments[].factors[].factor	string	要因名：vulnerability_exposure、bus_factor、popularity、active_exploitation、community_signal
assessments[].factors[].weight	number	総合スコアにおける要因の重み
assessments[].factors[].score	number	要因の生スコア、0～1
avgRisk	number	評価したすべてのリポジトリの平均リスクスコア
criticalCount	number	リスクレベルがcriticalのリポジトリ数

generate_oss_risk_report

フィールド	型	説明
findings[].category	string	検出事項のカテゴリ（例：既知の悪用された脆弱性）
findings[].finding	string	人が読める形式の検出事項の概要
findings[].severity	string	low / medium / high / critical
findings[].evidence	string	裏付けとなるCVE IDまたはリポジトリ名
findings[].recommendation	string	実行可能な修正手順
overallRisk	string	レポート全体のリスクレベル
reposScreened	number	分析したリポジトリ数
recommendations	array	最上位の修正推奨事項のリスト

detect_typosquat_indicators

フィールド	型	説明
indicators[].package	string	タイポスクワットの疑いがあるパッケージ名
indicators[].similarTo	string	似ている人気パッケージ
indicators[].editDistance	number	レーベンシュタイン編集距離（1または2）
indicators[].starRatio	number	stars(suspect) / stars(popular)、0～1
indicators[].suspicionScore	number	疑わしさの合計スコア、0～1
totalChecked	number	比較したリポジトリ名の合計数
suspiciousCount	number	suspicionScore が0.6を超える件数
avgSuspicion	number	すべての指標の平均疑わしさスコア

detect_vulnerability_propagation

フィールド	型	説明
propagations[].cve	string	CVE または KEV 識別子
propagations[].severity	number	CVSS から算出した重大度、0-1
propagations[].affectedRepos	number	BFS で到達可能な下流リポジトリ数
propagations[].propagationDepth	number	到達した BFS の深さ（最大 6）
propagations[].blastRadius	number	affectedRepos / totalRepos、0-1
totalVulns	number	分析した CVE + KEV ノードの合計
criticalCount	number	重大度が 0.8 を超える伝播の数
avgBlastRadius	number	すべての脆弱性の平均ブラスト半径

assess_maintainer_risk

フィールド	型	説明
risks[].repo	string	リポジトリ名
risks[].maintainerCount	number	確認済みのメンテナー関係の数
risks[].busFactor	number	min(1, maintainerCount / 5)、0-1
risks[].lastActivity	string	最後のプッシュ日（ISO 日付形式、YYYY-MM-DD）
risks[].abandonmentRisk	number	バス係数と最近の活動状況を組み合わせたスコア、0-1
totalRepos	number	評価したリポジトリの合計
highRiskCount	number	abandonmentRisk が 0.6 を超えるリポジトリ数
avgBusFactor	number	すべてのリポジトリの平均バス係数

map_dependency_network

フィールド	型	説明
entries[].entity	string	ノード名（リポジトリ、CVE、メンテナーなど）
entries[].type	string	ノードの種類：repo、maintainer、cve、kev、package、discussion
entries[].connections	number	エッジの合計数（入方向 + 出方向）
entries[].stars	number	スター数（リポジトリのみ。他の種類では 0）
entries[].severity	number	CVSS 重大度 0-1（CVE/KEV ノードのみ）
totalEntities	number	ネットワーク内のノードの合計
totalEdges	number	ネットワーク内のエッジの合計
avgConnections	number	すべてのノードの平均エッジ次数

analyze_community_health

フィールド	型	説明
assessments[].repo	string	リポジトリ名
assessments[].discussionVolume	number	このリポジトリに関連付けられた Hacker News/StackExchange の議論数
assessments[].sentimentScore	number	フォーク数とスター数の比率に基づく指標、0-1
assessments[].issueResponseTime	number	イシュー数とスター数の逆比率に基づく指標、0-1
assessments[].healthIndex	number	複合的な健全性スコア、0-1
totalAssessed	number	評価したリポジトリの合計
unhealthyCount	number	healthIndex が 0.3 未満のリポジトリ数
avgHealth	number	すべてのリポジトリの平均健全性指標

assess_research_security_landscape

フィールド	型	説明
topics[].topic	string	セキュリティトピックのキーワード
topics[].paperCount	number	このトピックに言及している論文と議論の合計数
topics[].recentActivity	number	過去 90 日間に公開された論文と議論の数
topics[].trendScore	number	recentActivity / paperCount、0-1
topics[].keyFindings	array	代表的な論文または議論のタイトル（最大 3 件）
totalPapers	number	分析した論文と議論の合計
trendingCount	number	trendScore が 0.5 を超えるトピック数
avgTrend	number	すべてのトピックの平均トレンドスコア

オープンソースのサプライチェーンリスク分析の実行には、どのくらいの費用がかかりますか？

この MCP はイベントごとの従量課金制です。ツール呼び出し1回あたり 0.035 ドルをお支払いいただきます。プラットフォームのコンピューティング費用も含まれています。

シナリオ	ツール呼び出し数	1回あたりの費用	合計費用
簡易テスト（単一パッケージのリスクスコア）	1	$0.035	$0.035
完全なリスクレポート（7つすべてのソース）	1	$0.035	$0.035
包括的なデューデリジェンス（スコア＋メンテナー＋影響範囲）	3	$0.035	$0.105
20個のパッケージを毎日監視	20	$0.035	$0.70
100個の依存関係を毎週完全監査	100	$0.035	$3.50

費用を管理するため、実行ごとに最大支出額を設定できます。予算に達するとアクターが停止するため、長時間の AI セッション中に予期しない請求が発生するのを防げます。

Snyk の月額 $25-98 や、エンタープライズチーム向けの Mend（WhiteSource）の年間 $10k 以上と比べてみてください。この MCP で OSS のサプライチェーンチェックを実行するほとんどのユーザーは、サブスクリプション契約なしで月額 $5 未満に収まっています。Apify の無料プランには月額 $5 分のクレジットが含まれており、月におよそ 140 回のツール呼び出しをまかなえます。

API を使用した接続方法

Claude Desktop

claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "open-source-supply-chain-risk": {
      "url": "https://open-source-supply-chain-risk-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Python

import httpx, json

MCP_URL = "https://open-source-supply-chain-risk-mcp.apify.actor/mcp"
TOKEN   = "YOUR_APIFY_TOKEN"

payload = {
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
        "name": "generate_oss_risk_report",
        "arguments": {
            "query": "log4j",
            "sources": ["github", "cve", "kev", "hackernews", "stackexchange", "arxiv", "censys"]
        }
    },
    "id": 1
}

response = httpx.post(
    MCP_URL,
    json=payload,
    headers={"Authorization": f"Bearer {TOKEN}", "Content-Type": "application/json"},
    timeout=60
)

result = response.json()
report = json.loads(result["result"]["content"][0]["text"])

print(f"Overall risk: {report['overallRisk']}")
print(f"Repos screened: {report['reposScreened']}")
for finding in report["findings"]:
    print(f"[{finding['severity'].upper()}] {finding['category']}: {finding['finding']}")

JavaScript

const MCP_URL = "https://open-source-supply-chain-risk-mcp.apify.actor/mcp";
const TOKEN   = "YOUR_APIFY_TOKEN";

const response = await fetch(MCP_URL, {
    method: "POST",
    headers: {
        "Authorization": `Bearer ${TOKEN}`,
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        jsonrpc: "2.0",
        method: "tools/call",
        params: {
            name: "score_supply_chain_risk",
            arguments: {
                query: "axios",
                sources: ["github", "cve", "kev", "hackernews", "stackexchange"]
            }
        },
        id: 1
    })
});

const data = await response.json();
const result = JSON.parse(data.result.content[0].text);

for (const assessment of result.assessments) {
    console.log(`${assessment.entity}: ${assessment.riskLevel} (${assessment.riskScore.toFixed(3)})`);
}
console.log(`Critical packages: ${result.criticalCount}`);

cURL

# Call score_supply_chain_risk
curl -X POST "https://open-source-supply-chain-risk-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "score_supply_chain_risk",
      "arguments": {
        "query": "express",
        "sources": ["github", "cve", "kev", "hackernews", "stackexchange"]
      }
    },
    "id": 1
  }'

# List all available tools
curl -X POST "https://open-source-supply-chain-risk-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}'

Open Source Supply Chain Risk MCP の仕組み

フェーズ 1：キャッシュを利用した並列データ収集

ツールが呼び出されると、サーバーはMapベースのプロセス内キャッシュを使って、各source:query複合キーを確認します。キャッシュエントリーの有効期間は5分です（TTL = 300,000 ms）。キャッシュミスが発生すると、サーバーは必要な Apify ラッパーアクターを並列で呼び出します。Promise.allを介して最大7つを同時に実行します。各ラッパーアクターは180秒のタイムアウトで実行され、Apify データセットから最大500件の項目を返します。

7つのデータソースアクター：

• github — ryanclinton/github-repo-search — fullName、stars、owner、language、pushedAt、forksCount、openIssuesCountなど、リポジトリのメタデータを返します
• cve — ryanclinton/nvd-cve-vulnerability-search — cveId、cvssScore、description、影響を受ける構成を含む CVE レコードを返します
• kev — ryanclinton/cisa-kev-search — cveIDと悪用が確認された状況を含む CISA KEV エントリーを返します
• hackernews — ryanclinton/hackernews-search — サプライチェーンに関する議論の投稿タイトルとメタデータを返します
• stackexchange — ryanclinton/stackexchange-search — 開発者の採用状況や移行パターンを示す質問タイトルを返します
• arxiv — ryanclinton/arxiv-paper-search — 新たな脅威に関する研究論文のタイトルと公開日を返します
• censys — ryanclinton/censys-search — インターネットに公開されたインフラの露出状況を示すホストレコードを返します

フェーズ 2：型付きネットワークグラフの構築

dependency-network.tsのbuildOSSNetwork()は、すべてのソースの結果を型付きグラフに統合します。最大80個のリポジトリが、スター数と生のメタデータを持つrepoノードになります。各リポジトリの所有者はmaintainerノードとなり、重み0.9のmaintainsエッジで接続されます。リポジトリの言語はpackageノードとなり、重み0.5のdepends_onエッジで接続されます。

CVE ノードは、CVE の説明文を部分文字列検索してリポジトリ名と相互参照されます（3文字を超えるリポジトリの短縮名が対象です）。一致すると、重み0.7のaffectsエッジが作成されます。KEV ノードは対応する CVE ノードに重み1.0で接続され、影響範囲分析で CVE から KEV までを完全にたどれるようになります。

Hacker News と StackExchange の項目はdiscussionノードになります。議論のタイトルをリポジトリの短縮名（/の後の部分）と照合し、重み0.5のdiscussesエッジを作成します。ArXiv の論文はpaperノードとなり、研究動向を分析する関数で処理されます。

フェーズ 3：分析モデルの適用

8 つのツールはそれぞれ、統合ネットワークグラフに異なるモデルを適用します。

score_supply_chain_risk — repo ノードごとに 5 要素の重み付き計算式を適用します。脆弱性への露出度 = min(1, vulnLinks * 0.2)。バスファクター = max(0, 1 - maintainerCount * 0.2)。人気度 = 1 - min(1, log10(max(1, stars)) / 5)。KEV ノードがリンクされている場合、実際の悪用状況は 0.9、それ以外は 0.1 です。コミュニティシグナルは、ディスカッションが存在する場合は 0.3、それ以外は 0.7 です。リスクレベルのしきい値：critical ≥ 0.75、high ≥ 0.50、medium ≥ 0.25。

detect_vulnerability_propagation — 各 CVE/KEV ノードから、エッジ一式（6 種類すべてのエッジ）を通じて深さ 6 まで幅優先探索（BFS）を行います。到達した repo: で始まるノード ID の数をカウントします。影響範囲 = 影響を受けるリポジトリ数 / リポジトリノードの総数。

detect_typosquat_indicators — すべての repo の短縮名（/ で分割し、小文字に変換）について、Levenshtein 距離を O(n²) でペアごとに計算します。距離が 1～2 で、絶対長差が ≤ 2 のペアを評価します。各ペアでは、スター数が少ない方のリポジトリを suspicious パッケージとします。結果は疑わしさスコアの降順に並べ替えられ、上位 20 件が返されます。

generate_oss_risk_report — 次の 3 つのカテゴリーで調査結果を統合します。KEV が存在する場合は、CISA BOD 22-01 のガイダンスを含む critical の調査結果が発生します。CVSS ≥ 9.0 の CVE（正規化後の severity ≥ 0.9）がある場合は、critical の調査結果が発生します。maintains エッジが ≤ 1 のリポジトリが 3 件を超える場合は、high の調査結果が発生します。調査結果は {critical: 0, high: 1, medium: 2, low: 3} の列挙順で並べ替えられます。

フェーズ 4：レスポンスの組み立て

すべてのツールは、type: "text" を含む MCP の content 配列でラップされた構造化 JSON を返します。ほとんどのツールでは、LLM に適したレスポンスペイロードを保つため、結果は 30 件までに制限されます。サーバーは上流のアクターの失敗を適切に処理します。アクターが失敗またはタイムアウトした場合は空の配列を返し、残りのソースを使って分析を続行します。

最良の結果を得るためのヒント

1. 最初に generate_oss_risk_report を実行してください。 1 回 $0.035 の呼び出しで 7 つすべてのソースを照会し、重大度順に並べた調査結果を返します。調査結果を参考に、次に呼び出す重点ツールを決めてください。レポートで詳しく調査する価値のあるリスクカテゴリーが特定された場合にのみ、ツールごとに追加で $0.035 を費やします。

2. プロジェクト名ではなく、正確なパッケージ名で照会してください。 log4j-core は log4j より多くの CVE の説明に一致します。pallets/flask を指定すると、似た名前の無関係なリポジトリにも一致する可能性がある flask だけを指定するより、正しいリポジトリをすばやく見つけられます。

3. 5 分間のキャッシュを計画的に活用してください。 同じパッケージに対して 5 分以内に score_supply_chain_risk を呼び出した後で assess_maintainer_risk を呼び出すと、2 回目の呼び出しではキャッシュされた上流データが再利用され、料金は $0.035 のイベント料金のみになります。同じパッケージへの呼び出しをまとめるように、AI セッションを構成してください。

4. censys を追加するのは、KEV で確認済みの脆弱性がある場合に限ってください。 Censys のデータは、脆弱なバージョンが実環境にどのように導入されているかを把握するのに役立ちますが、呼び出しの遅延が増加します。レポートで実際の悪用がすでに確認されたパッケージに限って使用してください。

5. 情報公開前の脅威ハンティングには arxiv を使用してください。 特定のエコシステム（npm、PyPI、Maven Central）に関する研究論文は、正式な CVE 割り当てより 4～8 週間前に公開されることがよくあります。assess_research_security_landscape を週次でスケジュール実行すれば、セキュリティチームに新たな攻撃パターンを事前に警告できます。

6. typosquat の結果は、ブロックする前に必ず手動で照合してください。 Levenshtein アルゴリズムが検出するのは統計的な異常であり、マルウェアが確認されたわけではありません。疑わしさの高いパッケージを CI/CD のブロックリストに追加する前に、必ずレジストリページで確認してください。人気ライブラリの新しい正当なフォークも、この指標では typosquat とまったく同じように見えます。

7. エコシステムの監視にはブロードキャストクエリを使用してください。 npm、PyPI、Maven などのクエリは、多様なリポジトリや CVE を返すため、単一パッケージのクエリより広範な依存関係ネットワークのマッピングが可能になります。エコシステム全体を対象とした定期的なリスク評価に役立ちます。

他の Apify アクターとの組み合わせ

アクター	組み合わせ方
Website Tech Stack Detector	ベンダーのウェブサイトで使用されている OSS ライブラリを検出し、そのライブラリ名を score_supply_chain_risk に渡して、すぐにリスクを評価します
Company Deep Research	サードパーティのデューデリジェンスのワークフローで、ベンダーの OSS サプライチェーンリスクを、より幅広い企業情報と組み合わせます
WHOIS Domain Lookup	不審なタイポスクワッティングパッケージのドメインをドメイン登録データと照合し、悪意のある所有パターンを特定します
Website Content to Markdown	ベンダーのセキュリティ勧告ページを Markdown に変換し、MCP のリスクデータとともに AI エージェントに渡して、総合的に評価します
Trustpilot Review Analyzer	レビュープラットフォームの開発者コミュニティによる信頼性の指標を OSS サプライチェーンリスクスコアと組み合わせ、ベンダーをより包括的に評価します
B2B Lead Qualifier	提携評価に投資する前に、OSS 依存関係の健全性に基づいて、提携候補となる技術パートナーを審査します
Website Change Monitor	ベンダーのセキュリティ勧告ページの変更を監視し、新しい勧告が現れたら generate_oss_risk_report を自動的に実行します

制限事項

• 静的コード解析には対応していません — サーバーが解析するのはリポジトリのメタデータ、脆弱性データベース、コミュニティの指標であり、ソースコードではありません。コードレベルの SAST スキャンには、この MCP と併せて Semgrep や CodeQL などの専用ツールを使用してください。
• リポジトリの検出は GitHub が中心です — 依存関係グラフは GitHub の検索結果から作成されます。プライベートパッケージ、内部ミラー、GitHub での存在感が小さいレジストリ（プライベートな npm スコープ、内部 Maven リポジトリなど）は検出されません。
• 推移的な依存関係の解決には対応していません — サーバーは検索語に関連するリポジトリを特定しますが、依存関係ツリー全体を再帰的にたどるために package.json、requirements.txt、pom.xml を解析することはありません。
• レーベンシュタイン距離によるタイポスクワッティングの検出には複数の結果が必要です — タイポスクワッティング分析では、検索結果セット内のパッケージを比較します。検索結果が 5 件未満の場合、ペアごとの網羅性が限られます。より網羅的に調べるには、単一パッケージの検索ではなく、エコシステム単位のクエリ（requests python など）を使用してください。
• CVE とリポジトリの照合はテキストベースです — サーバーは CVE の説明文に含まれるテキストとリポジトリの短い名前を部分文字列として照合します。一般的な名前（core、utils など）のリポジトリは、CVE との誤った関連付けが発生する可能性があります。名前が CVE のテキストに一度も現れないリポジトリは、実際に影響を受けていても、脆弱性の影響がないものとして表示されます。
• Censys のデータはスキャン時点のスナップショットを反映します — Censys の結果は、スキャン時に検出されたホストを示すもので、リアルタイムのデプロイ状況一覧ではありません。迅速にパッチが適用されたデプロイ環境は、スキャン結果にまだ反映されていない場合があります。
• キャッシュはインスタンスごとです — 5 分の TTL キャッシュはプロセス内メモリに保存されます。新しい Apify Standby インスタンスは、起動時にキャッシュが空の状態です。同時に多数の AI セッションが実行される高並行性の環境では、複数のインスタンスでキャッシュミスが発生し、コストが増加する場合があります。
• ソースごとに最大 500 件です — 各アップストリームアクターが返すアイテムは最大 500 件です。linux や openssl などの非常に人気のあるパッケージには、関連リポジトリや CVE が数千件存在する場合があります。分析対象はソースごとに最初の 500 件に限られます。

インテグレーション

• Apify API — /mcp エンドポイントに直接 HTTP POST することで、あらゆる言語からこの MCP サーバーをプログラムで呼び出せます
• Webhooks — 監視対象のパッケージに対して generate_oss_risk_report が overallRisk: critical を返した際に、Slack または PagerDuty のアラートをトリガーします
• Zapier — コードを記述せずに、CISA KEV カタログへの新たな追加項目を、自動化されたサプライチェーンリスクスコアリングのワークフローに接続できます
• Make — 複数ステップのセキュリティワークフローを構築できます。新しい CVE を検出し、影響を受けるパッケージをスコアリングし、リスクの高い検出結果に対して Jira チケットを作成します
• LangChain / LlamaIndex — この MCP を LLM エージェントで呼び出し可能なツールとして統合し、セキュリティ調査と依存関係の審査のパイプラインを自動化できます
• Claude Desktop — MCP URL を claude_desktop_config.json に追加すると、Claude でサプライチェーンリスクについて直接対話できます

トラブルシューティング

• ツールが空の assessments 配列を返す — クエリに一致する GitHub リポジトリが見つかりませんでした。org.apache.logging.log4j:log4j-core ではなく log4j のように、短い、または一般的なクエリを試してください。ほとんどの分析ツールでは評価の生成に repo ノードが必要なため、sources 配列に github が含まれていることを確認してください。

• タイポスクワッティング分析で指標が表示されない — 検索結果が 2 件未満のリポジトリだったため、ペアごとの比較ができませんでした。エコシステムやパッケージファミリーに一致する、より広範なクエリを使用してください。たとえば colorama では、人気のパッケージに加えて、比較対象となる関連プロジェクトも見つかります。

• 既知の脆弱なパッケージのリスクスコアが予想より低い — CVE とリポジトリの照合はテキストベースのため、CVE の説明文にリポジトリ名が含まれていないパッケージを見落とすことがあります。特定の脆弱性ノードを基準に分析するには、CVE ID をクエリとして detect_vulnerability_propagation を直接呼び出してみてください（例：CVE-2021-44228）。

• ツール呼び出しがタイムアウトする — 上流の 7 つのアクターのいずれかが、180 秒のタイムアウト内に応答しませんでした。サーバーは失敗したアクターに対して空の配列を返すため、部分的な結果は引き続き返されます。呼び出しを再試行してください。遅延が継続的な制約になる場合は、sources を最速の 4 つ（github、cve、kev、hackernews）に減らしてください。

• ツールの応答に spending limit reached エラーが表示される — Apify アカウントが、実行ごとの支出上限または月間クレジット上限に達しました。Apify Console でクレジットを追加するか、支出上限を引き上げてください。5 ドルの無料枠では、月におよそ 140 回のツール呼び出しが可能です。

責任ある利用

• この MCP は、公開データベース（NVD、CISA KEV、GitHub の公開リポジトリ、ArXiv、Hacker News、StackExchange、Censys）で公開されているデータのみを取得します。
• NVD と CISA KEV は、セキュリティ調査と修正を目的として提供されている、米国政府の公式データベースです。
• 評価する権限のないシステムの脆弱性を特定するために、このツールを使用しないでください。
• タイポスクワッティングの検出結果は統計的な指標であり、悪意のあるパッケージであると確認されたことを示すものではありません。レーベンシュタイン距離のスコアだけを根拠に、パッケージ作成者を悪意があると公に非難しないでください。
• ウェブスクレイピングとデータ収集の適法性に関するガイダンスは、Apify のガイドをご覧ください。

FAQ

オープンソースのサプライチェーンリスクを完全に監査するには、ツール呼び出しが何回必要ですか？ 1 つのパッケージを徹底的に監査する場合、通常は 3～4 回のツール呼び出しが必要です。概要の確認には generate_oss_risk_report（0.035 ドル）、要因ごとの内訳には score_supply_chain_risk（0.035 ドル）を使用し、KEV が存在する場合は detect_vulnerability_propagation（0.035 ドル）を使用します。パッケージあたりの合計は 0.105～0.14 ドルです。50 個のパッケージを四半期ごとに監査する場合、費用はおよそ 5～7 ドルです。 この MCP は、マルウェアやバックドアを検出するために実際のパッケージのソースコードをスキャンしますか？ いいえ。メタデータ、脆弱性データベース、コミュニティのシグナルを分析します。ソースコードは分析しません。このサーバーは、高い CVSS スコア、CISA KEV の登録状況、低いバスファクター、名前の異常などのリスク指標を検出します。コードレベルの検査には、Semgrep や CodeQL などの専用 SAST ツールとこの MCP を組み合わせてください。

オープンソースのサプライチェーンリスクスコアは、具体的にどのように算出されますか？ score_supply_chain_risk ツールは、リポジトリごとに 5 つの要素を重み付けするモデルを適用します。脆弱性への露出度（30%）、バスファクター（20%）、CISA KEV を通じた悪用の活発さ（20%）、人気度／攻撃対象領域（15%）、コミュニティでの議論のシグナル（15%）です。各要素から 0～1 のスコアが算出されます。加重合計によってリスクレベルが決まります。クリティカルは 0.75 以上、ハイは 0.50 以上、ミディアムは 0.25 以上、ローは 0.25 未満です。

Snyk や Mend（WhiteSource）とは何が違いますか？ Snyk と Mend は、CI/CD に統合される SCA プラットフォームで、独自の脆弱性データベース、ライセンスコンプライアンスのスキャン、IDE プラグインを備えています。この MCP は、対話型のリスク評価、調査、デューデリジェンスのワークフローに対応する、AI ネイティブなインテリジェンスツールです。ビルドパイプラインではなく、AI エージェントに接続します。2 つのアプローチは相互補完的です。CI/CD では Snyk／Mend を使用し、AI セッションでの調査分析にはこの MCP を使用してください。

影響範囲の推定精度はどの程度ですか？ 影響範囲は、利用可能な公開データに基づくグラフ理論上の近似値です。すべてのパッケージレジストリにわたる完全な推移的依存関係ツリーではなく、観測された依存関係グラフ内のつながりを反映します。GitHub のフォークやコミュニティでの議論が多いパッケージは、同程度にリスクが高くても公開情報が少ないパッケージより、影響範囲が大きくなります。正確な下流への影響件数ではなく、相対的なリスク指標として扱ってください。

オープンソースのサプライチェーンリスクを定期的に監視するために、この MCP を使えますか？ はい。定期監視には Apify API の利用が最適です。対象パッケージを指定してアクターのエンドポイントに POST し、JSON 出力を処理して、重大度の高い検出結果をウェブフック経由でアラートシステムに送ります。また、標準のスケジュール設定済み Apify アクターを使って、この MCP の HTTP エンドポイントを一定間隔で呼び出すこともできます。

このオープンソースのセキュリティデータを収集することは合法ですか？ はい。すべてのデータソースは公開されています。NVD と CISA KEV は米国政府の公式データベースです。GitHub の公開リポジトリのメタデータは、研究開発目的であれば GitHub の利用規約に従って公開されています。Hacker News、StackExchange、ArXiv は一般公開のプラットフォームです。Censys は、研究目的での使用を許可するライセンスの下でインターネットスキャンデータを提供しています。

ツールの呼び出し中に 7 つのデータソースのいずれかが失敗すると、どうなりますか？ サーバーは上流の障害を適切に処理します。アクターがタイムアウトしたりエラーを返したりした場合、その結果は空の配列に置き換えられ、残りのソースを使って分析が続行されます。エラーレスポンスではなく、一部の結果が返されます。ツールは実行されているため、ツールイベント料金は適用されます。

キャッシュはどのように機能し、費用に影響しますか？ 5 分間のプロセス内キャッシュにより、1 回の AI セッション内で上流の重複課金を防ぎます。log4j に対して score_supply_chain_risk を呼び出し、5 分以内に log4j に対して assess_maintainer_risk を呼び出した場合、2 回目の呼び出しでは、1 回目で取得した上流データのキャッシュが再利用されます。呼び出しごとに 0.035 ドルのツールイベント料金がかかりますが、上流データの取得に再度課金されることはありません。キャッシュはインスタンスごとに保持されます。新しい Apify Standby インスタンスは、キャッシュが空の状態で起動します。

Cursor、Windsurf、その他のコーディングアシスタントに接続できますか？ はい。Streamable HTTP トランスポートに対応する MCP 互換クライアントであれば、/mcp エンドポイントを使用できます。SSE ベースのクライアント（古い MCP 実装）では、代わりに /sse エンドポイントを使用してください。Authorization: Bearer ヘッダーに Apify トークンを指定します。 オープンソースのサプライチェーンリスク分析と従来のSBOMツールの違いは何ですか？ 従来のSBOMツール（CycloneDX、SPDXジェネレーター）は、ビルドマニフェストから依存関係を列挙します。このMCPは、リアルタイムのインテリジェンスを使って依存関係のリスクを評価します。現在積極的に悪用されている脆弱性、活動を停止したメンテナー、タイポスクワッティングの特徴を示すパッケージなどを調べます。保有しているものを一覧表示するにはSBOMツールを、リスクの高さを評価するにはこのMCPを使用してください。

オープンソースのサプライチェーンリスク分析では、エコシステムを横断してどのようにタイポスクワッティングを検出しますか？ detect_typosquat_indicatorsツールは、クエリに対して返されたリポジトリの短縮名すべてについて、レーベンシュタイン編集距離をペアごとに計算します。距離が1〜2で、スター数に大きな差があるペア（starRatioが低いもの）は、疑わしさが高いと判定されます。requestsのようなクエリを指定すると、GitHubの検索結果から類似したパッケージ名が見つかり、ツールが各ペアを比較して疑わしさの高い順に並べます。より広範にエコシステムをスキャンするには、requests pythonのようなクエリを使って、比較候補を増やしてください。

改善にご協力ください

問題が発生した場合、Apifyアカウントで実行の共有を有効にすると、より迅速なデバッグにご協力いただけます。

1. アカウント設定 > プライバシーに移動します
2. Share runs with public Actor creatorsを有効にします

これにより、問題が発生した際に実行の詳細を確認できるようになり、より迅速に問題を修正できます。データは公開されず、Actorの開発者のみが閲覧できます。

サポート

バグを見つけた場合や機能のリクエストがある場合は、このActorのページにあるIssuesタブでイシューを作成してください。カスタム連携やエンタープライズ向けセキュリティワークフローについては、Apifyプラットフォームからお問い合わせください。