Open Source Software Supply Chain

オープンソースソフトウェアサプライチェーン MCP サーバー

ApifyForge で見る | Apify Store で使う

---

クイックスタート

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

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

---

CVE スキャナーだけでは不十分な AppSec チーム、エンジニアリングリード、プラットフォームエンジニア向けの、オープンソースサプライチェーンのリスク評価です。この MCP サーバーは、GitHub、NVD、CISA KEV、StackExchange、Hacker News、Federal Register、Congress.gov の7つのライブデータソースを集約し、0〜100の複合依存関係リスクスコアと、LOW_RISK から DO_NOT_USE までの機械可読な判定を提供します。

脆弱性データベースから分かるのは、CVEが存在することです。このサーバーは、メンテナーのバス係数、コミュニティの健全性、SBOMの規制上のリスク、そして現在の悪用状況を組み合わせ、ツール呼び出し1回あたり0.045ドルで、プロジェクトが実際に修正する見込みがあるかを実用的な評価として提示します。サブスクリプションも、ユーザーごとの料金も、CVEだけに注目することで見落とされるリスクもありません。

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

データ項目	ソース	例
📊 複合依存関係リスクスコア（0〜100）	7つすべてのソース	compositeScore: 71, verdict: "HIGH_RISK"
👤 メンテナーのバス係数とジニ係数	GitHub	busFactorLevel: "SINGLE_POINT", giniCoefficient: 0.87
🔴 重大なCVEの件数と深刻度の分布	NVD	criticalCVEs: 4, highCVEs: 9
⚡ CISA 既知の悪用脆弱性	CISA KEV	kevCount: 3, ransomwareCampaignUse: "Known"
📅 パッチ適用のタイムライン：90日を超えるCVE	NVD	unfixedCVEsOver90Days: 5
🏥 コミュニティの健全性レベルと推移	GitHub + StackExchange + HN	healthLevel: "GROWING", stars: 14200
📜 ライセンスの種類とコピーレフトのリスク	GitHub	complianceLevel: "MOSTLY_COMPLIANT", licenseRisk: 0
🏛️ SBOMに関する規制動向	Federal Register + Congress	regulatorySignals: 6, sbomBills: 3
💬 開発者向けQ&Aの活動状況	StackExchange	discussions: 31, answeredQuestions: 24
📰 セキュリティインシデントに関する言及	Hacker News	newsmentions: 9, hnPoints: 340
⚠️ 分かりやすいリスクシグナル	複合評価	"CISA KEV の登録が3件 — 現在悪用されている脆弱性"
📋 優先順位付きの修正推奨事項	複合評価	"重大なCVEが存在 — 直ちにパッチを適用するか、置き換えてください"

Open Source Software Supply Chain MCP Server を使う理由

多くの依存関係監査ワークフローは、CVEスキャナーで始まり、そこで終わります。CVE IDと深刻度の一覧は得られても、プロジェクトが現在も保守されているか、コミュニティが縮小しているか、あるいは連邦政府の要件によって依存関係ツリー全体のSBOM文書化が新たに義務付けられているか、といった背景は分かりません。GitHub、NVD、CISA KEV、Stack Overflow、規制データベースを横断して手作業で情報を集めるには、パッケージごとに何時間もかかります。

この MCP サーバーは、インテリジェンス収集のパイプライン全体を自動化します。1回のツール呼び出しで7つのアクターを並行して実行し、4つの独立した観点から結果を評価して、根拠となるシグナルと優先順位付きの推奨事項を含む構造化された判定を返します。重大なCVEが1件あっても、現在活動中の貢献者が500人いるパッケージと、同じCVEを抱え、休眠状態のメンテナーが1人しかいないパッケージとでは、リスクはまったく異なります。

• スケジュール設定 — 重要な依存関係を対象にサプライチェーン監査を毎週実行し、新たなCVE、KEVへの追加、貢献者の離脱を、インシデントになる前に検出します
• API アクセス — CI/CD パイプライン内から、Python、JavaScript、または任意のHTTPクライアントで評価を実行します
• プロキシローテーション — 信頼性の高い大規模アクセスのため、上流データの取得にはすべて Apify の組み込みプロキシインフラストラクチャを使用します
• 監視 — スケジュール実行で新たな HIGH_RISK パッケージや予期しないスコア上昇が検出された場合に、Slack またはメールでアラートを受け取ります
• 連携 — 結果を Zapier、Make、Jira、または ITSM プラットフォームに送り、判定が変わった際にチケットを自動作成します

特徴

