Dependency Vulnerability & EOL Checker

Paste (or upload) a dependency manifest — requirements.txt, package.json, package-lock.json, go.mod, Pipfile.lock, composer.lock or Gemfile.lock — and every pinned version is looked up in the open-source vulnerability database OSV.dev. Where the manifest declares a runtime (engines.node, the go directive, python_version, platform.php, RUBY VERSION), its support status is checked against endoflife.date; the second tab checks any product/version by hand. Up to 30 manifest checks per hour per visitor.

🔒 Your manifest is processed in memory only for the duration of the request. It is never stored, logged, or cached — only the package names and versions it contains are sent to OSV.dev, nothing else.

Check a manifest Is my runtime supported?

Limitations — read before trusting the result

Only pinned versions can be checked. A package.json range like ^1.2.3 is checked at its minimum version 1.2.3 and marked ≈ approximate — the version actually installed may be newer and already fixed. Paste the lockfile (package-lock.json, Pipfile.lock, composer.lock, Gemfile.lock) for exact answers.
No transitive resolution. A requirements.txt, package.json or go.mod only lists what you declared; the packages they pull in are not checked unless you provide a lockfile that lists them.
Coverage varies by ecosystem. OSV.dev aggregates GitHub Advisories, PyPA, Go, RustSec, OSS-Fuzz and others; "none known" means nothing is recorded there, not that a package is safe. Severity comes from the advisory's CVSS v3 vector when present, otherwise from the database's own label — many older advisories carry none.
"Fixed in" is the smallest fixed version above yours from the advisory's own range data for this exact package; some advisories list no fix.
EOL dates are the upstream project's public schedule as tracked by endoflife.date (cached here for up to 24 h). Vendor extended support and distro backports are not reflected.

💻 Show API usage examples (cURL)

Check a manifest

curl -sS -X POST https://devops.majbase.com/dependency-checker/api -H "Content-Type: application/json" \
  -d '{"manifest":"requests==2.25.0\nflask==2.0.0","format":"auto"}'

# or straight from a file:
curl -sS -X POST https://devops.majbase.com/dependency-checker/api --data-urlencode "manifest@package-lock.json"

Returns {"format", "summary": {"checked", "vulnerable", "clean", "unchecked", "vulnerabilities", ...}, "packages": [{"name", "version", "ecosystem", "approximate", "status", "vulns": [{"id", "url", "severity", "fixed_in", "summary", "aliases", ...}]}], "unchecked": [{"name", "reason"}], "runtime": {...} | null}, or {"error": "..."}. format is optional (auto, or one of requirements.txt, Pipfile.lock, package.json, package-lock.json, go.mod, composer.lock, Gemfile.lock). Rate limited to 30 checks/hour per source IP; input up to 512 KB / 2000 packages.

Is my runtime supported?

curl -sS "https://devops.majbase.com/dependency-checker/api/runtime?product=python&version=3.9"

Returns {"product", "product_url", "version", "status": "supported" | "ending-soon" | "security-only" | "eol" | "unknown", "eol_date", "days_to_eol", "support_date", "latest", "lts", "message", "cycle", "available_cycles"}, or {"error": "..."}.