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 Agent 直接访问 CVE 记录、CISA KEV 漏洞利用、维护者单点风险评分和 7 个实时情报源的拼写仿冒检测。专为安全工程师、DevSecOps 团队和 AI 辅助工作流打造，无需离开 AI 客户端即可获得达到 SBOM 级别的风险情报。

此 MCP 服务提供 8 种专用工具，可并行查询 GitHub、NVD、CISA KEV、Hacker News、StackExchange、ArXiv 和 Censys，然后将结果合并为有类型定义的开源软件依赖网络图。进程内缓存有效期为 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，Levenshtein 距离为 1
💬 供应链事件讨论	Hacker News	“发现 xz-utils 5.6.0 中的后门”
❓ 开发者迁移和采用信号	StackExchange	“从 requests 迁移到 httpx——安全方面的顾虑”
🔬 学术安全研究论文	ArXiv	“PyPI 中的拼写仿冒：一项系统性研究（2024）”
🌐 面向互联网的基础设施暴露情况	Censys	运行易受攻击的 Log4j 版本的主机
📊 依赖网络图	所有来源	节点 + 边：仓库、维护者、CVE、KEV、讨论
🏥 社区健康指数	GitHub + HN + SE	复刻/星标情绪、问题响应率、0-1 分
📋 感知 SBOM 的风险报告	所有 7 个来源	按类别整理的发现，附严重程度 + CISA 修复步骤

为什么使用 Open Source Supply Chain Risk MCP？

手动审计开源软件供应链既昂贵又耗时。安全工程师手动审查 50 个传递依赖项——交叉核对 NVD、检查 GitHub 提交历史、扫描 PyPI 中的相似名称——需要 2-3 天。CISA KEV 每日更新。ArXiv 每周发布新的漏洞研究。没有团队能靠手动操作跟上进度。

此 MCP 会自动完成整个流程。你的 AI Agent 只需调用一个工具，就能在 30 秒内获得来自 7 个实时来源、带评分且由图谱支持的风险评估。针对单个软件包完成完整尽职调查工作流——风险评分、影响范围、维护者健康状况——费用为 $0.105。商业替代方案的收费高得多。

• 数据始终最新——调用时查询实时 API；5 分钟 TTL 缓存可避免会话内重复收费
• API 访问——可从 Claude Desktop、Cursor、Windsurf、Cline 或任何 HTTP MCP 客户端连接
• 并行执行——所有 7 个数据源通过 Promise.all 并发运行；通常在 30 秒内响应
• 监控——Apify 平台会针对运行失败发出警报；Webhook 会在检测到严重 KEV 时通知 Slack
• 集成——可连接 Zapier、Make、LangChain、LlamaIndex，也可通过任何语言直接发起 HTTP 调用

功能

• 带类型的开源软件依赖网络图 — 基于合并后的多源数据构建包含 7 种节点类型（repo、maintainer、cve、kev、package、discussion、paper、host）和 6 种边类型（depends_on、maintains、affects、discusses、researches、hosts）的图；每次运行最多处理 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，并在多因素风险评分中触发权重为 0.9 的 active_exploitation 因素；自动生成 CISA BOD 22-01 修复指南
• 5 因素加权供应链风险评分 — 漏洞暴露（30%）、巴士因子（20%）、活跃利用（20%）、流行度/攻击面（15%）、社区信号（15%）；风险等级阈值为 0.75/0.50/0.25
• Levenshtein 拼写抢注检测 — 对所有发现的代码库短名称进行 O(n²) 两两编辑距离计算；将距离为 1-2 且星标比低于 0.3 的名称对标记为高度可疑；可疑度公式：(1 - dist/3) * 0.5 + (1 - starRatio) * 0.5；达到 0.6 阈值即计为“可疑”
• 社区健康度索引 — 将分叉与星标比作为情绪代理指标，将问题与星标比用于衡量响应质量，并将 Hacker News/StackExchange 讨论量综合为每个代码库的单一 0-1 健康度指数
• 安全研究趋势跟踪 — 从 ArXiv 标题和 HN 帖子中提取 13 个安全主题关键词；趋势分数 = 最近 90 天的论文数 / 论文总数；呈现通常比正式分配 CVE 提前 4-8 周的披露前威胁研究
• 感知 SBOM 的报告生成 — 将发现分类为已知遭利用漏洞、严重 CVE（CVSS ≥ 9.0）和巴士因子风险（≤ 1 名维护者）；按严重性排序，并为每项发现提供证据字符串和可执行的修复建议
• 5 分钟进程内缓存 — 基于 Map 的 TTL 缓存，以 source:query 为键；同一会话中针对同一软件包的多次工具调用会复用上游数据，并几乎即时返回
• 双 MCP 传输方式 — 为旧版客户端提供 SSE 传输方式（/sse + /messages）；为现代客户端提供 Streamable HTTP（/mcp）；提供用于就绪探测的 /health 端点
• 按工具配置数据源 — 每个工具都接受 sources 数组；默认配置按工具调优（generate_oss_risk_report 使用全部 7 个数据源；assess_research_security_landscape 使用 arxiv + hackernews + stackexchange）