• 複合依存関係リスクスコア（0～100）。脆弱性への曝露（35％）、バス係数リスク（25％）、コミュニティの健全性の逆数（20％）、SBOM 準拠状況の逆数（20％）を用いた加重計算式を採用します。
• メンテナーのバス係数分析。貢献者のジニ係数を算出し、1 人のメンテナーが離れるとコードベースが放棄されるプロジェクトを検出します。
• 活動の新しさのスコアリング。コミットが 90 日、180 日、または 365 日以上ないリポジトリに対して、リスクへの加算値を最大 20 ポイントまで段階的に増やします。
• NVD の CVE 深刻度分布。CRITICAL（×10 ポイント）、HIGH（×5 ポイント）、MEDIUM（×2 ポイント）の件数を、40 ポイントの曝露サブスケールに換算します。
• CISA KEV との相互参照。実環境での悪用が確認されている CVE を特定し、脆弱性サブスケールで各 8 ポイントとしてスコアリングします。
• ランサムウェアキャンペーンの検出。CISA KEV の knownRansomwareCampaignUse フィールドを通じて、ランサムウェアキャンペーンでの使用が確認された CVE に、さらに 5 ポイントの倍率を適用します。
• 強制上書きルール。CISA KEV に登録され、かつバス係数が SINGLE_POINT のパッケージは、複合スコアの数値にかかわらず、判定が DO_NOT_USE に強制されます。
• ライセンスのコピーレフト検出。GPL、AGPL、LGPL、SSPL のライセンスを、寛容なライセンスである MIT、Apache、BSD、ISC と比較して分類し、エンタープライズ配布のリスクを評価します。
• SBOM 準拠への準備状況。Federal Register と Congress.gov をスキャンし、パッケージの規制上の対象範囲に影響する、有効な SBOM 義務や議会法案を調べます。
• コミュニティ健全性インデックス。GitHub のスター（35 ポイント）、StackExchange の回答済み質問（25 ポイント）、Hacker News のポイント合計（25 ポイント）、複数シグナルによるエコシステムの活発さ（15 ポイント）を重み付けします。
• アクターの並列実行。7 つのデータソースアクターすべてを並行して実行し、ソースごとに 120 秒のタイムアウトを設定することで、エンドツーエンドのレイテンシを最小限に抑えます。
• 8 つの専用ツール。複合評価全体から、対象を絞った調査ワークフロー向けの単一の側面に特化したクエリまでを提供します。
• 支出上限の適用。すべてのツール呼び出しで、実行前に実行ごとの課金予算を確認し、自動化パイプラインで費用が際限なく増えるのを防ぎます。

OSS サプライチェーンリスクインテリジェンスのユースケース

AppSec チームによる依存関係の監査

脆弱性管理を担当する AppSec エンジニアは、どの間接依存関係に直ちに対応する必要があるかを優先順位付けする必要があります。CVE ID だけでは、そのプロジェクトが四半期ごとにパッチをリリースしているのか、あるいは 2 年間放置されているのかは分かりません。dependency_risk_assessment ツールは、バス係数、パッチ履歴のシグナル、コミュニティの健全性を 1 回の呼び出しで返すため、すべての CVE を同じ緊急度として扱うのではなく、チームが正確に優先順位を付けられます。

エンジニアリングリードによるパッケージ選定

新しいライブラリを採用する前に、シニアエンジニアやテックリードは、積極的に保守されているか、ライセンスによって配布上の義務が生じるか、未修正の重大な CVE が過去にあったかを把握したいと考えます。compare_package_risks ツールは、候補パッケージとその代替パッケージを並べて評価するため、GitHub のスター数だけでなく、コミュニティのデータに基づいて判断できます。

SBOM 準拠と調達

大統領令 14028、NIST のガイドライン、または契約上の SBOM 要件の対象となる組織は、自社の OSS 利用にどの規制が適用されるかを追跡する必要があります。sbom_regulatory_tracker ツールは Federal Register と Congress.gov をリアルタイムで照会し、SBOM 関連の規制活動の密度をスコアリングします。これにより、コンプライアンスチームは、新たな要件が監査指摘になる前に対応できます。

セキュリティインシデント対応

サプライチェーン攻撃（Log4Shell、XZ Utils、SolarWinds など）が発生した場合、インシデント対応担当者は、CVE の深刻度プロファイルと、CISA が実環境での悪用を確認しているかどうかをすぐに把握する必要があります。security_incident_monitor ツールは、Hacker News の侵害報道を NVD の CVE データおよび CISA KEV カタログと同時に相互参照し、構造化された vulnLevel と関連するすべてのシグナルを返します。

プラットフォームエンジニアリングと CI/CD ゲート

ビルドパイプラインに依存関係のリスクチェックを組み込むプラットフォームエンジニアには、ゲート判定に使える機械可読な結果が必要です。dependency_risk_assessment は、CI の合格／不合格ロジックに手動でスコアを解釈せずに直接対応できる、構造化された JSON 判定（LOW_RISK、ACCEPTABLE、REVIEW_NEEDED、HIGH_RISK、DO_NOT_USE）を返します。

ベンダーおよび調達のデューデリジェンス

OSS コンポーネントをバンドルするソフトウェアベンダーを評価する調達チームには、サプライチェーンの健全性を示す、根拠として提示できる証拠が必要です。ベンダーが申告した依存関係に対して dependency_risk_assessment を実行すると、リスクスコアが文書化され、デューデリジェンス資料や契約交渉に活用できます。

OSS サプライチェーンのリスクインテリジェンスの使い方

1. MCP サーバーに接続する — https://open-source-software-supply-chain-mcp.apify.actor/mcp を MCP クライアント（Claude Desktop、Cursor、Windsurf、Cline、または MCP 対応ツール）に追加します。Apify API トークンを Authorization: Bearer YOUR_TOKEN として指定します。
2. ユースケースに合ったツールを選ぶ — リスクを総合的に把握するには、"lodash" や "openssl" などのパッケージ名を指定して dependency_risk_assessment を呼び出します。特定の項目に絞って確認するには、vulnerability_exposure_timeline または maintainer_bus_factor を直接呼び出します。
3. 判定とシグナルを確認する — レスポンスには、verdict フィールド（LOW_RISK から DO_NOT_USE まで）、0～100 の compositeScore、平易な言葉でリスクを説明する allSignals 配列が含まれます。
4. 推奨事項に基づいて対応する — 各レスポンスの recommendations 配列には、パッチ適用の緊急度、代替パッケージの評価、ライセンスレビューの要件、移行計画など、具体的な対応項目が含まれます。

MCP ツール

