Open Source Software Supply Chain MCP Server

> View on ApifyForge | Use on Apify Store

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf):```json
{
"mcpServers": {
"open-source-software-supply-chain-mcp": {
"url": "https://ryanclinton--open-source-software-supply-chain-mcp.apify.actor/mcp"
}
}
}

---

Open source supply chain risk assessment for AppSec teams, engineering leads, and platform engineers who need more than a CVE scanner. This MCP server aggregates 7 live data sources — GitHub, NVD, CISA KEV, StackExchange, Hacker News, Federal Register, and Congress.gov — into a composite Dependency Risk Score (0-100) with a machine-readable verdict from `LOW_RISK` to `DO_NOT_USE`.

Vulnerability databases tell you a CVE exists. This server tells you whether the project will ever fix it — by combining maintainer bus factor, community health, SBOM regulatory exposure, and active exploitation status into one actionable assessment per $0.045 tool call. No subscription, no per-seat pricing, no CVE-only blindspots.

## What data can you access?

| Data Point | Source | Example |
|------------|--------|---------|
| 📊 Composite Dependency Risk Score (0-100) | All 7 sources | `compositeScore: 71, verdict: "HIGH_RISK"` |
| 👤 Maintainer bus factor + Gini coefficient | GitHub | `busFactorLevel: "SINGLE_POINT", giniCoefficient: 0.87` |
| 🔴 Critical CVE count and severity distribution | NVD | `criticalCVEs: 4, highCVEs: 9` |
| ⚡ CISA Known Exploited Vulnerabilities | CISA KEV | `kevCount: 3, ransomwareCampaignUse: "Known"` |
| 📅 Patch timeline: CVEs older than 90 days | NVD | `unfixedCVEsOver90Days: 5` |
| 🏥 Community health level and trajectory | GitHub + StackExchange + HN | `healthLevel: "GROWING", stars: 14200` |
| 📜 License type and copyleft risk | GitHub | `complianceLevel: "MOSTLY_COMPLIANT", licenseRisk: 0` |
| 🏛️ SBOM regulatory signals | Federal Register + Congress | `regulatorySignals: 6, sbomBills: 3` |
| 💬 Developer Q&A activity | StackExchange | `discussions: 31, answeredQuestions: 24` |
| 📰 Security incident mentions | Hacker News | `newsmentions: 9, hnPoints: 340` |
| ⚠️ Plain-language risk signals | Composite | `"3 CISA KEV entries — actively exploited vulnerabilities"` |
| 📋 Prioritized remediation recommendations | Composite | `"Critical CVEs present — patch immediately or replace"` |

## Why use Open Source Software Supply Chain MCP Server?

Most dependency auditing workflows start and end with a CVE scanner. You receive a list of CVE IDs, severity ratings, and no context on whether the project is actively maintained, whether the community is shrinking, or whether a federal mandate now requires SBOM documentation for your entire dependency tree. Assembling that picture manually — across GitHub, NVD, CISA KEV, Stack Overflow, and regulatory databases — takes hours per package.

This MCP server automates the entire intelligence pipeline. One tool call dispatches 7 actors in parallel, scores the results across 4 independent dimensions, and returns a structured verdict with supporting signals and prioritized recommendations. A package with one critical CVE and 500 active contributors is a very different risk from one with the same CVE and a single dormant maintainer.

- **Scheduling** — run weekly supply chain audits on critical dependencies to detect new CVEs, KEV additions, or contributor departures before they become incidents
- **API access** — trigger assessments from Python, JavaScript, or any HTTP client inside your CI/CD pipeline
- **Proxy rotation** — all upstream data fetching uses Apify's built-in proxy infrastructure for reliable access at scale
- **Monitoring** — receive Slack or email alerts when scheduled runs flag new `HIGH_RISK` packages or unexpected score increases
- **Integrations** — pipe results to Zapier, Make, Jira, or your ITSM platform to create tickets automatically on verdict changes

## Features

- **Composite Dependency Risk Score (0-100)** using a weighted formula: vulnerability exposure (35%), bus factor risk (25%), inverse community health (20%), inverse SBOM compliance (20%)
- **Maintainer bus factor analysis** with contributor Gini coefficient calculation — detects single-maintainer projects where one departure abandons the codebase
- **Activity recency scoring** — penalizes repositories with no commits in 90, 180, or 365+ days with escalating risk contributions up to 20 points
- **CVE severity distribution** from NVD — maps CRITICAL (×10 pts), HIGH (×5 pts), and MEDIUM (×2 pts) counts to a 40-point exposure subscale
- **CISA KEV cross-reference** — identifies CVEs with confirmed active exploitation in the wild, scoring 8 points each on the vulnerability subscale
- **Ransomware campaign detection** — applies an additional 5-point multiplier for CVEs confirmed used in ransomware campaigns via the CISA KEV `knownRansomwareCampaignUse` field
- **Hard-override rule** — any package with both a CISA KEV entry and a `SINGLE_POINT` bus factor is forced to `DO_NOT_USE` verdict regardless of the numeric composite score
- **License copyleft detection** — classifies GPL, AGPL, LGPL, and SSPL licenses against permissive alternatives (MIT, Apache, BSD, ISC) for enterprise distribution risk
- **SBOM compliance readiness** — scans Federal Register and Congress.gov for active SBOM mandates and congressional bills affecting the package's regulatory footprint
- **Community health index** — weighs GitHub stars (35 pts), StackExchange answered questions (25 pts), Hacker News point totals (25 pts), and cross-signal ecosystem vibrancy (15 pts)
- **Parallel actor execution** — all 7 data source actors run concurrently with 120-second per-source timeouts, minimizing end-to-end latency
- **8 specialized tools** — from full composite assessment to focused single-dimension queries for targeted investigation workflows
- **Spending limit enforcement** — every tool call checks the per-run charge budget before executing, preventing runaway costs in automated pipelines

## Use cases for OSS supply chain risk intelligence

### AppSec team dependency audits

AppSec engineers responsible for vulnerability management need to prioritize which transitive dependencies require immediate action. A CVE ID alone does not tell you whether the project ships patches quarterly or has been abandoned for two years. The `dependency_risk_assessment` tool returns bus factor, patch history signals, and community health in one call, letting teams triage accurately instead of treating every CVE as equally urgent.

### Engineering lead package selection

Before adopting a new library, a senior engineer or tech lead wants to know whether it is actively maintained, whether the license creates distribution obligations, and whether it has a history of unpatched critical CVEs. The `compare_package_risks` tool profiles a candidate package alongside its alternative, so the decision is based on community data rather than GitHub star counts alone.

### SBOM compliance and procurement

Organizations subject to Executive Order 14028, NIST guidelines, or contractual SBOM requirements need to track which regulations apply to their OSS usage. The `sbom_regulatory_tracker` tool queries Federal Register and Congress.gov in real time, scoring the density of SBOM-related regulatory activity so compliance teams stay ahead of new requirements before they become audit findings.

### Security incident response

When a supply chain attack surfaces — Log4Shell, XZ Utils, SolarWinds — incident responders need to know immediately how severe the CVE profile is and whether CISA has confirmed active exploitation. The `security_incident_monitor` tool cross-references Hacker News breach coverage with NVD CVE data and the CISA KEV catalog simultaneously, returning a structured `vulnLevel` and all associated signals.

### Platform engineering and CI/CD gates

Platform engineers embedding dependency risk checks in build pipelines need a machine-readable verdict they can gate on. `dependency_risk_assessment` returns a structured JSON verdict (`LOW_RISK`, `ACCEPTABLE`, `REVIEW_NEEDED`, `HIGH_RISK`, `DO_NOT_USE`) that maps cleanly to CI pass/fail logic without manual score interpretation.

### Vendor and procurement due diligence

Procurement teams evaluating software vendors who bundle OSS components need defensible evidence of supply chain health. Running `dependency_risk_assessment` across a vendor's declared dependencies produces documented risk scores that can be included in due diligence artifacts and contract negotiations.

## How to use OSS supply chain risk intelligence

1. **Connect the MCP server** — add `https://open-source-software-supply-chain-mcp.apify.actor/mcp` to your MCP client (Claude Desktop, Cursor, Windsurf, Cline, or any MCP-compatible tool). Include your Apify API token as `Authorization: Bearer YOUR_TOKEN`.
2. **Choose a tool for your use case** — for a full risk picture, call `dependency_risk_assessment` with a package name like `"lodash"` or `"openssl"`. For a focused check, call `vulnerability_exposure_timeline` or `maintainer_bus_factor` directly.
3. **Read the verdict and signals** — the response includes a `verdict` field (`LOW_RISK` through `DO_NOT_USE`), a `compositeScore` from 0-100, and an `allSignals` array with plain-language risk explanations.
4. **Act on the recommendations** — the `recommendations` array in each response contains specific action items: patch urgency, alternative package evaluation, license review requirements, or migration planning.