开源供应链风险的使用场景

DevSecOps 流水线安全门禁

平台工程团队将此 MCP 集成到基于 Claude 的代码审查 Agent 中。在合并添加新 npm 依赖的 PR 之前，Agent 会针对软件包名称调用 score_supply_chain_risk。如果评分高于 0.6，或存在任何关联的 KEV 节点，就会阻止合并，直到安全负责人批准。整个门禁流程不到 30 秒，每次检查的成本为 $0.035，远低于一次误报事件的代价。

SBOM 审计和供应商风险管理

采购团队评估 SaaS 供应商时，会让 AI 助手针对供应商声明的关键依赖运行 generate_oss_risk_report。报告会指出第三方库中被列入 CISA KEV 的漏洞、存在弃用风险的单维护者代码库，以及符合 CISA BOD 22-01 要求的 SBOM 修复步骤。过去需要一周人工研究才能完成的尽职调查，如今通过一次 AI 对话即可完成。

事件响应分诊

当新的严重 CVE 出现时（例如 Log4Shell 级别的事件），事件响应团队会使用 CVE 标识符调用 detect_vulnerability_propagation。影响范围分析会显示哪些内部仓库依赖受影响的软件包，以及依赖图中的传播深度。团队可以立即确定哪些系统需要紧急修补，以及修补的优先顺序。

采用软件包前进行审查

一位工程负责人评估三个候选库时，会分别调用 assess_maintainer_risk。其中两个库的 bus factor 高于 0.4，且近期仍有活动。另一个库只有一位维护者，最近一次提交是在 18 个月前，弃用风险为 0.82。团队选择了其中一个更健康的替代方案。总计 0.105 美元的成本，与节省的工程时间相比微不足道。

供应链攻击预警

安全研究团队每周都会针对技术栈关键词调用 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 个来源，并在一次调用中返回按严重程度排序的发现。

4. 使用专用工具深入分析。 如果报告发现高风险维护者，请接着调用 assess_maintainer_risk。如果存在 KEV，请调用 detect_vulnerability_propagation 了解影响范围。每次专用工具调用都会复用第 3 步中缓存的上游数据。

MCP 工具

工具	价格	默认来源	描述
map_dependency_network	$0.035	github, cve, kev, hackernews	绘制开源软件依赖图：节点、边和连接数
assess_maintainer_risk	$0.035	github, cve, kev, hackernews	每个仓库的 bus factor、弃用风险和最近活动日期
detect_vulnerability_propagation	$0.035	github, cve, kev, hackernews	通过依赖图上的 BFS 分析 CVE/KEV 影响范围
analyze_community_health	$0.035	github, cve, kev, hackernews	分析 Fork/Star 情绪、问题响应和讨论量
score_supply_chain_risk	$0.035	github, cve, kev, hackernews, stackexchange	包含各因素明细的 5 因素加权风险评分
detect_typosquat_indicators	$0.035	github, cve, kev, hackernews	基于 Levenshtein 距离和 Star 比率进行两两仿冒包分析
assess_research_security_landscape	$0.035	arxiv, hackernews, stackexchange	ArXiv 论文趋势和社区讨论信号
generate_oss_risk_report	$0.035	全部 7 个来源	全面的 SBOM 感知报告，包含发现和建议