ツール	料金	データソース	説明
dependency_risk_assessment	$0.045	7 つすべて	保守担当者のバスファクター、CVE への曝露、コミュニティの健全性、SBOM 準拠状況を含む、総合リスクスコア（0～100）です。判定と推奨事項を返します。
maintainer_bus_factor	$0.045	GitHub + StackExchange	コントリビューターのジニ係数、コントリビューター数、活動の直近性スコアです。単一の保守担当者による放棄のリスクを特定します。
vulnerability_exposure_timeline	$0.045	NVD + CISA KEV	CVE の深刻度分布、悪用状況、パッチがないまま 90 日を超えた CVE を示します。
license_compliance_check	$0.045	GitHub + Federal Register	コピーレフト型と寛容型の分類、SBOM の規制要件、ライセンスの競合検出を行います。
community_health_score	$0.045	GitHub + StackExchange + HN	スター数、Q&A の件数、Hacker News での注目度を示します。healthLevel は DEAD から THRIVING までを返します。
sbom_regulatory_tracker	$0.045	Federal Register + Congress	有効な SBOM 義務、連邦規制、ソフトウェアサプライチェーンに関する議会法案を追跡します。
security_incident_monitor	$0.045	HN + NVD + CISA KEV	特定のパッケージに関する侵害報告、新たな CVE の公開、CISA KEV への追加を確認します。
compare_package_risks	$0.045	GitHub + NVD + KEV + SE + HN	パッケージ選定の判断に役立つ、総合リスクプロファイルの並列比較を行います。

ツールの入力パラメーター

パラメーター	ツール	型	必須	デフォルト	説明
package	sbom_regulatory_tracker 以外すべて	string	はい	—	パッケージまたはライブラリの名前（例："lodash"、"openssl"、"log4j"）
ecosystem	dependency_risk_assessment	string	いいえ	—	エコシステムのヒント：npm、pypi、cargo、maven、go
alternative	compare_package_risks	string	いいえ	—	並列比較する代替パッケージの名前
topic	sbom_regulatory_tracker	string	いいえ	"software supply chain SBOM"	Federal Register と Congress で追跡する規制関連トピック

入力例

重要なライブラリの依存関係リスクを包括的に評価する：

{
  "tool": "dependency_risk_assessment",
  "package": "log4j",
  "ecosystem": "maven"
}

2 つの代替 HTTP クライアントライブラリを比較する：

{
  "tool": "compare_package_risks",
  "package": "axios",
  "alternative": "got"
}

現在の SBOM 規制の動向を追跡する：

{
  "tool": "sbom_regulatory_tracker",
  "topic": "software bill of materials executive order"
}

入力のヒント

• CVE の照合には、エコシステムを含む正式名称を使用してください — "apache struts" のほうが "struts" より、対象を絞った CVE が返されます。Maven アーティファクトでは、判明している場合はグループ ID を含めてください。
• まず dependency_risk_assessment を実行してください — 包括的な複合評価により、コストあたりの調査範囲が最も広くなります。特定のサブスコアでフラグが立った項目を追加調査する際は、対象を絞ったツールを使用してください。
• vulnerability_exposure_timeline と security_incident_monitor を組み合わせてください — リスクが高いと判明しているパッケージについて、両方を実行すると、CVE の履歴とコミュニティから報告された侵害情報を併せて確認できます。
• sbom_regulatory_tracker を四半期ごとに実行してください — OSS サプライチェーンをめぐる規制の動向は頻繁に変化するため、四半期ごとに実行すると、新たな連邦官報の措置や議会法案の進捗状況を把握できます。
• 実行ごとに支出上限を設定してください — 自動化されたパイプラインでは、バッチのクエリリストが想定より大きい場合に費用が膨らむのを防ぐため、Apify の実行に最大コストを設定してください。

出力例

{
  "package": "log4j",
  "compositeScore": 71,
  "verdict": "HIGH_RISK",
  "busFactor": {
    "score": 22,
    "contributors": 38,
    "giniCoefficient": 0.61,
    "busFactorLevel": "ADEQUATE",
    "signals": [
      "Gini coefficient 0.61 — moderate commit concentration among top contributors"
    ]
  },
  "vulnExposure": {
    "score": 88,
    "criticalCVEs": 4,
    "highCVEs": 9,
    "kevCount": 3,
    "vulnLevel": "CRITICAL",
    "signals": [
      "4 CRITICAL CVEs — immediate remediation required",
      "9 HIGH severity CVEs — significant exposure",
      "3 CISA KEV entries — actively exploited vulnerabilities",
      "2 used in ransomware campaigns — urgent patching needed",
      "5 CVEs older than 90 days without patch — slow remediation"
    ]
  },
  "communityHealth": {
    "score": 72,
    "stars": 3200,
    "discussions": 31,
    "newsmentions": 9,
    "healthLevel": "GROWING",
    "signals": [
      "31 StackExchange discussions — active Q&A community",
      "9 Hacker News mentions — tech community visibility"
    ]
  },
  "sbomCompliance": {
    "score": 44,
    "regulatorySignals": 6,
    "licenseRisk": 0,
    "complianceLevel": "PARTIAL",
    "signals": [
      "4 SBOM-related federal regulations — compliance landscape active",
      "2 relevant bills in Congress — legislative momentum"
    ]
  },
  "allSignals": [
    "Gini coefficient 0.61 — moderate commit concentration among top contributors",
    "4 CRITICAL CVEs — immediate remediation required",
    "9 HIGH severity CVEs — significant exposure",
    "3 CISA KEV entries — actively exploited vulnerabilities",
    "2 used in ransomware campaigns — urgent patching needed",
    "5 CVEs older than 90 days without patch — slow remediation",
    "31 StackExchange discussions — active Q&A community",
    "4 SBOM-related federal regulations — compliance landscape active"
  ],
  "recommendations": [
    "Critical CVEs present — patch immediately or replace dependency",
    "CISA KEV vulnerabilities — actively exploited, urgent action required",
    "High dependency risk — evaluate alternative packages"
  ]
}

出力フィールド