## MCP tools

| Tool | Price | Data Sources | Description |
|------|-------|-------------|-------------|
| `dependency_risk_assessment` | $0.045 | All 7 | Full composite risk score (0-100) with bus factor, CVE exposure, community health, and SBOM compliance. Returns verdict + recommendations. |
| `maintainer_bus_factor` | $0.045 | GitHub + StackExchange | Contributor Gini coefficient, contributor count, activity recency score. Identifies single-maintainer abandonment risk. |
| `vulnerability_exposure_timeline` | $0.045 | NVD + CISA KEV | CVE severity distribution, active exploitation status, CVEs older than 90 days without patches. |
| `license_compliance_check` | $0.045 | GitHub + Federal Register | Copyleft vs permissive classification, SBOM regulatory requirements, license conflict detection. |
| `community_health_score` | $0.045 | GitHub + StackExchange + HN | Stars, Q&A volume, Hacker News visibility. Returns `healthLevel`: DEAD through THRIVING. |
| `sbom_regulatory_tracker` | $0.045 | Federal Register + Congress | Active SBOM mandates, federal regulations, congressional bills on software supply chain. |
| `security_incident_monitor` | $0.045 | HN + NVD + CISA KEV | Breach reports, new CVE disclosures, CISA KEV additions for a specific package. |
| `compare_package_risks` | $0.045 | GitHub + NVD + KEV + SE + HN | Side-by-side composite risk profile for package selection decisions. |

