OSS Dependency Risk Report

OSS dependency risk analysis for any npm, PyPI, Cargo, Go, Maven, NuGet, or RubyGems package — scored across four dimensions and delivered as a single actionable report. Built for engineering teams that need to evaluate open-source packages before adoption, audit existing dependencies for supply chain exposure, and demonstrate SBOM compliance readiness to auditors and regulators.

The actor queries 7 authoritative data sources in parallel — GitHub, the NVD CVE database, the CISA Known Exploited Vulnerabilities catalog, StackExchange, Hacker News, the Federal Register, and U.S. Congress legislation — then applies four scoring models (Bus Factor, Vulnerability Exposure, Community Health, SBOM Compliance) to produce a composite Dependency Risk Score from 0-100, a five-tier verdict, and prioritized remediation recommendations. No manual research, no spreadsheets, no subscriptions.

What data can you extract?

Why use OSS Dependency Risk Report?

Manually assessing a dependency's risk means checking CVE databases, GitHub contributor history, license files, StackOverflow activity, and government regulatory feeds — a process that takes 2-4 hours per package and requires access to multiple platforms. Security and engineering teams making adoption decisions often skip this entirely, leaving supply chain vulnerabilities undetected until exploitation.

This actor automates the entire dependency due-diligence workflow. One run, one structured report, decisions in minutes rather than days.

• Scheduling — run weekly scans of your critical dependencies to catch new CVEs and maintainer abandonment before they become incidents
• API access — trigger risk assessments from CI/CD pipelines in Python, JavaScript, or any HTTP client to gate deployments on dependency health scores
• Proxy rotation — built-in proxy infrastructure handles rate limiting across all 7 external data sources without IP blocks
• Monitoring — configure Slack or email alerts when runs identify new high-risk signals on packages already in production
• Integrations — connect results to Zapier, Make, Google Sheets, HubSpot, or custom webhooks for automated risk ticketing workflows

Features

• 4-model composite scoring — Bus Factor (25% weight), Vulnerability Exposure (35% weight), Community Health (20% weight, inverted), and SBOM Compliance (20% weight, inverted) combine into a single 0-100 risk score
• Gini coefficient for commit concentration — measures how unequally commits are distributed among maintainers; a Gini of 0.90+ with fewer than 3 contributors triggers concentrated maintainer risk warnings
• CISA KEV cross-reference — checks every CVE against the CISA Known Exploited Vulnerabilities catalog, which lists vulnerabilities confirmed to be actively exploited in production environments
• Ransomware campaign detection — flags CVEs marked with knownRansomwareCampaignUse: "Known" in the KEV catalog for immediate escalation
• DO_NOT_USE override rule — automatically assigns the harshest verdict when CISA KEV vulnerabilities coexist with a single-maintainer (SINGLE_POINT) bus factor, regardless of composite score
• 5-tier verdict system — LOW_RISK, ACCEPTABLE, REVIEW_NEEDED, HIGH_RISK, or DO_NOT_USE, with thresholds at scores 15, 35, 55, and 75
• CVE severity distribution — weights CRITICAL at 10 points, HIGH at 5, MEDIUM at 2; flags CVEs older than 90 days without a patch as evidence of slow remediation
• License risk classification — detects copyleft licenses (GPL, AGPL, LGPL, SSPL) that impose source-disclosure obligations and flags missing licenses as legal ambiguity
• SBOM regulatory tracking — monitors Federal Register publications for SBOM, software supply chain, and related terms; tracks U.S. Congress bills on cybersecurity and software supply chain
• Community health across 3 platforms — aggregates GitHub stars (tiered: 10K+ = maximum score), StackExchange Q&A volume and answer rates, and Hacker News story points
• 7 parallel data source queries — GitHub Repo Search, NVD CVE, CISA KEV, StackExchange, Hacker News, Federal Register, Congress Bill Search all run simultaneously to minimize total run time
• Multi-ecosystem support — npm, PyPI, Cargo, Go Modules, Maven, NuGet, RubyGems, with auto-detect when no ecosystem is specified
• Activity recency penalty — applies up to 20 risk points for projects with no repository activity in the past 180 days, detecting silently abandoned packages

