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"
    }
  }
}

---

为 AppSec 团队、工程负责人和平台工程师提供开源供应链风险评估，满足他们对 CVE 扫描器以外功能的需求。此 MCP 服务汇总 7 个实时数据源——GitHub、NVD、CISA KEV、StackExchange、Hacker News、Federal Register 和 Congress.gov——生成综合依赖风险评分（0-100），并提供从 LOW_RISK 到 DO_NOT_USE 的机器可读判定。

漏洞数据库会告诉你某个 CVE 是否存在。此服务则会告诉你项目是否会修复它——它综合维护者 bus factor、社区健康状况、SBOM 法规风险以及当前漏洞利用状态，为每次价值 $0.045 的工具调用提供一项可执行评估。无需订阅、无需按席位付费，也不会像仅关注 CVE 的方案那样存在盲区。

可以访问哪些数据？

数据点	来源	示例
📊 综合依赖风险评分（0-100）	全部 7 个数据源	compositeScore: 71, verdict: "HIGH_RISK"
👤 维护者 bus factor 和基尼系数	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
📜 许可证类型和 copyleft 风险	GitHub	complianceLevel: "MOSTLY_COMPLIANT", licenseRisk: 0
🏛️ SBOM 法规信号	Federal Register + Congress	regulatorySignals: 6, sbomBills: 3
💬 开发者问答活动	StackExchange	discussions: 31, answeredQuestions: 24
📰 安全事件提及	Hacker News	newsmentions: 9, hnPoints: 340
⚠️ 通俗易懂的风险信号	综合结果	"3 CISA KEV entries — actively exploited vulnerabilities"
📋 优先级排序后的修复建议	综合结果	"Critical CVEs present — patch immediately or replace"

为什么使用 Open Source Software Supply Chain MCP Server？

大多数依赖项审计工作流始于 CVE 扫描器，也止于 CVE 扫描器。你得到的只是一份 CVE ID 和严重性评级列表，却不了解项目是否正在积极维护、社区是否正在萎缩，或联邦法规是否已要求为整个依赖树提供 SBOM 文档。要手动整合这些信息——查阅 GitHub、NVD、CISA KEV、Stack Overflow 和法规数据库——每个软件包都要花上数小时。

此 MCP 服务可自动完成整套情报处理流程。一次工具调用即可并行启动 7 个 Actor，按 4 个独立维度对结果评分，并返回包含佐证信号和优先级排序建议的结构化判定。一个存在严重 CVE、却有 500 名活跃贡献者的软件包，与存在同一 CVE、但只有一名不活跃维护者的软件包，风险截然不同。

• 定时运行——每周审计关键依赖项，在新 CVE、KEV 新增记录或贡献者离开演变成安全事件之前及时发现
• API 访问——在 CI/CD 流水线中通过 Python、JavaScript 或任何 HTTP 客户端触发评估
• 代理轮换——所有上游数据获取均使用 Apify 内置的代理基础设施，确保大规模访问的可靠性
• 监控——定时运行发现新的 HIGH_RISK 软件包或评分意外升高时，通过 Slack 或电子邮件接收提醒
• 集成——将结果发送到 Zapier、Make、Jira 或 ITSM 平台，在判定发生变化时自动创建工单

功能

• 综合依赖风险评分（0-100），使用加权公式：漏洞暴露度（35%）、关键维护者风险（25%）、社区健康度反向指标（20%）、SBOM 合规性反向指标（20%）
• 维护者关键性分析，计算贡献者基尼系数——检测只有一名维护者的项目，避免其离职后代码库无人维护
• 活跃度近期性评分——对 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
• 许可证 copyleft 检测——将 GPL、AGPL、LGPL 和 SSPL 许可证与 MIT、Apache、BSD、ISC 等宽松许可证进行分类对比，评估企业分发风险
• SBOM 合规准备度——扫描 Federal Register 和 Congress.gov，查找影响该软件包监管范围的现行 SBOM 强制要求和国会法案
• 社区健康指数——综合 GitHub 星标（35 分）、StackExchange 已解答问题（25 分）、Hacker News 积分总数（25 分）和跨信号生态活力（15 分）
• 并行 Actor 执行——全部 7 个数据源 Actor 并发运行，每个数据源超时为 120 秒，最大限度降低端到端延迟
• 8 个专用工具——涵盖完整综合评估，以及面向定向调查工作流的单一维度查询
• 支出限额执行——每次工具调用前都会检查单次运行的费用预算，防止自动化流水线产生失控费用