### Tool input parameters

| Parameter | Tool | Type | Required | Default | Description |
|-----------|------|------|----------|---------|-------------|
| `package` | All except `sbom_regulatory_tracker` | string | Yes | — | Package or library name (e.g., `"lodash"`, `"openssl"`, `"log4j"`) |
| `ecosystem` | `dependency_risk_assessment` | string | No | — | Ecosystem hint: `npm`, `pypi`, `cargo`, `maven`, `go` |
| `alternative` | `compare_package_risks` | string | No | — | Alternative package name for side-by-side comparison |
| `topic` | `sbom_regulatory_tracker` | string | No | `"software supply chain SBOM"` | Regulatory topic to track in Federal Register and Congress |

### Input examples

**Full dependency risk assessment for a critical library:**```json
{
  "tool": "dependency_risk_assessment",
  "package": "log4j",
  "ecosystem": "maven"
}

Compare two alternative HTTP client libraries:```json
{
"tool": "compare_package_risks",
"package": "axios",
"alternative": "got"
}

**Track current SBOM regulation landscape:**```json
{
  "tool": "sbom_regulatory_tracker",
  "topic": "software bill of materials executive order"
}

Input tips

• Use full ecosystem-qualified names for CVE matching — "apache struts" returns more targeted CVEs than "struts". For Maven artifacts, include the group ID where known.
• Start with dependency_risk_assessment — the full composite covers the most ground per dollar. Use focused tools for follow-up investigation on specific flagged subscores.
• Pair vulnerability_exposure_timeline with security_incident_monitor — for known high-risk packages, run both to get CVE history alongside community breach reporting.
• Use sbom_regulatory_tracker quarterly — the regulatory landscape for OSS supply chain changes frequently; a quarterly run captures new Federal Register actions and congressional bill progress.
• Set a spending limit per run — in automated pipelines, configure the Apify run's maximum cost to prevent runaway charges if a batch query list is larger than expected.

Output example```json

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