Use cases for OSS dependency risk analysis

Pre-adoption dependency vetting

Engineering managers evaluating new open-source packages before merging a pull request need fast, structured risk signals. This actor delivers a complete picture — vulnerability exposure, maintainer concentration, community vitality, and license obligations — in a single run. It replaces ad-hoc Googling and undocumented tribal knowledge with a consistent, repeatable scoring process.

Security team CVE triage

Security teams need to prioritize which dependency vulnerabilities to patch first. This actor cross-references NVD CVE data with the CISA KEV catalog to surface actively exploited vulnerabilities, flags ransomware campaign usage, and identifies CVEs older than 90 days that still lack patches — giving analysts a clear remediation priority order rather than a flat CVE list.

SBOM compliance and software supply chain audits

Compliance officers preparing for audits under NIST SP 800-161, Executive Order 14028, or emerging federal SBOM mandates need to document dependency risk and license obligations. This actor tracks Federal Register SBOM regulations and Congressional legislation to contextualize each dependency within the current regulatory landscape and flags copyleft license exposure that could create legal obligations for downstream users.

CI/CD pipeline dependency gates

DevOps and platform engineering teams can call this actor via the Apify API from within deployment pipelines to gate releases when a dependency risk score exceeds a defined threshold. A HIGH_RISK or DO_NOT_USE verdict can block a deployment and open a risk ticket automatically via webhook.

Architecture review and build-vs-buy decisions

CTOs and principal engineers evaluating whether to adopt a dependency, build an internal replacement, or fork an existing project need long-term maintenance signals. The bus factor score, Gini coefficient, and community health level directly address the question: "What happens to our system if this package stops being maintained?"

Third-party vendor and contractor software audits

Risk and procurement teams reviewing software supplied by third-party vendors need to assess the OSS components embedded in that software. Running each declared dependency through this actor produces a structured risk register suitable for inclusion in vendor assessment documentation.

How to analyze open-source dependency risk

1. Enter the package name — Type the package identifier in the "Package Name" field. Use lodash for npm packages, requests for PyPI, facebook/react for GitHub repositories, or openssl for multi-ecosystem packages.
2. Select the ecosystem — Choose "npm (JavaScript)", "PyPI (Python)", "Cargo (Rust)", or another ecosystem from the dropdown for more targeted results, or leave it on "Auto-detect" if you're unsure.
3. Run the actor — Click "Start" and wait approximately 2-4 minutes while the actor queries all 7 data sources in parallel and applies the scoring models.
4. Download your risk report — Open the Dataset tab and export the structured JSON, CSV, or Excel report. The verdict field, compositeScore, and recommendations array give you immediate decision-making signals.

Input parameters

Input examples

Standard npm package analysis:

{
  "package": "axios",
  "ecosystem": "npm",
  "includeTransitive": true
}

Python security-critical package:

{
  "package": "cryptography",
  "ecosystem": "pypi",
  "includeTransitive": true
}

GitHub repository by owner/repo:

{
  "package": "curl/curl",
  "ecosystem": "",
  "includeTransitive": false
}

Input tips

• Use the ecosystem field for common names — packages like log4j exist across multiple ecosystems; specifying maven eliminates noise from unrelated results
• Owner/repo format for GitHub — for repositories, use facebook/react or nodejs/node format; the actor searches GitHub directly with this identifier
• Leave transitive enabled for audits — transitive dependency analysis surfaces indirect risk from packages your direct dependencies rely on, which is where many supply chain attacks originate
• Start with auto-detect — for well-known packages, leaving ecosystem blank still produces accurate results as GitHub and CVE databases use consistent naming

Output example