OSS 供应链风险情报的使用场景

AppSec 团队依赖项审计

负责漏洞管理的 AppSec 工程师需要确定哪些传递依赖项需要立即处理。仅有 CVE ID 无法说明项目是每季度发布补丁，还是已经弃置两年。dependency_risk_assessment 工具一次调用即可返回关键维护者、补丁历史信号和社区健康度，让团队能够准确分级，而不是把每个 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 会返回结构化 JSON 判定结果（LOW_RISK、ACCEPTABLE、REVIEW_NEEDED、HIGH_RISK、DO_NOT_USE），可直接用于 CI 的通过／失败逻辑，无需手动解读评分。

供应商与采购尽职调查

评估捆绑 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 token 作为 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 项	综合风险评分（0-100），涵盖关键人员系数、CVE 暴露、社区健康状况和 SBOM 合规性。返回判定结果和建议。
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	Copyleft 与宽松许可证分类、SBOM 监管要求、许可证冲突检测。
community_health_score	$0.045	GitHub + StackExchange + HN	星标数、问答量、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 外的所有工具	字符串	是	—	包或库名称（例如 "lodash"、"openssl"、"log4j"）
ecosystem	dependency_risk_assessment	字符串	否	—	生态系统提示：npm、pypi、cargo、maven、go
alternative	compare_package_risks	字符串	否	—	用于并列比较的替代包名称
topic	sbom_regulatory_tracker	字符串	否	"software supply chain SBOM"	要在 Federal Register 和 Congress 中跟踪的监管主题

输入示例

对关键库进行全面依赖风险评估：

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

比较两个备选 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 构件，已知时请包含 group 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	Bus factor 风险子评分，范围为 0-100
busFactor.contributors	number	在匹配的仓库中检测到的贡献者数量上限
busFactor.giniCoefficient	number	提交分布的基尼系数（0 = 均等，1 = 单一贡献者）
busFactor.busFactorLevel	string	HEALTHY / ADEQUATE / CONCENTRATED / FRAGILE / SINGLE_POINT
busFactor.signals	string[]	通俗易懂的 Bus factor 风险信号
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	许可证风险累积值（数值越高，Copyleft 暴露程度越高）
sbomCompliance.complianceLevel	string	NON_COMPLIANT / GAPS / PARTIAL / MOSTLY_COMPLIANT / FULLY_COMPLIANT
sbomCompliance.signals	string[]	通俗易懂的合规信号
allSignals	string[]	汇总全部四项子评分的所有信号
recommendations	string[]	按优先级排序的修复建议

综合风险评分方法

评分范围	判定	说明
0-14	LOW_RISK	维护良好、漏洞记录干净、社区实力强
15-34	ACCEPTABLE	存在轻微隐患；需持续关注，但使用安全
35-54	REVIEW_NEEDED	维护者集中度或 CVE 暴露程度中等；建议团队审核
55-74	HIGH_RISK	存在严重 CVE、仅有一位维护者，或社区活跃度下降；应制定修复计划
75-100	DO_NOT_USE	存在正在被利用的漏洞，或项目已被弃用

综合公式对漏洞暴露的权重最高（35%），因为正在发生的漏洞利用代表最紧迫的风险。维护者集中度（25%）次之，因为项目被弃用后，未来的漏洞将无法修复。社区健康状况和 SBOM 合规性各占 20%，作为衡量长期可持续性的先行指标。