## Output fields

| Field | Type | Description |
|-------|------|-------------|
| `package` | string | Package name as provided in the input |
| `compositeScore` | number | Composite risk score 0-100. Higher = more risk. |
| `verdict` | string | `LOW_RISK` / `ACCEPTABLE` / `REVIEW_NEEDED` / `HIGH_RISK` / `DO_NOT_USE` |
| `busFactor.score` | number | Bus factor risk subscale 0-100 |
| `busFactor.contributors` | number | Maximum contributor count detected across matching repos |
| `busFactor.giniCoefficient` | number | Gini coefficient of commit distribution (0 = equal, 1 = single contributor) |
| `busFactor.busFactorLevel` | string | `HEALTHY` / `ADEQUATE` / `CONCENTRATED` / `FRAGILE` / `SINGLE_POINT` |
| `busFactor.signals` | string[] | Plain-language bus factor risk signals |
| `vulnExposure.score` | number | Vulnerability exposure subscale 0-100 |
| `vulnExposure.criticalCVEs` | number | Count of CRITICAL severity CVEs from NVD |
| `vulnExposure.highCVEs` | number | Count of HIGH severity CVEs from NVD |
| `vulnExposure.kevCount` | number | Count of CISA KEV entries for this package |
| `vulnExposure.vulnLevel` | string | `CLEAN` / `LOW` / `MODERATE` / `HIGH` / `CRITICAL` |
| `vulnExposure.signals` | string[] | Plain-language vulnerability signals |
| `communityHealth.score` | number | Community health subscale 0-100. Higher = healthier. |
| `communityHealth.stars` | number | Total GitHub stars across matching repositories |
| `communityHealth.discussions` | number | StackExchange question count for this package |
| `communityHealth.newsmentions` | number | Hacker News story count mentioning this package |
| `communityHealth.healthLevel` | string | `DEAD` / `DECLINING` / `STABLE` / `GROWING` / `THRIVING` |
| `communityHealth.signals` | string[] | Plain-language community health signals |
| `sbomCompliance.score` | number | SBOM compliance readiness 0-100. Higher = more compliant. |
| `sbomCompliance.regulatorySignals` | number | Count of relevant federal regulations + congressional bills |
| `sbomCompliance.licenseRisk` | number | License risk accumulator (higher = more copyleft exposure) |
| `sbomCompliance.complianceLevel` | string | `NON_COMPLIANT` / `GAPS` / `PARTIAL` / `MOSTLY_COMPLIANT` / `FULLY_COMPLIANT` |
| `sbomCompliance.signals` | string[] | Plain-language compliance signals |
| `allSignals` | string[] | All signals from all four subscores combined |
| `recommendations` | string[] | Prioritized remediation recommendations |

## Composite risk score methodology

| Score Range | Verdict | Interpretation |
|-------------|---------|---------------|
| 0-14 | `LOW_RISK` | Well-maintained, clean vulnerability history, strong community |
| 15-34 | `ACCEPTABLE` | Minor concerns; monitor but safe to use |
| 35-54 | `REVIEW_NEEDED` | Moderate bus factor or CVE exposure; team review recommended |
| 55-74 | `HIGH_RISK` | Critical CVEs, single maintainer, or declining community; plan remediation |
| 75-100 | `DO_NOT_USE` | Actively exploited vulnerabilities or abandoned project |