フィールド	型	説明
package	string	入力で指定されたパッケージ名
compositeScore	number	複合リスクスコア（0～100）。数値が高いほどリスクが高くなります。
verdict	string	LOW_RISK / ACCEPTABLE / REVIEW_NEEDED / HIGH_RISK / DO_NOT_USE
busFactor.score	number	バスファクターリスクのサブスケール（0～100）
busFactor.contributors	number	一致するリポジトリ全体で検出されたコントリビューター数の最大値
busFactor.giniCoefficient	number	コミット分布のジニ係数（0 = 均等、1 = 単独のコントリビューター）
busFactor.busFactorLevel	string	HEALTHY / ADEQUATE / CONCENTRATED / FRAGILE / SINGLE_POINT
busFactor.signals	string[]	平易な言葉で示したバスファクターリスクのシグナル
vulnExposure.score	number	脆弱性エクスポージャーのサブスケール（0～100）
vulnExposure.criticalCVEs	number	NVD の CRITICAL 重大度の CVE 件数
vulnExposure.highCVEs	number	NVD の HIGH 重大度の CVE 件数
vulnExposure.kevCount	number	このパッケージに関する CISA KEV エントリ数
vulnExposure.vulnLevel	string	CLEAN / LOW / MODERATE / HIGH / CRITICAL
vulnExposure.signals	string[]	平易な言葉で示した脆弱性のシグナル
communityHealth.score	number	コミュニティ健全性のサブスケール（0～100）。数値が高いほど健全です。
communityHealth.stars	number	一致するリポジトリ全体の GitHub スター総数
communityHealth.discussions	number	このパッケージに関する StackExchange の質問数
communityHealth.newsmentions	number	このパッケージに言及した Hacker News の記事数
communityHealth.healthLevel	string	DEAD / DECLINING / STABLE / GROWING / THRIVING
communityHealth.signals	string[]	平易な言葉で示したコミュニティ健全性のシグナル
sbomCompliance.score	number	SBOM コンプライアンスへの対応度（0～100）。数値が高いほど準拠度が高くなります。
sbomCompliance.regulatorySignals	number	関連する連邦規制および議会法案の件数
sbomCompliance.licenseRisk	number	ライセンスリスクの累積値（数値が高いほどコピーレフトへのエクスポージャーが大きくなります）
sbomCompliance.complianceLevel	string	NON_COMPLIANT / GAPS / PARTIAL / MOSTLY_COMPLIANT / FULLY_COMPLIANT
sbomCompliance.signals	string[]	平易な言葉で示したコンプライアンスのシグナル
allSignals	string[]	4 つすべてのサブスコアのシグナルをまとめたもの
recommendations	string[]	優先順位付けされた修正の推奨事項

複合リスクスコアの算出方法

スコア範囲	判定	解釈
0-14	LOW_RISK	適切に保守されており、脆弱性の履歴がなく、コミュニティが活発です
15-34	ACCEPTABLE	軽微な懸念があります。監視は必要ですが、安全に使用できます
35-54	REVIEW_NEEDED	バスファクターまたは CVE への露出度に中程度の懸念があります。チームでのレビューを推奨します
55-74	HIGH_RISK	重大な CVE、メンテナーが 1 人のみ、またはコミュニティの衰退が見られます。是正計画を立ててください
75-100	DO_NOT_USE	脆弱性が現在悪用されているか、プロジェクトが放棄されています

複合スコアの計算では、脆弱性への露出度を最も重視し、35％の重みを付けています。脆弱性の積極的な悪用は、最も差し迫ったリスクを示すためです。次に、バスファクターに25％の重みを付けています。プロジェクトが放棄されていると、今後の脆弱性にパッチを適用できないためです。コミュニティの健全性と SBOM への準拠度には、それぞれ長期的な持続可能性を示す先行指標として20％ずつの重みを付けています。

強制上書き： CISA KEV に登録されており、かつバスファクターが SINGLE_POINT のパッケージは、複合スコアの数値にかかわらず DO_NOT_USE に設定されます。

OSS サプライチェーンのリスク評価にかかる費用はどのくらいですか？

この MCP サーバーはイベントごとの従量課金制です。ツールの呼び出し1回につき $0.045 かかります。プラットフォームのコンピューティング費用も含まれています。支出上限に達した場合、失敗した呼び出しには課金されません。

シナリオ	ツール呼び出し回数	1回あたりの費用	合計費用
クイックテスト — 単一パッケージ	1	$0.045	$0.045
新規プロジェクトのセットアップ — 主要な依存関係10件	10	$0.045	$0.45
スプリント監査 — 依存関係50件	50	$0.045	$2.25
四半期監査 — パッケージ200件	200	$0.045	$9.00
エンタープライズライセンス監査 — パッケージ1,000件	1,000	$0.045	$45.00

実行ごとに最大支出上限を設定して、費用を管理できます。サーバーは呼び出しごとにこの上限を適用し、予算に達すると構造化エラーを返します。

Snyk の開発者向けプランは、CVE とライセンスのデータを月額 $98 から提供していますが、メンテナーの健全性、コミュニティの持続可能性、SBOM の規制に関する情報は含まれていません。このサーバーを利用する多くのエンジニアリングチームでは、サブスクリプション契約を結ぶことなく、対象を絞った評価に月額 $2～10 を費やしています。

この OSS サプライチェーン MCP サーバーへの接続方法

Claude Desktop

claude_desktop_config.json に追加します。

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

Cursor / Windsurf / Cline

IDE の MCP 設定パネルに MCP サーバーの URL を追加します。

https://open-source-software-supply-chain-mcp.apify.actor/mcp

リクエストヘッダーとして Authorization: Bearer YOUR_APIFY_TOKEN を含めてください。

Python

import httpx
import json

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

payload = {
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
        "name": "dependency_risk_assessment",
        "arguments": {
            "package": "requests",
            "ecosystem": "pypi"
        }
    },
    "id": 1
}

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

