DependencyWatch

A real-time dependency health scanner that fuses security, maintenance, adoption, and live web chatter into one clear repair signal for every package.

Comment 1

💡 Inspiration

Every modern app stands on hundreds of open-source dependencies — a typical package.json pulls in 800 to 1,500 transitive packages. And developers have no early-warning system for when one of them goes bad. A package can get a fresh CVE, be quietly abandoned by its maintainer, or even be hijacked in a supply-chain attack — and you find out when your build breaks, or worse, after a breach.

The real problem is that the health signals for each package live in completely different places: CVE feeds, GitHub activity, package registries, and live community chatter. Nobody fuses them into one plain-English verdict. We wanted to build the tool we always wished we had.

🛡️ What it does

DependencyWatch reads your project manifest — or a GitHub repo URL — and produces a live "repair signal" score (0–100) for every dependency, telling you which packages are silently rotting, abandoned, or carrying fresh CVEs before they break your build.

For each dependency it fuses four pillars:

  • 🛡 Security (45%) — known CVEs per version, live from OSV.dev
  • 🧭 Maintenance (30%) — commit cadence, release age, issue load, archival flags from GitHub
  • 📡 Live Chatter (15%) — real-time community & security discussion pulled from the live web via Nimble
  • 📈 Adoption (10%) — versions-behind and deprecation flags from npm / PyPI / crates.io

Each package gets a color-coded score, a recommended action (KEEP · PIN · UPDATE · MIGRATE · FORK), and a full evidence trail — every score links back to a citable source. Results stream in live, worst-first. Critical packages literally sound the alarm. 🚨

It supports six manifest formats (npm, PyPI, Go, Rust, Maven, and SBOM), saves scans as trackable projects with alerts, exports PDF/JSON reports, and ships a CI/CD GitHub Action that fails any pull request introducing a critical dependency.

🏗️ How we built it

  • Frontend & API: Next.js 16 (App Router, Server Actions, SSE streaming), React 19, TypeScript (strict), Tailwind CSS v4.
  • Architecture: Clean Architecture — a pure, fully-tested domain layer (scoring engine + manifest parsers) with zero I/O, an application layer for orchestration, and an infrastructure layer for all external adapters. This made every provider swappable and gracefully degradable.
  • Security-first scoring: a plain weighted average let vulnerable packages "hide" behind good maintenance, so we added a hard ceiling that forces any package with serious CVEs into the red — matching npm audit behavior.
  • Live web intelligence (Nimble): for risky dependencies we query Nimble's Search API to surface real-world chatter — abandonment notices, malware reports — that static APIs can't see, then feed it into the AI fusion step.
  • Data-to-AI pipeline (Tower): a Python Tower app fans out one task per dependency in parallel, scores them with an engine that mirrors the TypeScript one exactly, and writes results to an Apache Iceberg lakehouse so re-scans are instant and history is queryable. A scheduled run keeps cached data fresh.
  • AI fusion: Claude refines each verdict into a plain-English reason, with Groq as an instant fallback and a deterministic engine as the always-on safety net.
  • Domain (name.com Domain Roulette): we picked signal.repair — "the signals that tell you what needs repair."

🧗 Challenges we ran into

  • Rate limits: GitHub's Search API capped us hard, so we rewrote the maintenance pillar to use only core REST endpoints with Link-header pagination (5,000 req/hr).
  • Scoring honesty: getting the security ceiling right took real tuning — axios@0.18.0 with 23 CVEs was initially scoring a soft "MEDIUM"; now it correctly lands at 30/100, AT_RISK.
  • Live web auth: wiring up Nimble's live search and making the whole thing degrade gracefully so a scan never breaks, even if an external provider is down.
  • Score parity: keeping the Python (Tower) and TypeScript scoring engines producing identical results.

🏆 What we learned

How fragmented the open-source supply-chain risk landscape really is, how to design a system where every external dependency degrades gracefully, and how to fuse structured data (CVEs, GitHub) with unstructured live web signals into a single defensible AI verdict.

🚀 What's next

Org-wide dependency-risk dashboards over time, Slack/Discord alert delivery, and auto-PR generation for safe version bumps.

Built for the DeveloperWeek New York 2026 Hackathon — submitting to the **Tower, **Nimble, and **name.com* challenges.*

Built With

Share this project:

Updates