The composite formula weights vulnerability exposure most heavily (35%) because active exploitation represents the most immediate risk. Bus factor (25%) is next because an abandoned project cannot patch future vulnerabilities. Community health and SBOM compliance each contribute 20% as leading indicators of long-term viability.

**Hard override:** any package with both a CISA KEV entry and a `SINGLE_POINT` bus factor is assigned `DO_NOT_USE` regardless of the numeric composite score.

## How much does it cost to assess OSS supply chain risk?

This MCP server uses **pay-per-event pricing** — every tool call costs **$0.045**. Platform compute costs are included. You are not charged for failed calls that hit the spending limit.

| Scenario | Tool calls | Cost per call | Total cost |
|----------|-----------|---------------|------------|
| Quick test — single package | 1 | $0.045 | $0.045 |
| New project setup — 10 key dependencies | 10 | $0.045 | $0.45 |
| Sprint audit — 50 dependencies | 50 | $0.045 | $2.25 |
| Quarterly audit — 200 packages | 200 | $0.045 | $9.00 |
| Enterprise license audit — 1,000 packages | 1,000 | $0.045 | $45.00 |

You can set a **maximum spending limit** per run to control costs. The server enforces this limit per call and returns a structured error when the budget is reached.

Snyk's developer plan starts at $98/month for CVE and license data — with no maintainer health, community viability, or SBOM regulatory context. Most engineering teams spend $2-10/month with this server for targeted assessments, with no subscription commitment.

## How to connect this OSS supply chain MCP server

### Claude Desktop

Add to your `claude_desktop_config.json`:```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

Add the MCP server URL in your IDE's MCP configuration panel:```
https://open-source-software-supply-chain-mcp.apify.actor/mcp

Include `Authorization: Bearer YOUR_APIFY_TOKEN` as a request header.

### Python```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```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```bash
# 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
  }'

How Open Source Software Supply Chain MCP Server works

Phase 1: Parallel data collection across 7 sources

When a tool call arrives, the server dispatches up to 7 Apify actors simultaneously using Promise.all with a 512 MB memory allocation and 120-second timeout per source. The 7 actors are:

• github-repo-search — public repository metadata: star counts, fork counts, contributor numbers, last-pushed timestamps, open issue counts, license SPDX identifiers, and CI/Actions presence flags
• nvd-cve-vulnerability-search — National Vulnerability Database CVE entries with CVSS v3 severity (CRITICAL, HIGH, MEDIUM, LOW), published dates, and affected product version ranges
• cisa-kev-search — CISA Known Exploited Vulnerabilities catalog entries with the knownRansomwareCampaignUse field indicating confirmed ransomware association
• stackexchange-search — Stack Overflow and related Q&A: question count, is_answered flags, and answer counts as community support proxies
• hacker-news-search — HN story counts and aggregate point totals as a proxy for tech-community security incident awareness
• federal-register-search — Federal Register entries matching sbom, software bill, or supply chain keywords in title and abstract fields
• congress-bill-search — Congressional bills matching software, cyber, or supply chain in bill titles

Tools that require fewer sources dispatch only the relevant subset. maintainer_bus_factor uses 2 actors; vulnerability_exposure_timeline uses 2; sbom_regulatory_tracker uses 2. This reduces both latency and cost for focused queries.

Phase 2: Four-dimensional scoring

The scoring.ts module applies four independent models to the aggregated data:

Bus Factor model (0-100 risk scale): Contributor count maps to a base risk score: single maintainer = 40 pts, 2-3 contributors = 25 pts, 4-5 = 15 pts, 6-10 = 8 pts. A Gini coefficient is then calculated from the contributor count distribution across matching repositories using the formula sumDiff / (n * totalSum) where contributions are sorted ascending and index-weighted. The Gini score contributes up to 20 additional points. Activity recency adds 0-20 points based on days since last push: 0 pts if active within 90 days, 8 pts at 90-180 days, 15 pts at 180-365 days, 20 pts beyond one year stale.

