Building a Legacy Software
Inventory
You can't manage end-of-life exposure you haven't enumerated. A legacy software inventory — every product and version you run, annotated with its support status — is the foundation of any EOL audit, and most teams don't have one because building it by hand means chasing lifecycle pages across dozens of vendor sites. This page is the practical workflow: collect what you run, scan it, batch-check it, and rank what comes back.
The Four-Step Audit Workflow
| Step | What You Do | Tool |
|---|---|---|
| 1. Collect | Gather dependency files from your repos, plus a list of OS, database, and runtime versions from your infrastructure | Your repos and infra notes |
| 2. Scan | Run each dependency file through the free stack scanner for an instant lifecycle report | Stack Scanner |
| 3. Batch-check | Query everything the files don't cover — OS, databases, infra — against lifecycle data for 480+ products | API or EOL Checker |
| 4. Prioritize | Rank every EOL finding by its 0–100 risk score and decide: migrate now, or bridge with extended support | EOL Risk Score |
Step 2 in Practice: Scanning Dependency Files
Your dependency files are already an inventory — they just don't know it. The Stack Scanner accepts a requirements.txt, package.json, Gemfile, or composer.json — uploaded or pasted — and returns a lifecycle report for every recognized dependency: EOL, warning, or active, with dates. It runs in the browser, so there's nothing to install and no signup. For a multi-repo estate, run each service's file through and collect the EOL rows into one sheet — that sheet is the application-layer half of your inventory.
Step 3 in Practice: Batch-Checking via API
Dependency files won't tell you the Ubuntu version on your hosts or the PostgreSQL major version behind your app. For that layer, query the API, which serves EOL dates and risk scores across all 480+ tracked products — operating systems, databases, runtimes, and infrastructure tooling. The free tier allows 500 requests per day, which is comfortably enough to script a nightly or weekly job that re-checks your full inventory and diffs the results. For a handful of one-off lookups, the EOL Checker does the same thing interactively.
Step 4 in Practice: Prioritizing With Risk Scores
An honest audit usually surfaces more EOL findings than any team can fix at once, so ordering is the whole game. The EOL Risk Score ranks each finding on a 0–100 scale using four weighted factors — how long it's been past EOL (40 points max), its attack surface (30), CISA KEV exposure (20), and whether extended support exists as a fallback (10). Work down the list from the top. For items you can't migrate quickly, extended support can cover the gap — the extended-support market overview explains the options, and we can match you with a provider for free. The full decision framework lives in the EOL management guide.
Start the audit now
Scan a dependency file in your browser, or check a single product in seconds.
Frequently Asked Questions
What is a legacy software inventory?
A list of every product and version running in your environment, annotated with its support status: actively supported, approaching end of life, or already past it. It's the foundation of an EOL audit — you can't manage exposure you haven't enumerated.
How do I run an EOL software audit?
Four steps: collect what you're running (dependency files, OS and database versions), scan dependency files with the free Stack Scanner, batch-check everything else against the API (free tier: 500 requests per day, covering 480+ products), then prioritize findings with the 0–100 EOL Risk Score.
Can I audit dependencies without installing anything?
Yes. The Stack Scanner runs in the browser — upload or paste a requirements.txt, package.json, Gemfile, or composer.json and get an instant lifecycle report for every recognized dependency. No agent, no install, no signup.
How often should the inventory be refreshed?
EOL dates are announced and occasionally revised throughout the year, and your own stack changes with every deploy. A practical cadence is a scripted API re-check monthly or quarterly, plus a re-scan whenever dependency files change.