工具参数

每个工具都接受相同的两个参数：

Parameter	Type	Required	Default	Description
query	string	Yes	—	要调查的软件包名称、仓库标识或 OSS 项目（例如，log4j、pallets/flask、numpy）
sources	array of enum	No	Varies by tool	要查询的数据源。可选项：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 分钟缓存意味着会话中对同一查询进行第二次工具调用时会复用上游数据，只需支付 $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

Field	Type	Description
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	处于严重风险级别的仓库数量

generate_oss_risk_report

Field	Type	Description
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

Field	Type	Description
indicators[].package	string	疑似拼写仿冒的软件包名称
indicators[].similarTo	string	与其相似的热门软件包
indicators[].editDistance	number	Levenshtein 编辑距离（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

Field	Type	Description
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

Field	Type	Description
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

Field	Type	Description
entries[].entity	string	节点名称（仓库、CVE、维护者等）
entries[].type	string	节点类型：repo、maintainer、cve、kev、package、discussion
entries[].connections	number	边的总数（入边 + 出边）
entries[].stars	number	Star 数（仅适用于仓库；其他类型为 0）
entries[].severity	number	CVE/KEV 节点的 CVSS 严重性，0-1
totalEntities	number	网络中的节点总数
totalEdges	number	网络中的边总数
avgConnections	number	所有节点的平均边度数

analyze_community_health

Field	Type	Description
assessments[].repo	string	仓库名称
assessments[].discussionVolume	number	与此仓库关联的 Hacker News/StackExchange 讨论数
assessments[].sentimentScore	number	Fork 与 Star 比率的代理指标，0-1
assessments[].issueResponseTime	number	Issue 与 Star 比率倒数的代理指标，0-1
assessments[].healthIndex	number	综合健康评分，0-1
totalAssessed	number	已评估的仓库总数
unhealthyCount	number	healthIndex 低于 0.3 的仓库数
avgHealth	number	所有仓库的平均健康指数

assess_research_security_landscape

Field	Type	Description
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 采用按调用付费定价——每次工具调用收费 $0.035。平台计算费用已包含在内。

场景	工具调用次数	每次调用费用	总费用
快速测试（单个软件包风险评分）	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

你可以为每次运行设置最高支出限额来控制费用。达到预算后，Actor 会停止运行，避免在长时间 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 包装 Actor——最多通过 Promise.all 同时运行 7 个。每个包装 Actor 的运行超时时间为 180 秒，并从其 Apify 数据集中返回最多 500 条数据。

7 个数据源 Actor：

• github — ryanclinton/github-repo-search — 返回仓库元数据，包括 fullName、stars、owner、language、pushedAt、forksCount、openIssuesCount
• cve — ryanclinton/nvd-cve-vulnerability-search — 返回 CVE 记录，包括 cveId、cvssScore、description 和受影响的配置
• kev — ryanclinton/cisa-kev-search — 返回 CISA KEV 条目，包括 cveID 和已确认的遭利用状态
• 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 节点会以权重 1.0 连接到对应的 CVE 节点，从而支持在影响范围分析中完整追踪 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。风险等级阈值：严重 ≥ 0.75，高 ≥ 0.50，中 ≥ 0.25。

detect_vulnerability_propagation — 从每个 CVE/KEV 节点出发，沿完整边集（全部 6 种边类型）执行 BFS，深度最多为 6。统计到达的 repo: 前缀节点 ID。影响范围 = 受影响的仓库数量 / 仓库节点总数。