**硬性覆盖规则：**如果某个软件包同时存在 CISA KEV 条目，且其维护者集中度为 SINGLE_POINT，则无论综合评分数值如何，均判定为 DO_NOT_USE。

评估 OSS 供应链风险需要多少费用？

此 MCP 服务采用按事件付费模式——每次工具调用收费 $0.045。平台计算费用已包含在内。对于触及支出限额的失败调用，不会向你收费。

场景	工具调用次数	单次调用费用	总费用
快速测试——单个软件包	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 的开发者计划起价为每月 $98，可提供 CVE 和许可证数据，但不包含维护者健康状况、社区可持续性或 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 actor，每个来源分配 512 MB 内存，超时时间为 120 秒。这 7 个 actor 分别是：

• github-repo-search — 公开仓库元数据：星标数、复刻数、贡献者人数、最近推送时间、未关闭的 Issue 数、许可证 SPDX 标识符，以及 CI/Actions 是否存在的标记
• nvd-cve-vulnerability-search — 国家漏洞数据库中的 CVE 条目，包含 CVSS v3 严重级别（CRITICAL、HIGH、MEDIUM、LOW）、发布日期和受影响的产品版本范围
• cisa-kev-search — CISA 已知遭利用漏洞目录条目，其中的 knownRansomwareCampaignUse 字段表示已确认与勒索软件相关
• stackexchange-search — Stack Overflow 及相关问答：问题数、is_answered 标记和回答数，用作社区支持度的代理指标
• hacker-news-search — HN 故事数和总得分，用作科技社区安全事件认知度的代理指标
• federal-register-search — 标题和摘要字段中匹配 sbom、software bill 或 supply chain 关键词的《联邦公报》条目
• congress-bill-search — 法案标题中包含 software、cyber 或 supply chain 的国会法案

只需较少来源的工具只会调度相关子集。maintainer_bus_factor 使用 2 个 actor；vulnerability_exposure_timeline 使用 2 个；sbom_regulatory_tracker 使用 2 个。这样可以降低针对性查询的延迟和成本。

阶段 2：四维评分

scoring.ts 模块会对汇总数据应用四种独立模型：

维护者因子模型（0-100 风险量表）： 贡献者人数对应一个基础风险分数：单个维护者 = 40 分，2-3 名贡献者 = 25 分，4-5 名 = 15 分，6-10 名 = 8 分。随后，根据匹配仓库中贡献者人数的分布，使用公式 sumDiff / (n * totalSum) 计算 Gini 系数；其中贡献数按升序排列，并按索引加权。Gini 分数最多额外贡献 20 分。活动时效性根据距上次推送的天数增加 0-20 分：90 天内仍活跃得 0 分，90-180 天得 8 分，180-365 天得 15 分，超过一年未活动得 20 分。

漏洞暴露模型（0-100 风险量表）： CVE 严重级别对应分值——CRITICAL × 10、HIGH × 5、MEDIUM × 2，最高 40 分。CISA KEV 条目每条得 8 分，每个已确认的勒索软件活动另加 5 分，最高 35 分。发布超过 90 天的 CVE 每条得 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 正向量表）： Copyleft 许可证（GPL、AGPL、LGPL、SSPL）会使风险累加值增加 3 分；缺少许可证会增加 5 分。许可证分数会根据此累加值反向计分，最高 30 分。匹配 SBOM 关键词的《联邦公报》条目最多贡献 25 分；匹配的国会法案最多贡献 25 分；CI/宽松许可证就绪指标（存在 GitHub Actions 且使用 MIT/Apache/BSD 许可证）最多贡献 20 分。

第 3 阶段：综合评分与判定结果分配

综合公式对四项子评分进行加权：

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 阶段：信号汇总与建议生成

将四个模型的信号拼接为一个扁平的 allSignals 数组，便于使用。建议根据条件检查生成：严重 CVE 会触发立即修补建议，CISA KEV 条目会触发紧急行动建议，社区健康度不佳会触发迁移建议，较高的巴士因子会触发分叉或替换建议，Copyleft 许可证风险会触发法律审查建议。

