Check your dependencies against today

1. 1Point it at your dependencies. Paste a public GitHub repo link, or drop or paste manifest files. Only the files that name dependencies are read.
2. 2Every version is checked live. Packages go to OSV.dev for known vulnerabilities, with CISA KEV and FIRST EPSS for which ones attackers use. Runtimes, frameworks and base images go to endoflife.date. npm, PyPI and deps.dev answer for deprecations and newer releases.
3. 3You get one list, most urgent first. One finding per package, the version that fixes all of its advisories, the file to change, and a task to paste into Claude Code, Cursor or Codex.

• JavaScript and TypeScript: package.json, with package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock for the installed versions. package.json checker
• Python: requirements.txt and its variants, pyproject.toml (PEP 621 and Poetry), with uv.lock or poetry.lock. requirements.txt checker
• Go: go.mod, including indirect modules and the toolchain line. go.mod checker
• Rust: Cargo.toml, with Cargo.lock. Cargo.toml checker
• Containers: Dockerfile FROM lines, multi-stage builds included, and compose image: lines. Dockerfile checker
• Runtime versions: .nvmrc, .node-version, .python-version, .tool-versions, a package.json engines field that names one Node.js major, and go.mod’s toolchain.

Up to 400 packages per check, direct dependencies first. A repo is read at its root, plus the workspace folders it names.

• Known vulnerabilities from OSV.dev, which collects the GitHub Advisory Database, the PyPI, Go and RustSec databases and malicious-package reports.
• Exploitation: an advisory in CISA’s Known Exploited Vulnerabilities catalog is always critical, and EPSS scores order the rest.
• End of life: runtimes, frameworks and base images past their end-of-life date or within 180 days of it, with the supported line to move to.
• Deprecated packages and releases, and packages two or more major versions behind.
• Licences that restrict how you can use or host the code (SSPL, BUSL, Elastic, FSL; AGPL as low priority), as npm and PyPI list them.
• Base images on latest or with no tag, which change under you on every build.

This sample app pins old versions on purpose. The result below comes from running it through the same live check on the server, with the time it ran and the sources it asked.

{
  "name": "acme-storefront",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "15.0.3",
    "react": "19.0.0",
    "react-dom": "19.0.0",
    "axios": "0.21.1",
    "lodash": "4.17.15",
    "jsonwebtoken": "8.5.1",
    "request": "2.88.2"
  },
  "devDependencies": {
    "typescript": "4.9.5"
  }
}

FROM node:16-alpine
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["npm", "start"]

• It doesn’t read your source code, upload your repo or run your build. It reads manifest files only.
• It reads public repos only, without credentials. For a private repo, drop its files or connect GitHub.
• It doesn’t scan container image layers or operating system packages. For those, use a scanner such as Docker Scout or Trivy on the built image.
• It doesn’t know whether your code calls the vulnerable function. Tools with call-graph analysis, such as govulncheck for Go, can rule some findings out.