result = response.json()
content = json.loads(result["result"]["content"][0]["text"])
print(f"Package: {content['package']}")
print(f"Risk Score: {content['compositeScore']}/100 — {content['verdict']}")
print(f"Critical CVEs: {content['vulnExposure']['criticalCVEs']}")
print(f"KEV count: {content['vulnExposure']['kevCount']}")
print(f"Bus factor level: {content['busFactor']['busFactorLevel']}")
for rec in content.get("recommendations", []):
    print(f"  -> {rec}")

JavaScript

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

const response = await fetch(MCP_URL, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${APIFY_TOKEN}`
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    method: "tools/call",
    params: {
      name: "vulnerability_exposure_timeline",
      arguments: { package: "lodash" }
    },
    id: 1
  })
});

const data = await response.json();
const result = JSON.parse(data.result.content[0].text);
console.log(`Package: ${result.package}`);
console.log(`Vuln level: ${result.vulnExposure.vulnLevel}`);
console.log(`Critical CVEs: ${result.vulnExposure.criticalCVEs}`);
console.log(`CISA KEV entries: ${result.vulnExposure.kevCount}`);
for (const signal of result.vulnExposure.signals) {
  console.log(`  Signal: ${signal}`);
}

cURL

# Full dependency risk assessment
curl -X POST "https://open-source-software-supply-chain-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "dependency_risk_assessment",
      "arguments": {
        "package": "openssl",
        "ecosystem": "c"
      }
    },
    "id": 1
  }'

# Monitor security incidents for a specific package
curl -X POST "https://open-source-software-supply-chain-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "security_incident_monitor",
      "arguments": { "package": "xz-utils" }
    },
    "id": 2
  }'

Open Source Software Supply Chain MCP Server の仕組み

フェーズ 1：7 つのソースからの並列データ収集

ツール呼び出しを受信すると、サーバーは Promise.all を使用して最大 7 つの Apify アクターを同時に実行します。各ソースには 512 MB のメモリ割り当てと 120 秒のタイムアウトが設定されます。7 つのアクターは次のとおりです。

• github-repo-search — 公開リポジトリのメタデータ：スター数、フォーク数、コントリビューター数、最終プッシュ日時、オープン中のイシュー数、ライセンスの SPDX 識別子、CI／Actions の有無を示すフラグ
• nvd-cve-vulnerability-search — CVSS v3 の重大度（CRITICAL、HIGH、MEDIUM、LOW）、公開日、影響を受ける製品のバージョン範囲を含む National Vulnerability Database の CVE エントリ
• cisa-kev-search — ランサムウェアとの関連が確認済みであることを示す knownRansomwareCampaignUse フィールドを含む、CISA Known Exploited Vulnerabilities カタログのエントリ
• stackexchange-search — Stack Overflow および関連する Q&A：コミュニティサポートの指標となる質問数、is_answered フラグ、回答数
• hacker-news-search — 技術コミュニティにおけるセキュリティインシデントの認知度を示す指標となる、HN のストーリー数とポイントの合計
• federal-register-search — タイトルおよび概要フィールドで sbom、software bill、supply chain のキーワードに一致する Federal Register のエントリ
• congress-bill-search — 法案のタイトルに software、cyber、supply chain が含まれる議会法案

必要なソースが少ないツールは、関連するサブセットのみを実行します。maintainer_bus_factor は 2 つのアクター、vulnerability_exposure_timeline は 2 つ、sbom_regulatory_tracker も 2 つを使用します。これにより、対象を絞ったクエリのレイテンシとコストの両方を削減できます。

フェーズ 2：4 次元のスコアリング

scoring.ts モジュールは、集約されたデータに 4 つの独立したモデルを適用します。

バスファクターモデル（0～100 のリスクスケール）： コントリビューター数を基本リスクスコアに対応付けます。メンテナーが 1 人の場合は 40 点、コントリビューターが 2～3 人の場合は 25 点、4～5 人の場合は 15 点、6～10 人の場合は 8 点です。次に、一致したリポジトリ全体のコントリビューター数の分布から、sumDiff / (n * totalSum) の式を使ってジニ係数を算出します。貢献数を昇順に並べ、インデックスで重み付けします。ジニスコアによって最大 20 点が加算されます。最終プッシュからの日数に基づき、アクティビティの新しさによって 0～20 点が加算されます。90 日以内にアクティブであれば 0 点、90～180 日であれば 8 点、180～365 日であれば 15 点、1 年を超えて更新がなければ 20 点です。

脆弱性エクスポージャーモデル（0～100 のリスクスケール）： CVE の重大度を点数に換算します。CRITICAL は 10 倍、HIGH は 5 倍、MEDIUM は 2 倍で、上限は 40 点です。CISA KEV のエントリは 1 件につき 8 点、ランサムウェアとの関連が確認された場合は 1 件につきさらに 5 点で、上限は 35 点です。公開から 90 日を超えた CVE は 1 件につき 3 点で、上限は 15 点です。重大な CVE と KEV エントリの両方が同時に存在する場合、複合ボーナスとして 10 点が加算されます。

コミュニティ健全性モデル（0～100 のポジティブスケール）： GitHub のスター数を 35 点満点のスケールに対応付けます（10,000 以上＝35 点、1,000 以上＝25 点、100 以上＝15 点、10 以上＝8 点）。StackExchange の質問数と回答済み質問の割合で最大 25 点、Hacker News のストーリー数とポイントの合計で最大 25 点が加算されます。GitHub と StackExchange の両方が同時にアクティブな場合、複数のシグナルによるエコシステムの活性度に応じて最大 15 点が加算されます。

SBOM コンプライアンスモデル（0～100 のポジティブスケール）： コピーレフトライセンス（GPL、AGPL、LGPL、SSPL）はリスク累積値に 3 を加算し、ライセンスがない場合は 5 を加算します。ライセンススコアは、この累積値を最大 30 点の範囲で反転させたものです。Federal Register の SBOM キーワードとの一致によって最大 25 点、議会法案との一致によって最大 25 点が加算されます。CI／パーミッシブライセンスの準備状況を示す指標（GitHub Actions の有無と MIT／Apache／BSD ライセンス）によって最大 20 点が加算されます。

フェーズ 3：複合スコアと判定の割り当て

複合スコアの計算式では、4 つのサブスコアに重みを付けます。

compositeScore = busFactor.score × 0.25
               + vulnExposure.score × 0.35
               + (100 − communityHealth.score) × 0.20
               + (100 − sbomCompliance.score) × 0.20

コミュニティの健全性と SBOM への準拠度は反転され、より健全で準拠度の高いパッケージほど、全体的なリスクが低くなります。複合スコアは、15、35、55、75 のしきい値に基づいて判定レベルにマッピングされます。次に、ハードオーバーライドが適用されます。kevCount > 0 かつ busFactorLevel === 'SINGLE_POINT' の場合、数値スコアにかかわらず、判定は DO_NOT_USE に強制されます。

フェーズ 4：シグナルの集約と推奨事項の生成

4 つすべてのモデルのシグナルを連結し、使いやすいフラットな allSignals 配列にします。推奨事項は条件チェックに基づいて生成されます。重大な CVE がある場合は即時パッチ適用を推奨し、CISA KEV エントリーがある場合は緊急対応を推奨します。コミュニティの健全性が低い場合は移行を推奨し、バスファクターが高い場合はフォークまたは置き換えを推奨します。また、コピーレフトライセンスのリスクがある場合は法務レビューを推奨します。

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

1. CVE の照合には、エコシステム名を含む完全な名前を使用してください。 "struts" で検索するよりも、"apache struts" で検索したほうが、関連性の高い CVE が多く見つかります。Maven アーティファクトでは、分かる場合はグループ ID を含めてください。
2. まず dependency_risk_assessment を実行し、その後、目的を絞ったツールで詳しく調べてください。 全体評価では、4 つすべてのサブスコアが返されます。vulnExposure.score が主なリスク要因である場合は、vulnerability_exposure_timeline を使って CVE の完全な一覧を確認してください。
3. 新しい依存関係を採用する前に、compare_package_risks で相互参照してください。 現在のパッケージと有力な代替パッケージを指定して呼び出すと、1 回のリクエストで相対的なリスクプロファイルを確認できます。
4. 本番環境のクリティカルパスにある依存関係については、security_incident_monitor をスケジュールしてください。 Apify のスケジューリングでは毎日の実行に対応しています。vulnLevel が CRITICAL に上昇したときに備え、Slack または PagerDuty への Webhook と組み合わせてください。
5. コミュニティの健全性は、バスファクターと合わせて評価し、個別に判断しないでください。 コミュニティが THRIVING でも、バスファクターが SINGLE_POINT なら、依然として脆弱です。コミュニティが活発な利用者で構成され、貢献者は少ない可能性があります。パッケージが安全だと結論付ける前に、両方のサブスコアを確認してください。
6. 企業の調達サイクル前に sbom_regulatory_tracker を使用してください。 規制環境は急速に変化しています。調達審査会の前に四半期ごとに実行することで、新たな連邦政府の義務がコンプライアンス上の問題になる前に把握できます。
7. 多層防御のため、静的解析ツールと組み合わせてください。 このサーバーは、静的スキャナーでは見逃される行動面とコミュニティ面のシグナルをカバーします。コードレベルの依存関係分析には Syft または OWASP Dependency-Check と組み合わせ、API 経由で複合リスクスコアを既存のワークフローに取り込んでください。

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

アクター	組み合わせ方法
OSS Dependency Risk Report	このアクターを実行して、関係者向けの書式設定済み HTML／PDF サプライチェーンリスクレポートを作成します。フラグが付いたパッケージの対話型 AI 主導調査には、この MCP を使用します
Cyber Attack Surface Report	この MCP のサプライチェーン脆弱性データをインフラの露出スキャンと組み合わせ、アプリケーションセキュリティの全体像を把握します
Company Deep Research	ベンダーが申告した OSS 依存関係のサプライチェーン健全性スコアで、ベンダーのデューデリジェンスを強化します
Website Tech Stack Detector	対象ウェブサイトが使用する OSS ライブラリを検出し（100 以上のテクノロジーのフィンガープリント）、各ライブラリを dependency_risk_assessment に渡して、サプライチェーンを全面的に監査します
Federal Contract Intelligence	SBOM の義務化対象となる連邦政府請負業者を特定し、sbom_regulatory_tracker を使ってコンプライアンス環境を評価します
SEC EDGAR Filing Analyzer	10-K 提出書類のサイバーセキュリティリスク開示と、上場ソフトウェアベンダーのサプライチェーン脆弱性スコアを照合します
B2B Lead Qualifier	セキュリティベンダーのリードを、そのベンダー自身の OSS サプライチェーン健全性に照らして評価し、アプローチ前に信頼性を判断します

制限事項

• GitHub の照合はキーワードベースであり、レジストリ解決は行いません。 サーバーはパッケージ名で GitHub を検索します。npm、PyPI、Cargo のレジストリメタデータを、正規のリポジトリ URL に解決することはありません。一般的な名前のパッケージでは、関連性の低い検索結果が返される場合があります。
• 推移的依存関係ツリーの走査には対応していません。 サーバーは入力で指定された個々のパッケージを分析します。package.json、requirements.txt、ロックファイルは読み取りません。SBOM を全面的に生成するには、Syft または CycloneDX CLI を使用してから、主要な依存関係をここで分析してください。
• CVE の照合精度は名前の指定方法に左右されます。 NVD の検索はテキストベースです。"react" で検索すると、React に言及しているあらゆる CVE が一致します。具体的に指定することが重要です。"react dom" や "facebook react" では、より対象を絞った結果が返されます。
• GitHub のコントリビューターデータは、レジストリのコントリビューショングラフではなく、リポジトリの検索結果を反映します。 コントリビューター数とジニ係数は、完全なコミット履歴ではなく、リポジトリのメタデータフィールドから算出されます。
• コミュニティ健全性スコアは現在の状態を示すものであり、傾向を示すものではありません。 過去に多くのスターを獲得したプロジェクトでも、実質的に放置されている場合があります。アクティビティの直近度シグナルで一部を補いますが、経時的な傾向分析には複数回の実行が必要です。
• SBOM コンプライアンススコアは、規制環境の密度を示すものであり、お客様固有のコンプライアンス義務を示すものではありません。 regulatorySignals の数が多い場合、規制環境が活発であることを意味しますが、お客様のユースケースが必ずしもコンプライアンス違反であることを意味するものではありません。コンプライアンスの判断については、弁護士に相談してください。
• Hacker News のインシデントデータはコミュニティによって集約されたものであり、網羅的ではありません。 すべてのセキュリティインシデントが HN で取り上げられるわけではありません。newsmentions の数が少なくても、インシデントがないとは限りません。
• プライベートパッケージや内部フォークは確認できません。 データは公開されている GitHub リポジトリに限定されます。内部でフォークされた配布物やプロプライエタリな配布物は、このツールの対象外です。

インテグレーション

• Zapier — 新しい CVE アラートが届いたときに security_incident_monitor を呼び出し、vulnLevel が CRITICAL または HIGH の場合は Jira チケットを作成します
• Make — パッケージリストに対して dependency_risk_assessment を実行する依存関係監査の自動化ワークフローを構築し、HIGH_RISK の結果をレビューキューに振り分けます
• Google Sheets — 複合リスクスコアとすべてのシグナルを依存関係リスク登録用のスプレッドシートにエクスポートし、関係者への報告に使用します
• Apify API — 構造化された JSON レスポンスを返す HTTP API を使用して、サプライチェーンのチェックを CI/CD パイプラインに直接組み込みます
• Webhooks — スケジュールされたセキュリティ監視の実行で判定結果に変化があったとき、Slack または PagerDuty に POST 通知を送信します
• LangChain / LlamaIndex — この MCP を、依存関係ツリーを調査してリスクの説明を作成する AI セキュリティ分析エージェント内のツールとして使用します

トラブルシューティング

• 多数の脆弱性があるはずのパッケージで CVE 件数が少ない — CVE の照合はテキストベースです。"spring" ではなく "spring framework" や "pivotal spring" を使うなど、より具体的なクエリを試してください。また、NVD の製品名に記載されているパッケージの正式なベンダー名も試してください。
• メンテナーが 1 人しかいないと分かっているプロジェクトで、バスファクターが HEALTHY と表示される — パッケージ名による GitHub リポジトリ検索で、人気のフォークや無関係なプロジェクトが見つかり、コントリビューター数が水増しされることがあります。signals 配列を確認してください。集中リスクのシグナルは、集計スコアにかかわらず追加されます。
• dependency_risk_assessment が空のシグナルを返す — 上流の 7 つのアクターすべてが空のデータセットを返した場合、複合スコアはシグナルなしで 0 になります。パッケージ名のスペルを確認し、status.apify.com で Apify プラットフォームのステータスを確認してください。
• 最初の呼び出しで支出上限に達したというエラーが表示される — 1 回の実行あたりの支出上限が低すぎる可能性があります。各ツール呼び出しの料金は $0.045 です。1 回の呼び出しでは少なくとも $0.10、100 パッケージの一括処理では $5.00 以上の実行予算を設定してください。
• dependency_risk_assessment でタイムアウトエラーが発生する — このツールは 7 つのアクターを、それぞれ 120 秒のタイムアウトで実行します。負荷が高い場合、合計遅延は 60〜90 秒に達することがあります。クライアント側のタイムアウトを少なくとも 180 秒に増やしてください。

責任ある利用

• このサーバーがアクセスするのは、GitHub、NVD、CISA、StackExchange、Hacker News、Federal Register、Congress.gov で公開されているデータのみです。
• NVD と CISA KEV は米国政府の公式データベースです。GitHub の公開リポジトリのメタデータは、GitHub の利用規約に基づき公開されています。
• リスクスコアは分析上の指標であり、法令遵守の判断を示すものではありません。資格のあるセキュリティおよび法務の専門家に相談せず、調達やコンプライアンスに関する判断をスコアだけに基づいて行わないでください。
• 人によるレビューなしに、バスファクターの指標に基づいてオープンソースのメンテナーに不利益を与える自動拒否リストの作成に、このサーバーを使用しないでください。
• ウェブスクレイピングの合法性に関するガイダンスは、Apify のガイドを参照してください。

FAQ

オープンソースのサプライチェーンリスク評価は、一般的な CVE スキャナーとどう違いますか？ 一般的な CVE スキャナーが報告するのは、どの CVE が存在するかです。このサーバーでは、メンテナーのバスファクター（誰が修正するのか）、コミュニティの健全性（プロジェクトが今後も存続するか）、ライセンスコンプライアンス（合法的に配布できるか）、SBOM の規制上の背景（文書化が義務付けられているか）も評価します。重大な CVE が 1 件あっても、500 人のコントリビューターが活動するコミュニティを持つパッケージと、同じ CVE があり、活動を停止したメンテナーが 1 人しかいないパッケージでは、リスクは大きく異なります。 OSS のバス係数分析におけるジニ係数の精度はどの程度ですか？ ジニ係数は、該当するリポジトリを対象とした GitHub リポジトリ検索から返されるコントリビューター数を基に算出されます。コミットの集中度を近似しますが、git の全履歴にはアクセスしません。少数のメンテナーが、多数の名目上のコントリビューターに対するマージ権限を持つプロジェクトでは、集中リスクが過小評価される場合があります。busFactorLevel は、正確な測定値ではなく、傾向を示す指標として使用してください。

OSS サプライチェーンのリスク評価における脆弱性データは、どの程度最新ですか？ NVD の CVE データと CISA KEV データは、クエリ時にリアルタイムで取得されます。本日公開された新たな CVE の開示情報や KEV カタログへの追加は、すぐに結果に反映されます。キャッシュ層はなく、ツールを呼び出すたびに上流のソースを最新の状態で照会します。

この MCP サーバーを使って、依存関係ツリー全体を自動的にスキャンできますか？ このサーバーは、名前を指定して渡された個々のパッケージを分析します。ツリー全体を対象にするには、パッケージマネージャー（npm list --depth=0、pip freeze、cargo tree）から依存関係のリストを生成し、直接の依存関係ごとに dependency_risk_assessment を呼び出してください。HTTP API を使って一括処理を自動化できます。

OSS の依存関係の判定で DO_NOT_USE とは何を意味しますか？ 複合スコアが 75 以上に達したか、ハードオーバーライドが発動したことを意味します（CISA KEV への登録と SINGLE_POINT のバス係数が同時に発生）。実際には、パッケージに悪用が確認されている脆弱性があり、それを修正するメンテナーが一人しかいない可能性があることを示します。recommendations 配列に、パッチ適用、置き換え、または移行のいずれが推奨されるかが指定されています。

サプライチェーンセキュリティに関して、Snyk や Dependabot とはどう違いますか？ Snyk と Dependabot は、CVE の検出と PR の自動生成に重点を置いています。メンテナーの健全性、コミュニティの持続可能性、SBOM に関する規制上のリスクは評価しません。このサーバーは、それらのツールが見落とす背景情報を提供します。オープンな CVE がなくても、コミュニティが活動を停止し、メンテナーが一人しかおらず、その人も活動していないパッケージは、CVE データベースには表れない将来的なリスクとなります。

オープンソースのサプライチェーン監視を毎日実行するようにスケジュールできますか？ はい。Apify のスケジュール機能を使って、重要な依存関係に対する security_incident_monitor または dependency_risk_assessment を cron スケジュールで呼び出してください。vulnLevel が上昇した場合や、新たな CISA KEV エントリーが追加された場合に Slack、PagerDuty、またはメールで通知するよう、Webhook を設定してください。

商用の依存関係監査に、公開されている CVE と GitHub のデータを使用することは合法ですか？ はい。NVD と CISA KEV は、この目的のために明示的に提供されている米国政府の公開データベースです。GitHub の公開 API では、利用規約に基づいて公開リポジトリのメタデータにアクセスできます。StackExchange のコンテンツは Creative Commons のライセンスで提供されています。Hacker News のコンテンツは公開されています。このサーバーは、すべてのソースに対し、それぞれの想定された利用条件の範囲内でアクセスします。

SBOM コンプライアンススコアは、組織が現行の規制に準拠していることを意味しますか？ いいえ。sbomCompliance スコアは、Federal Register と Congressional records における SBOM 関連の規制活動の密度に加え、パッケージの技術的な準備状況を示す指標（CI の有無、寛容なライセンス）を反映します。これは分析上の指標であり、コンプライアンス認証ではありません。組織固有の SBOM 義務については、法律の専門家にご相談ください。

dependency_risk_assessment の実行には、どのくらい時間がかかりますか？ 通常は 30〜90 秒です。7 つの上流アクターは、ソースごとに 120 秒のタイムアウトを設定して並列実行されます。通常の負荷では、ほとんどのソースが 15〜40 秒で応答します。接続が早期に切断されないよう、クライアントのタイムアウトは少なくとも 180 秒に設定してください。

OSS サプライチェーンのリスク分析では、どのパッケージエコシステムをサポートしていますか？ このサーバーは、任意のパッケージ名文字列を受け付けます。GitHub での存在感が大きいパッケージ（npm、PyPI、Cargo、Maven、Go modules、Ruby gems）で最も効果を発揮します。GitHub での活動が少なく、商用ディストリビューションとしてのみ提供されているパッケージでは、信頼度の低いスコアが返されます。dependency_risk_assessment の ecosystem パラメーターは検索のヒントとして使われますが、結果を制限するものではありません。 1 回の OSS サプライチェーン評価呼び出しで、複数のパッケージを比較できますか？ compare_package_risks ツールは、package と任意の alternative パラメーターを受け取り、主要パッケージのリスクプロファイルを返します。2 つを超えるパッケージを比較する場合は、compare_package_risks を並列で呼び出し、クライアントで compositeScore フィールドと verdict フィールドを集計してください。

改善にご協力ください

予期しない結果やデータ品質の問題が発生した場合は、実行共有を有効にすると、問題をより迅速にデバッグできます。

1. アカウント設定 > プライバシー に移動します
2. 実行データを公開 Actor 作成者と共有を有効にします

これにより、問題が発生した際に実行の詳細を確認できるため、より迅速に修正できます。データは Actor の開発者にのみ表示され、一般公開されることはありません。

サポート

バグを見つけた場合や機能のリクエストがある場合は、この Actor のページにある Issues タブ で Issue を作成してください。カスタム統合や SLA 要件を伴うエンタープライズ導入については、Apify プラットフォームからお問い合わせください。