{
  "package": "log4j-core",
  "compositeScore": 71,
  "verdict": "HIGH_RISK",
  "busFactor": {
    "score": 28,
    "contributors": 5,
    "giniCoefficient": 0.74,
    "busFactorLevel": "CONCENTRATED",
    "signals": [
      "Only 5 contributors — maintainer concentration risk"
    ]
  },
  "vulnExposure": {
    "score": 88,
    "criticalCVEs": 3,
    "highCVEs": 4,
    "kevCount": 2,
    "vulnLevel": "CRITICAL",
    "signals": [
      "3 CRITICAL CVEs — immediate remediation required",
      "4 HIGH severity CVEs — significant exposure",
      "2 CISA KEV entries — actively exploited vulnerabilities",
      "1 used in ransomware campaigns — urgent patching needed",
      "5 CVEs older than 90 days without patch — slow remediation"
    ]
  },
  "communityHealth": {
    "score": 61,
    "stars": 3200,
    "discussions": 18,
    "newsmentions": 7,
    "healthLevel": "GROWING",
    "signals": [
      "18 StackExchange discussions — active Q&A community",
      "7 Hacker News mentions — tech community visibility"
    ]
  },
  "sbomCompliance": {
    "score": 52,
    "regulatorySignals": 3,
    "licenseRisk": 0,
    "complianceLevel": "PARTIAL",
    "signals": [
      "3 SBOM-related federal regulations — compliance landscape active"
    ]
  },
  "allSignals": [
    "Only 5 contributors — maintainer concentration risk",
    "3 CRITICAL CVEs — immediate remediation required",
    "2 CISA KEV entries — actively exploited vulnerabilities",
    "1 used in ransomware campaigns — urgent patching needed",
    "18 StackExchange discussions — active Q&A community",
    "3 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"
  ],
  "metadata": {
    "ecosystem": "maven",
    "includeTransitive": true,
    "analyzedAt": "2026-03-20T09:14:22.000Z",
    "dataSources": {
      "githubRepos": 8,
      "nvdCVEs": 14,
      "cisaKEVs": 2,
      "stackExchangeQuestions": 18,
      "hackerNewsMentions": 7,
      "federalRegulations": 5,
      "congressBills": 3
    },
    "scoringModels": [
      "Bus Factor Analysis (Gini coefficient, contributor concentration)",
      "Vulnerability Exposure Timeline (CVE severity, CISA KEV, patch latency)",
      "Community Health Score (GitHub activity, StackExchange, Hacker News)",
      "SBOM Compliance Assessment (license risk, regulatory landscape)"
    ]
  },
  "rawData": {
    "topRepos": [],
    "recentCVEs": [],
    "kevEntries": [],
    "stackExchangeTopics": [],
    "hackerNewsStories": []
  }
}

Output fields

How much does it cost to analyze OSS dependency risk?

OSS Dependency Risk Report uses pay-per-run pricing — you pay for Apify platform compute time per analysis. Each run calls 7 sub-actors in parallel and takes approximately 2-4 minutes, consuming roughly $0.20–$0.50 per run depending on the package's data footprint. No subscription required.

You can set a maximum spending limit per run to control costs. The actor stops when your budget is reached.

Apify's free tier includes $5 of monthly credits — enough for 10-20 dependency risk assessments with no payment required. Compare this to Snyk's Team plan at $98/month or Sonatype Nexus IQ at $500+/month — OSS Dependency Risk Report covers most teams' ad-hoc analysis needs for under $10/month with no subscription commitment.

Analyze OSS dependency risk using the API

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

run = client.actor("ryanclinton/oss-dependency-risk-report").call(run_input={
    "package": "axios",
    "ecosystem": "npm",
    "includeTransitive": True
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"Package: {item['package']}")
    print(f"Risk Score: {item['compositeScore']}/100")
    print(f"Verdict: {item['verdict']}")
    print(f"Critical CVEs: {item['vulnExposure']['criticalCVEs']}")
    print(f"CISA KEV count: {item['vulnExposure']['kevCount']}")
    for rec in item.get("recommendations", []):
        print(f"  -> {rec}")

JavaScript

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: "YOUR_API_TOKEN" });