最佳实践提示

1. 搜索 CVE 时使用包含完整生态系统信息的名称。 搜索 "struts" 得到的相关 CVE 少于搜索 "apache struts"。对于 Maven 构件，已知时请包含 group ID。
2. 先运行 dependency_risk_assessment，再使用专门的工具深入分析。 完整评估会返回全部四项子评分。如果 vulnExposure.score 占主导，请继续使用 vulnerability_exposure_timeline 获取完整的 CVE 列表。
3. 采用新依赖前，使用 compare_package_risks 进行交叉比较。 使用当前软件包及其主要替代品调用该工具，即可一次获取相对风险概况。
4. 为生产环境关键路径上的依赖安排 security_incident_monitor。 Apify 支持每日定时运行。当 vulnLevel 升至 CRITICAL 时，可配合 webhook 向 Slack 或 PagerDuty 发送通知。
5. 结合巴士因子评估社区健康度，不要单独看其中一项。 THRIVING 的社区若巴士因子为 SINGLE_POINT，仍然很脆弱——社区活跃的可能是用户，而非贡献者。得出软件包是否安全的结论前，请检查两项子评分。
6. 在企业采购周期开始前使用 sbom_regulatory_tracker。 监管环境变化迅速，在采购评审委员会审查前每季度运行一次，可及时发现新的联邦要求，避免形成合规缺口。
7. 结合静态分析工具，实现纵深防御。 此服务可覆盖静态扫描器容易遗漏的行为和社区信号。对于代码级依赖分析，可搭配 Syft 或 OWASP Dependency-Check，并通过 API 将综合风险评分纳入现有工作流。

与其他 Apify actor 组合使用

Actor	组合方式
OSS Dependency Risk Report	运行此 actor，为利益相关者生成格式化的 HTML/PDF 供应链风险报告；使用此 MCP 对标记的软件包进行交互式 AI 驱动调查
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 较低并不能排除发生过事件。
• 无法查看私有软件包和内部 Fork。 数据仅限公开 GitHub 仓库。内部 Fork 或专有发行版本不在此工具的适用范围内。

集成

• Zapier — 收到新的 CVE 警报时触发 security_incident_monitor 调用；如果 vulnLevel 为 CRITICAL 或 HIGH，则创建 Jira 工单
• Make — 构建自动化依赖项审计工作流，对软件包列表运行 dependency_risk_assessment，并将 HIGH_RISK 结果转发至审核队列
• Google Sheets — 将综合风险评分和所有信号导出到依赖项风险登记表，以供利益相关方查看
• Apify API — 使用 HTTP API 和结构化 JSON 响应，将供应链检查直接嵌入 CI/CD 流水线
• Webhooks — 定期运行安全监控并发现判定结果变化时，向 Slack 或 PagerDuty 发送 POST 通知
• LangChain / LlamaIndex — 在 AI 安全分析 Agent 中将此 MCP 用作工具，以调查依赖项树并生成风险说明

故障排除

• 对于预期存在许多漏洞的软件包，CVE 数量偏少 — CVE 匹配基于文本。请尝试更具体的查询：例如，将 "spring" 换成 "spring framework" 或 "pivotal spring"。也可以尝试使用该软件包在 NVD 产品名称中显示的规范供应商名称。
• 已知由单一维护者维护的项目却显示 Bus factor 为 HEALTHY — 按软件包名称搜索 GitHub 仓库时，可能会返回热门分支或无关项目，从而虚增贡献者数量。请检查 signals 数组；无论综合评分如何，集中度风险信号都会追加到其中。
• dependency_risk_assessment 返回空信号 — 如果所有 7 个上游 Actor 都返回空数据集，综合评分将默认为零，且不会生成任何信号。请检查软件包名称是否拼写正确，并在 status.apify.com 确认 Apify 平台状态。
• 首次调用时出现达到支出上限的错误 — 单次运行的支出上限可能设置得过低。每次工具调用费用为 $0.045；请确保单次调用的运行预算至少为 $0.10，或 100 个软件包批量调用的预算至少为 $5.00。
• dependency_risk_assessment 出现超时错误 — 此工具会分派 7 个 Actor，每个 Actor 的超时时间为 120 秒。在负载较高时，总延迟可能达到 60-90 秒。请将客户端超时时间增加到至少 180 秒。