detect_typosquat_indicators — 对所有 repo 短名称（按 / 拆分并转换为小写）计算两两 Levenshtein 距离，时间复杂度为 O(n²)。评估距离为 1-2 且绝对长度差 ≤ 2 的名称对。每对中星标数较少的仓库被视为 suspicious。结果按可疑度分数降序排序，返回前 20 条。

generate_oss_risk_report — 综合三个类别的发现：存在 KEV 时，触发一条带有 CISA BOD 22-01 指南的 critical 发现；CVSS ≥ 9.0 的 CVE（规范化后 severity ≥ 0.9）会触发一条 critical 发现；超过 3 个仓库的 maintains 边 ≤ 1 时，会触发一条 high 发现。发现按 {critical: 0, high: 1, medium: 2, low: 3} 枚举顺序排序。

阶段 4：响应组装

所有工具都会返回结构化 JSON，并将其包装在包含 type: "text" 的 MCP content 数组中。大多数工具的结果最多为 30 条，以确保响应负载适合大模型处理。服务会妥善处理上游 actor 故障——actor 失败或超时会返回空数组，分析会继续使用其余来源。

最佳实践

1. 先运行 generate_oss_risk_report。 它会查询全部 7 个来源，一次调用仅需 $0.035，即可返回按严重程度排序的发现。根据这些发现决定接下来调用哪些专用工具——只有当报告指出值得深入调查的风险类别时，才为每个工具额外花费 $0.035。

2. 使用准确的软件包名称查询，而不是项目名称。 log4j-core 能匹配到比 log4j 更多的 CVE 描述。pallets/flask 比单独使用 flask 更快找到正确的仓库，因为后者可能会匹配到名称相似但无关的仓库。

3. 合理利用 5 分钟缓存。 如果你先对某个软件包调用 score_supply_chain_risk，然后在 5 分钟内对同一软件包调用 assess_maintainer_risk，第二次调用会复用缓存的上游数据，仅产生 $0.035 的事件费用。安排 AI 会话时，应将针对同一软件包的调用集中在一起。

4. 仅对已确认存在 KEV 的漏洞添加 censys。 Censys 数据有助于了解易受攻击版本在现实中的部署情况，但会增加调用延迟。仅对报告已确认正在被积极利用的软件包使用它。

5. 使用 arxiv 进行披露前的威胁搜寻。 关于特定生态系统（npm、PyPI、Maven Central）的研究论文，往往会在正式分配 CVE 前 4-8 周出现。每周定时调用 assess_research_security_landscape，可以提前提醒安全团队注意新兴攻击模式。

6. 封禁前手动交叉核验仿冒包结果。 Levenshtein 算法标记的是统计异常，并不能确认恶意软件。将高可疑度软件包加入 CI/CD 封禁列表前，务必在其注册表页面上核实。按照这一指标，一个热门库的全新合法分支看起来会与仿冒包完全相同。

7. 使用广播式查询监控生态系统。 npm、PyPI 或 Maven 等查询会返回多种仓库和 CVE，从而比单个软件包查询更全面地绘制依赖网络图。适用于定期开展生态系统级风险评估。

与其他 Apify Actor 组合使用

Actor	组合方式
Website Tech Stack Detector	检测供应商网站使用了哪些 OSS 库，然后将这些库名称传递给 score_supply_chain_risk，立即评估风险
Company Deep Research	在第三方尽职调查工作流中，将供应商 OSS 供应链风险与更广泛的公司情报结合起来
WHOIS Domain Lookup	将可疑的仿冒软件包域名与域名注册数据交叉核查，以识别恶意所有权模式
Website Content to Markdown	将供应商的安全公告页面转换为 Markdown，并与 MCP 风险数据一并提供给 AI Agent，以进行统一评估
Trustpilot Review Analyzer	将评论平台上的开发者社区信任信号与 OSS 供应链风险评分结合起来，更全面地评估供应商
B2B Lead Qualifier	在投入资源评估合作关系之前，先根据潜在技术合作伙伴的 OSS 依赖项健康状况进行筛查
Website Change Monitor	监控供应商安全公告页面的变化；出现新公告时，自动触发 generate_oss_risk_report