Vulnerability Exposure model (0-100 risk scale): CVE severity maps to points — CRITICAL × 10, HIGH × 5, MEDIUM × 2 — capped at 40. CISA KEV entries score 8 points each plus 5 per confirmed ransomware campaign, capped at 35. CVEs published more than 90 days ago score 3 points each, capped at 15. A compound bonus of 10 points applies when both critical CVEs and KEV entries are present simultaneously.

Community Health model (0-100 positive scale): GitHub stars map to a 35-point scale (10,000+ = 35, 1,000+ = 25, 100+ = 15, 10+ = 8). StackExchange question count and answered-question ratios contribute up to 25 points. Hacker News story count and aggregate point totals contribute up to 25 points. Cross-signal ecosystem vibrancy (both GitHub and StackExchange active simultaneously) adds up to 15 points.

SBOM Compliance model (0-100 positive scale): Copyleft licenses (GPL, AGPL, LGPL, SSPL) add 3 to a risk accumulator; missing licenses add 5. The license score inverts this accumulator up to 30 points. Federal Register SBOM-keyword matches contribute up to 25 points; congressional bill matches contribute up to 25 points; CI/permissive-license readiness indicators (GitHub Actions presence + MIT/Apache/BSD license) add up to 20 points.

Phase 3: Composite score and verdict assignment

The composite formula weights the four subscores:compositeScore = busFactor.score × 0.25 + vulnExposure.score × 0.35 + (100 − communityHealth.score) × 0.20 + (100 − sbomCompliance.score) × 0.20

Community health and SBOM compliance are inverted so that healthier, more compliant packages reduce overall risk. The composite score maps to a verdict tier at 15, 35, 55, and 75 thresholds. The hard override then applies: if kevCount > 0 AND busFactorLevel === 'SINGLE_POINT', the verdict is forced to DO_NOT_USE regardless of the numeric score.

Phase 4: Signal aggregation and recommendation generation

Signals from all four models are concatenated into a flat allSignals array for easy consumption. Recommendations are generated from conditional checks: critical CVEs trigger an immediate-patch recommendation, CISA KEV entries trigger an urgent-action recommendation, dead community health triggers a migration recommendation, high bus factor triggers a fork-or-replace recommendation, and copyleft license risk triggers a legal review recommendation.

Tips for best results

1. Use full ecosystem-qualified names for CVE matching. Searching "struts" returns fewer relevant CVEs than "apache struts". For Maven artifacts, include the group ID where known.
2. Run dependency_risk_assessment first, then drill with focused tools. The full assessment returns all four subscores. If vulnExposure.score dominates, follow up with vulnerability_exposure_timeline for the complete CVE list.
3. Cross-reference compare_package_risks before adopting new dependencies. Calling it with your current package and its leading alternative surfaces relative risk profiles in one round trip.
4. Schedule security_incident_monitor for production critical-path dependencies. Apify scheduling supports daily runs. Pair with a webhook to Slack or PagerDuty when vulnLevel escalates to CRITICAL.
5. Interpret community health alongside bus factor, not separately. A THRIVING community with a SINGLE_POINT bus factor is still fragile — the community may be active users, not contributors. Check both subscores before concluding a package is safe.
6. Use sbom_regulatory_tracker before enterprise procurement cycles. The regulatory landscape is changing rapidly; a quarterly run before procurement review boards surfaces new federal mandates before they become compliance gaps.
7. Combine with static analysis tools for defense in depth. This server covers behavioral and community signals that static scanners miss. For code-level dependency analysis, pair with Syft or OWASP Dependency-Check and bring the composite risk score into your existing workflow via the API.

Combine with other Apify actors

…（正文过长，页面只展示前面部分，完整内容见仓库）