负责任地使用

• 此服务仅访问 GitHub、NVD、CISA、StackExchange、Hacker News、Federal Register 和 Congress.gov 上公开可用的数据。
• NVD 和 CISA KEV 是美国政府的官方数据库。GitHub 公开仓库的元数据可依据 GitHub 的服务条款公开访问。
• 风险评分是分析指标，并非法律合规判定。未经合格的安全和法律专业人士咨询，请勿将评分作为采购或合规决策的唯一依据。
• 请勿使用此服务，根据 Bus factor 指标构建自动拒绝名单，在未经人工审核的情况下对开源维护者造成不利影响。
• 如需了解网页抓取合法性的指南，请参阅 Apify 的指南。

常见问题

开源供应链风险评估与标准 CVE 扫描器有何不同？ 标准 CVE 扫描器会报告存在哪些 CVE。此服务还会评估维护者 Bus factor（谁会修复问题）、社区健康状况（项目是否仍具可行性）、许可证合规性（是否可以合法分发），以及 SBOM 监管背景（是否需要记录该信息）。一个存在 1 个严重 CVE、但拥有 500 名活跃贡献者的社区的软件包，与一个存在相同 CVE、但只有 1 名不活跃维护者的软件包，风险截然不同。 Gini 系数用于分析 OSS 总线系数时有多准确？ Gini 系数根据 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，监控关键路径依赖项。配置 webhook，在 vulnLevel 升级或出现新的 CISA KEV 条目时通知 Slack、PagerDuty 或电子邮件。

将公开的 CVE 和 GitHub 数据用于商业依赖项审计合法吗？ 合法。NVD 和 CISA KEV 是美国政府公共数据库，明确用于此类用途。GitHub 的公共 API 根据其服务条款提供对公共仓库元数据的访问。StackExchange 内容采用知识共享许可。Hacker News 内容为公开内容。本服务会按照所有来源的预期使用方式访问数据。

SBOM 合规性评分是否意味着我的组织符合现行法规？ 不是。sbomCompliance 评分反映了《联邦公报》和国会记录中与 SBOM 相关的法规活动密度，以及软件包的技术准备情况指标（是否存在 CI、许可是否宽松）。这是一个分析信号，而非合规认证。请咨询法律顾问，以确定您具体的 SBOM 义务。

一次完整的 dependency_risk_assessment 调用需要多长时间？ 通常为 30-90 秒。7 个上游 Actor 会并行运行，每个来源的超时时间为 120 秒。正常负载下，大多数来源会在 15-40 秒内响应。请将客户端超时设置为至少 180 秒，以避免连接过早断开。

OSS 供应链风险分析支持哪些软件包生态系统？ 此服务接受任意软件包名称字符串。对于在 GitHub 上有大量活动的软件包，效果最佳：npm、PyPI、Cargo、Maven、Go modules、Ruby gems。仅以商业形式分发且 GitHub 活动极少的软件包，返回的评分置信度会较低。dependency_risk_assessment 中的 ecosystem 参数用于提供搜索提示，但不会限制搜索结果。 我可以在一次 OSS 供应链评估调用中比较多个软件包吗？ compare_package_risks 工具接受 package 和可选的 alternative 参数，并返回主要软件包的风险概况。要比较两个以上的软件包，请并行调用 compare_package_risks，并在客户端中汇总 compositeScore 和 verdict 字段。

帮助我们改进

如果你遇到意外结果或数据质量问题，可以启用运行共享，帮助我们更快地排查问题：

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

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

支持

发现错误或有功能请求？请在此 Actor 页面上的 问题标签页中提交问题。如需定制集成或有 SLA 要求的企业部署，请通过 Apify 平台联系我们。