const run = await client.actor("ryanclinton/oss-dependency-risk-report").call({
    package: "axios",
    ecosystem: "npm",
    includeTransitive: true
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const item of items) {
    console.log(`Package: ${item.package}`);
    console.log(`Risk Score: ${item.compositeScore}/100 — ${item.verdict}`);
    console.log(`Bus Factor: ${item.busFactor.busFactorLevel} (contributors: ${item.busFactor.contributors})`);
    console.log(`Vuln Level: ${item.vulnExposure.vulnLevel} (KEV: ${item.vulnExposure.kevCount})`);
    item.recommendations.forEach(r => console.log(`  Recommendation: ${r}`));
}

cURL

# Start the actor run
curl -X POST "https://api.apify.com/v2/acts/ryanclinton~oss-dependency-risk-report/runs?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"package": "axios", "ecosystem": "npm", "includeTransitive": true}'

# Fetch results (replace DATASET_ID from the run response)
curl "https://api.apify.com/v2/datasets/DATASET_ID/items?token=YOUR_API_TOKEN&format=json"

How OSS Dependency Risk Report works

Phase 1: Parallel data collection across 7 sources

The actor dispatches 7 sub-actor calls simultaneously using Promise.all(), eliminating serial latency. Each call targets a different data domain: GitHub Repo Search pulls repository metadata including star counts, fork counts, contributor counts, and last push timestamps; NVD CVE Vulnerability Search retrieves Common Vulnerabilities and Exposures records filtered to the package name with full CVSS severity scores; CISA KEV Search checks the official U.S. CISA Known Exploited Vulnerabilities catalog for confirmed active exploitation; StackExchange Search retrieves Q&A threads to measure developer community engagement and support availability; Hacker News Search fetches story mentions and point totals for tech community visibility; Federal Register Search queries SBOM and software supply chain regulatory publications; Congress Bill Search retrieves cybersecurity and supply chain legislation for compliance context.

Phase 2: Four independent scoring models

Bus Factor model (weight: 25%) applies a tiered contributor penalty (single maintainer: 40 points, 2-3 contributors: 25 points, 4-5: 15 points, 6-10: 8 points) and calculates an approximation of the Gini coefficient from the distribution of contributor counts across repositories. Gini values are mapped 0-1 and scaled to a maximum of 20 risk points. An activity recency penalty of up to 20 points applies when last push timestamp exceeds 180 days.

Vulnerability Exposure model (weight: 35%) scores CVE severity distribution at CRITICAL×10, HIGH×5, MEDIUM×2 (max 40 points), adds 8 points per CISA KEV entry plus 5 points per entry linked to ransomware campaigns (max 35 points), scores unfixed CVEs older than 90 days at 3 points each (max 15), and applies a 10-point compound penalty when CRITICAL CVEs and KEV entries coexist.

Community Health model (weight: 20%, inverted in composite) produces a positive health score. GitHub stars map to tiers: 10K+ stars = 35 points, 1K+ = 25, 100+ = 15, 10+ = 8. StackExchange Q&A volume scores at 2 points per question plus 3 per answered question (max 25). Hacker News stories score at 3 points each plus a 10-point bonus for stories with 100+ aggregate points (max 25). This score is subtracted from 100 before weighting.

SBOM Compliance model (weight: 20%, inverted in composite) scores license risk by penalizing copyleft licenses (GPL, AGPL, LGPL, SSPL) and missing licenses, adds points for Federal Register SBOM regulation mentions and Congressional cybersecurity bills, and awards SBOM readiness points for CI/CD workflow presence and permissive licensing. Higher compliance scores reduce the composite risk score.

Phase 3: Composite scoring and verdict assignment

The composite score is (busFactorScore × 0.25) + (vulnScore × 0.35) + ((100 − communityScore) × 0.20) + ((100 − sbomScore) × 0.20). Verdicts map as: 0-14 = LOW_RISK, 15-34 = ACCEPTABLE, 35-54 = REVIEW_NEEDED, 55-74 = HIGH_RISK, 75+ = DO_NOT_USE. A hard override sets DO_NOT_USE when kevCount > 0 and busFactorLevel === 'SINGLE_POINT' regardless of the numeric composite score. Recommendations are generated from threshold checks on each sub-score and the composite verdict.

Tips for best results

1. Specify the ecosystem for ambiguous package names — log4j exists in Maven, npm stubs, and other registries. Without an ecosystem, the GitHub search may return unrelated repositories and skew all four scoring models.

2. Use owner/repo format for forks and mirrors — if you're evaluating a fork of an upstream project, pass owner/repo directly. The actor will query GitHub with that exact identifier rather than a keyword search that might surface the original.

3. Run scheduled weekly scans for critical production dependencies — CVEs are published continuously. A package that scores ACCEPTABLE today may have a CISA KEV entry next week. Apify's built-in scheduling lets you re-run assessments on a cron and alert on verdict changes.

4. Gate deployments on the verdict field — in CI/CD integrations, parse verdict from the dataset output and fail the build if it equals HIGH_RISK or DO_NOT_USE. The compositeScore field is suitable for numeric threshold comparisons.

5. Cross-reference rawData.recentCVEs for patch version guidance — the raw CVE array includes published dates and affected version ranges. After identifying a risky package, query rawData.recentCVEs to identify the specific version that remediated each vulnerability.

6. Combine with Website Tech Stack Detector for supply chain mapping — use Website Tech Stack Detector to discover which packages a target website uses, then feed those package names into this actor to build a complete supply chain risk register.

7. Batch multiple packages in separate runs on the same schedule — the Apify platform supports concurrent runs. Analyzing 50 packages means 50 parallel runs, not a 50× wait time. Use the API with Promise.all() or Zapier multi-step workflows to batch assessments.

Combine with other Apify actors

Limitations

• Data freshness depends on upstream sources — NVD CVE records can lag 24-72 hours behind disclosure. CISA KEV entries are typically current, but GitHub activity data reflects the last-indexed state of the repository.
• Contributor count heuristics — GitHub's API does not directly expose full contributor counts in all contexts. The actor uses available repository metadata fields (contributors_count, contributors) and takes the maximum across repositories, which may undercount in some cases.
• No package manifest parsing — the actor does not parse package.json, requirements.txt, Cargo.toml, or other dependency manifest files. You must supply individual package names, not manifest files.
• Transitive dependency analysis is semantic, not graph-traversal — includeTransitive: true broadens the search query context but does not build a full dependency tree. True transitive graph analysis requires a local package manager invocation.
• License detection is best-effort — license identification relies on the license.spdx_id and license.key fields from GitHub repository metadata. Packages that declare licenses only in file headers or non-standard formats may not be detected.
• SBOM compliance scoring reflects regulatory landscape, not per-package SBOM attestation — the SBOM compliance dimension measures whether your dependency exists in a regulatory context that requires SBOM compliance; it does not verify that the package publisher has produced an actual SBOM artifact.
• Community health scores favor established packages — a new package with zero StackExchange questions and low star counts will score poorly on community health even if it is actively maintained by a dedicated team.
• GitHub search noise for common names — packages with common names (e.g., core, utils) may pull unrelated repositories. Use ecosystem + specific package name to reduce noise.

Integrations

• Zapier — trigger a dependency risk assessment when a new package version is added to a tracking spreadsheet, then post the verdict to a Slack channel
• Make — build multi-step workflows that run OSS risk analysis on every dependency listed in a Notion database and write risk scores back to the same table
• Google Sheets — export dependency risk reports directly to a shared spreadsheet for review by non-technical stakeholders and auditors
• Apify API — integrate into CI/CD pipelines using the REST API to gate deployments on dependency verdict thresholds
• Webhooks — receive a POST notification when a run completes with a HIGH_RISK or DO_NOT_USE verdict and route it to a Jira ticketing workflow
• LangChain / LlamaIndex — feed structured OSS risk reports into an LLM reasoning pipeline to generate natural-language security briefings or SBOM compliance summaries

Troubleshooting

• Composite score seems low despite known vulnerabilities — Verify that the package name matches how it appears in NVD CVE records. NVD uses CPE (Common Platform Enumeration) naming that can differ from the npm or PyPI package name. Try the ecosystem field to target results more precisely, or search the package name directly at nvd.nist.gov to confirm NVD naming conventions.

• Bus factor shows HEALTHY for an obviously unmaintained package — If the package has no recent CVE activity and minimal community presence, GitHub may return zero or sparse results, causing scoring models to default to low-risk scores. Check metadata.dataSources.githubRepos in the output — if it is zero or one, the package name may not have matched any GitHub repositories. Try passing the exact GitHub owner/repo format.

• Run taking longer than 4 minutes — The actor calls 7 sub-actors in parallel with a 120-second timeout each. If one or more sub-actors are rate-limited or delayed, the run will wait up to 120 seconds per blocked source. This is normal for first-time runs on packages with large CVE histories. Subsequent runs on the same package are typically faster.

• All sub-scores are zero — This usually means no data was found for the package name. Check metadata.dataSources in the output to see which sources returned data. For packages with very few records, only the SBOM compliance dimension (which uses generic SBOM legislation queries) may return results.

• SBOM compliance level is NON_COMPLIANT for a well-known package — The SBOM compliance score is partially driven by how active the Federal Register and Congress legislative feeds are at the time of the run. It does not reflect whether the specific package has published an SBOM. Treat the SBOM dimension as a regulatory context indicator, not a per-package SBOM attestation check.

Responsible use

• This actor queries only publicly available data from GitHub, NVD, CISA, StackExchange, Hacker News, the Federal Register, and Congress.gov.
• Risk scores and verdicts are heuristic assessments based on available signals. They do not constitute legal, security, or procurement advice.
• CISA KEV and NVD data reflect the vulnerability landscape at the time of the run. Re-run assessments regularly to capture newly published vulnerabilities.
• Comply with the terms of service of all upstream data sources when using results at scale.
• For guidance on responsible use of public data, see Apify's guide.

FAQ

How does OSS dependency risk scoring work at a high level? The actor runs four parallel scoring models — Bus Factor, Vulnerability Exposure, Community Health, and SBOM Compliance — and combines them with weighted averaging into a composite 0-100 risk score. Vulnerability Exposure carries the highest weight (35%) because active CVE exploitation is the most direct threat. Bus Factor (25%) reflects long-term maintainability risk. Community Health (20%) and SBOM Compliance (20%) are inverted before weighting — a healthier community and better compliance reduce the overall risk score.

What is the CISA KEV catalog and why does it matter for OSS dependency risk? The CISA Known Exploited Vulnerabilities catalog is maintained by the U.S. Cybersecurity and Infrastructure Security Agency and lists vulnerabilities that have been confirmed to be actively exploited in real attacks. Unlike NVD CVE records, which include theoretical vulnerabilities, a CISA KEV entry means attackers are already using that vulnerability today. The actor also flags KEV entries linked to ransomware campaigns, which carry the highest urgency for patching.

How is OSS Dependency Risk Report different from Snyk or Dependabot? Snyk and Dependabot analyze your specific project's dependency manifest files and require integration into your repository or CI pipeline. This actor performs on-demand, package-level risk assessment without requiring repository access or code integration — making it useful for vetting packages before adoption, auditing third-party vendor software, or running one-off assessments outside of a development workflow. It also adds dimensions that Snyk and Dependabot lack: bus factor analysis, community health scoring, and SBOM regulatory landscape tracking.

Can I analyze a package that is not on npm or PyPI? Yes. Any package with a GitHub presence can be analyzed by passing the owner/repo identifier. The actor queries GitHub, NVD, CISA KEV, and community sources using the package identifier regardless of ecosystem. For packages hosted only on private registries with no GitHub presence, results will be sparse as the actor relies on publicly searchable sources.

How accurate is the bus factor Gini coefficient? The Gini coefficient in this actor is an approximation calculated from contributor count distributions across GitHub search results rather than the full commit graph. It measures relative concentration of contributions and produces directionally accurate results for identifying single-maintainer and heavily concentrated projects, but it should not be treated as a precise mathematical Gini coefficient. For exact contributor graph analysis, use the GitHub API's contributor endpoint directly with the full commit history.

How many packages can I analyze in a single run? Each run analyzes one package. For batch analysis, use the Apify API to start multiple runs concurrently. The Apify platform handles concurrent run scheduling. At $0.25 per run, analyzing 100 packages costs approximately $25 and takes 2-4 minutes per package if run in parallel.

Can I schedule OSS dependency risk assessments to run automatically? Yes. Apify's built-in scheduler lets you configure runs on any cron schedule — daily, weekly, or on a custom interval. Combine scheduling with webhooks to receive alerts when a package's verdict changes from ACCEPTABLE to HIGH_RISK due to a newly published CVE or CISA KEV entry.

Is it legal to use this data for security and compliance purposes? Yes. The actor accesses only publicly available data from government databases (NVD, CISA, Federal Register, Congress.gov) and public platforms (GitHub, StackExchange, Hacker News). There are no legal restrictions on using publicly published vulnerability and repository data for security assessment purposes. For guidance on the broader legality of public data use, see Apify's web scraping legal guide.

What happens if no CVE records are found for a package? The vulnerability exposure sub-score will be zero (CLEAN), contributing zero risk to the composite score. The overall risk assessment will still reflect bus factor and community health signals. A CLEAN vulnerability score does not guarantee the package is vulnerability-free — it may simply mean no CVEs have been published to the NVD under that package name yet.

Does OSS dependency risk analysis cover license compatibility in detail? The current SBOM Compliance model classifies licenses into copyleft (GPL, AGPL, LGPL, SSPL — higher risk) and permissive (MIT, Apache, BSD, ISC, Unlicense — no penalty) categories. It does not perform multi-license compatibility analysis or check for dual-licensing. For complex license compatibility decisions, use the output as a first-pass flag and consult legal counsel for packages flagged with copyleft obligations.

How long does a typical OSS dependency risk assessment run take? Most runs complete in 2-4 minutes. The actor dispatches all 7 sub-actor calls simultaneously, so total run time is bounded by the slowest sub-actor rather than the sum of all call times. Packages with large NVD CVE histories or high GitHub search result counts may take closer to 4 minutes.

Can I use OSS dependency risk scoring results in an audit report? Yes. The structured JSON output — including sub-scores, signals, recommendations, and data source record counts — is suitable for inclusion in vendor assessments, M&A due diligence reports, and SBOM compliance documentation. The metadata.dataSources field records the evidence base for each scoring dimension. Note that the actor's verdicts are heuristic assessments, not certified security evaluations.

Help us improve

If you encounter issues, you can help us debug faster by enabling run sharing in your Apify account:

1. Go to Account Settings > Privacy
2. Enable Share runs with public Actor creators

This lets us see your run details when something goes wrong, so we can fix issues faster. Your data is only visible to the actor developer, not publicly.

Support

Found a bug or have a feature request? Open an issue in the Issues tab on this actor's page. For custom solutions or enterprise integrations, reach out through the Apify platform.