OSS Pulse: tracking dependency health before your users notice

Last week I added a dependency to a side project I haven't touched since 2021. Twenty minutes later, OSS Pulse sent me a CVE alert for that package.

That's the Show HN pitch. Here's how it actually works.

The problem

You have an app. It depends on 40 packages, those packages depend on 400 more. One of those 440 packages gets abandoned — the maintainer stops responding to issues, stops merging PRs, stops cutting releases. Or something worse: a critical CVE is disclosed, and the maintainer is gone. The patch never comes.

No fanfare. No notification. GitHub doesn't email you. npm doesn't email you. The package is just slowly going stale on your dependency tree.

Three months later, a transitive dep breaks because Node 22 dropped some API the stale package relied on. Now you have a production 5xx. Now you're debugging a module you didn't know you depended on, maintained by someone who disappeared two years ago.

This is not a hypothetical. Every senior engineer I know has a story like this.

The monitoring gap is real: we watch our servers, our certs, our uptime. We don't watch the packages our code depends on.

The health score

OSS Pulse resolves each package to its GitHub repository (using the npm registry and PyPI metadata) and computes a health score from four signals:

Last commit age. A repo that hasn't had a commit in 18 months is on yellow. 30 months is red. Active projects have recent commits; abandoned projects don't.

Open issues trend. If the open issue count is climbing and no PRs are being merged, that's a sign of a maintainer who's checked out. OSS Pulse tracks the trend — not just the absolute count, but whether it's growing.

Archive status. GitHub lets maintainers archive repos — read-only, no new issues or PRs. An archived dependency is a dependency on borrowed time. This is the clearest signal OSS Pulse has.

CVE count. Known vulnerabilities from the GitHub Security Advisories API, scoped to the version range your project is using.

The score is a weighted sum. Archive status dominates — an archived repo with a recent CVE is about as bad as a dependency can be. A package with 0 CVEs and a commit from last week is about as good.

The CVE scanner

The scanner runs every 4 hours. It queries the GitHub Security Advisories API for each package in your watchlist and compares against the version range you've declared.

The deduplication problem is real: if you have 15 projects watching the same package, and a CVE is disclosed, you don't want 15 emails. You also don't want to re-alert on the same CVE every 4 hours once it's in the database.

OSS Pulse deduplicates on a fingerprint hash: sha256(package_name + "::" + advisory_id + "::" + user_id). Once an alert has been sent for a given fingerprint, it won't fire again — regardless of how many scan cycles pass. If the CVE is patched and a new one is disclosed, the advisory ID changes, the fingerprint changes, and you get a fresh alert.

The email for a CVE alert includes: the package name, the affected version range, the CVSS score, the advisory summary, and a link to upgrade. No dashboard required.

Onboarding: paste a package.json

The dependency importer is the part I'm proudest of. You paste a package.json or requirements.txt directly into the text box. OSS Pulse parses it, resolves each package to its GitHub repo via the npm/PyPI registries, and shows you a candidate list with health scores pre-populated.

You click the checkboxes for the packages you want to watch, click "Start watching," and that's it. Two-click onboarding from any existing project, no YAML config, no CLI tool to install.

The resolver handles some messiness: packages with no GitHub link in their registry metadata fall back to a search heuristic. About 15% of packages hit this path. OSS Pulse shows you an "unresolved" count after import so you know what it missed.

The thing about 2021 projects

The CVE alert I got last week was for a package I added to a project that's been dormant since 2021. I had a requirements.txt with pinned versions and hadn't touched it in years.

Before OSS Pulse, I would have had no idea. The package was still working — the CVE was a server-side injection vulnerability that would only matter if I was running the thing in production with untrusted input. I'm not. But I know about it now. I can upgrade, or I can make an informed decision to leave it pinned with the risk documented.

That's the goal. Not alarm fatigue, not zero-trust security theater. Just: know what you depend on, know when it gets risky, make a decision.

OSS Pulse is at early access now. Free tier watches up to 50 packages.

The 4-hour scan interval isn't arbitrary — it's calibrated against the GitHub API rate limits for non-enterprise accounts. Pro plan gets 1-hour scans.