Launching today
EOL Dataset
Find every EOL dependency in your stack. Free. In 5 minutes.
16 followers
Find every EOL dependency in your stack. Free. In 5 minutes.
16 followers
Your SCA checks for CVEs. It doesn't check whether anyone is still maintaining the software. That's a different question, and until now, no tool answered it well. We track lifecycle status across 12M+ package versions using official EOL declarations and ML-based detection of maintainer abandonment. Upload a package.json, pom.xml, requirements.txt, or any SBOM and see exactly what's still maintained and what isn't. Direct and transitive deps. Every major ecosystem. Free of charge.
EOL Dataset
Last year, our engineering team ran 200+ dependency analyses by hand. Same job every time: a customer would come to us and say, "We need to know what's end-of-life in our stack." We'd dig through their dependency tree manually, cross-reference what we could find online, and deliver a report.
Over 200 times we did this. And over 200 times we ran into the same problem.
There is no complete source of lifecycle data for open source software. Not from NVD. Not from your SCA vendor. Not from the registries themselves. The best public source we could find covers about 7,000 package versions. The actual number of EOL package versions in the wild is in the millions.
So we asked the obvious question: if nobody has mapped which open source packages are dead, why don't we do it?
That was 14 months ago. Here's where we are now.
The dataset tracks 12M+ package versions across npm, Maven, PyPI, NuGet, Go, Cargo, and others. Two data sources feed it. First, official EOL declarations from maintainers and foundations. Second, and this is the part that took the most work, ML-based detection of maintainer abandonment. Because most open source doesn't get a formal end-of-life announcement. The commits just stop. The issues pile up. And the package sits on the registry looking perfectly healthy while nobody is home.
We found 81,000+ package versions in exactly that state: known CVEs, zero remediation path, no maintainer coming to fix them. And here's the detail that surprised even us: 93% of that risk sits in transitive dependencies. Packages your team never chose, never reviewed, and probably doesn't know exist.
The scanner is free. Upload a package.json, pom.xml, requirements.txt, go.mod, or any CycloneDX/SPDX SBOM. We resolve the full tree and show you what's dead, what's dying, and what's fine. Takes about five minutes.
No credit card. No agents. No code changes.
Two things I'd genuinely love from this community:
Coverage gaps. If you scan your stack and find a package or ecosystem we're not tracking, tell us. We're actively expanding and your feedback goes straight into the backlog.
Honest reactions. Does this actually save you time? Is the output useful? What's missing? We built this because we needed it ourselves 200+ times last year. I want to know if it solves the problem for you too.