限制

• 不进行静态代码分析 — 此服务分析的是仓库元数据、漏洞数据库和社区信号，而非源代码。要进行代码级 SAST 扫描，请搭配使用 Semgrep 或 CodeQL 等专用工具。
• 以 GitHub 为中心发现仓库 — 依赖关系图基于 GitHub 搜索结果构建。私有软件包、内部镜像以及 GitHub 存在感不强的注册表（私有 npm 作用域、内部 Maven 仓库）不可见。
• 不解析传递依赖 — 此服务会识别与查询词相关的仓库，但不会解析 package.json、requirements.txt 或 pom.xml，也不会递归遍历完整的依赖树。
• Levenshtein 仿冒检测需要多个结果 — 仿冒分析会比较搜索结果集中的软件包。返回仓库少于 5 个的查询，成对覆盖范围有限。为获得更好的覆盖范围，请使用生态系统级查询（requests python），而非单个软件包查询。
• CVE 与仓库的匹配基于文本 — 此服务会将 CVE 描述文本与仓库简称进行子字符串匹配。名称通用的仓库（core、utils）可能会产生错误的 CVE 关联。如果仓库名称从未出现在 CVE 文本中，即使确实受到影响，也不会显示漏洞暴露情况。
• Censys 数据反映扫描快照 — Censys 结果表示扫描时检测到的主机，并非实时部署清单。快速修补的部署可能尚未反映在扫描结果中。
• 缓存按实例隔离 — 5 分钟 TTL 缓存位于进程内存中。每个新启动的 Apify Standby 实例都从冷缓存开始。在有许多 AI 会话同时运行的高并发环境中，多个实例并行发生缓存未命中可能导致成本增加。
• 每个来源最多 500 项 — 每个上游 Actor 最多返回 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 Agent 中可调用的工具，用于自动化安全研究和依赖项审查流程
• Claude Desktop — 将 MCP URL 添加到 claude_desktop_config.json，即可直接在 Claude 中交互式讨论供应链风险

故障排除

• 工具返回空的 assessments 数组 — 查询没有返回与搜索词匹配的 GitHub 存储库。请尝试更短或更通用的查询，例如使用 log4j，而不是 org.apache.logging.log4j:log4j-core。请确认 sources 数组中包含 github，因为大多数分析工具都需要 repo 节点才能生成评估结果。

• 仿冒包分析未显示任何指标 — 搜索结果少于 2 个存储库，无法进行成对比较。请使用能匹配某个生态系统或软件包系列的更宽泛查询。例如，colorama 会返回热门软件包以及相关项目，以便进行比较。

• 已知存在漏洞的软件包风险评分低于预期 — CVE 与存储库的匹配基于文本，可能无法匹配存储库名称未出现在 CVE 描述文本中的软件包。请尝试直接使用 CVE ID 作为查询调用 detect_vulnerability_propagation（例如 CVE-2021-44228），以便围绕特定漏洞节点进行分析。

• 工具调用超时 — 7 个上游 Actor 中有一个未能在 180 秒超时期限内响应。服务会妥善处理失败的 Actor，并返回空数组；仍会返回部分结果。请重试调用。如果延迟持续受限，请将 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 是由美国政府提供、用于安全研究和漏洞修复的官方数据库。
• 请勿使用此工具识别你无权评估的系统中的漏洞。
• 仿冒包检测结果是统计指标，并非对软件包恶意性的确认。请勿仅凭 Levenshtein 相似度评分公开指控软件包作者怀有恶意。
• 有关网页抓取和数据收集合法性的指南，请参阅 Apify 指南。

常见问题

完成一次开源供应链风险审计需要调用多少次工具？ 对单个软件包进行全面审计通常需要调用工具 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 状态、较低的巴士系数以及名称异常等风险指标。如需检查代码级问题，请将此 MCP 与 Semgrep 或 CodeQL 等专用 SAST 工具结合使用。

开源供应链风险评分具体是如何运作的？ 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 Agent，而不是构建流水线。这两种方式互为补充：在 CI/CD 中使用 Snyk/Mend，在 AI 会话中使用此 MCP 进行调查分析。

爆炸半径估算有多准确？ 爆炸半径是基于可用公开数据进行的图论近似估算。它反映的是观测到的依赖关系图中的连接情况，而不是所有软件包注册表中的完整传递依赖树。GitHub Fork 和社区讨论较多的软件包，其爆炸半径会高于公开可见度较低但风险相当的软件包。请将其视为相对风险指标，而非精确的下游影响数量。

我可以定期使用此 MCP 监控开源供应链风险吗？ 可以。定期监控最好通过 Apify API 完成：向 actor 端点发送 POST 请求并附上目标软件包，处理 JSON 输出，然后通过 Webhook 将高严重性发现发送到你的告警系统。你也可以使用标准的定时 Apify actor，定期调用此 MCP 的 HTTP 端点。

收集这些开源安全数据合法吗？ 合法。所有数据来源均为公开数据。NVD 和 CISA KEV 是美国政府的官方数据库。根据 GitHub 的服务条款，GitHub 公开代码库的元数据可公开访问，用于研究和开发。Hacker News、StackExchange 和 ArXiv 都是开放的公共平台。Censys 根据研究用途许可提供互联网扫描数据。

如果工具调用期间 7 个数据源之一发生故障，会怎样？ 该服务会妥善处理上游故障。如果某个 actor 超时或返回错误，其结果会替换为空数组，分析会继续使用其余数据源。你会收到部分结果，而不是错误响应。由于工具已执行，仍会收取工具事件费用。

缓存如何运作？它会影响我的费用吗？ 5 分钟的进程内缓存可避免在单个 AI 会话中重复产生上游费用。如果你先对 log4j 调用 score_supply_chain_risk，然后在 5 分钟内对 log4j 调用 assess_maintainer_risk，第二次调用会复用第一次调用缓存的上游数据。每次调用仍需支付 $0.035 的工具事件费用，但不会再次收取上游数据获取费用。缓存按实例隔离；每个新的 Apify Standby 实例启动时缓存均为空。

我可以将它连接到 Cursor、Windsurf 或其他编码助手吗？ 可以。任何支持 Streamable HTTP 传输的 MCP 兼容客户端都能使用 /mcp 端点。对于基于 SSE 的客户端（较旧的 MCP 实现），请改用 /sse 端点。在 Authorization: Bearer 标头中传入你的 Apify token。 开源供应链风险分析与传统 SBOM 工具有什么区别？ 传统 SBOM 工具（CycloneDX、SPDX 生成器）会根据构建清单列出你的依赖项。此 MCP 会利用实时情报评估这些依赖项的风险：哪些漏洞目前正遭到主动利用、哪些维护者已停止活跃、哪些软件包具有拼写仿冒特征。使用 SBOM 工具列出你所使用的依赖项；使用此 MCP 评估其风险。

开源供应链风险分析如何检测跨生态系统的拼写仿冒包？ detect_typosquat_indicators 工具会计算查询返回的所有仓库短名称之间的两两 Levenshtein 编辑距离。编辑距离为 1-2 且星标数差异较大（starRatio 较低）的名称对会被判定为具有较高的可疑度。搜索 requests 之类的查询会从 GitHub 搜索结果中找出相似的软件包名称；随后，该工具会比较每一对名称并按可疑度排序。若要扫描更广泛的生态系统，请使用 requests python 等查询，以获取更多用于比较的候选项。

帮助我们改进

如果你遇到问题，可以在 Apify 账户中启用运行共享，帮助我们更快地进行调试：

1. 前往 账户设置 > 隐私
2. 启用 与公开 Actor 创建者共享运行记录

这样一来，出现问题时我们就能查看你的运行详情，从而更快地修复问题。你的数据只有 Actor 开发者可见，不会公开。

支持

发现错误或有功能请求？请在此 Actor 页面上的 问题标签页中提交问题。对于自定义集成或企业安全工作流，请通过 Apify 平台联系我们。