A libyear is a simple measure of dependency freshness: the time between the release you use and the newest release, in years, summed across your dependencies. One libyear means one year behind. It is useful for tracking upgrade debt over time, but it does not measure risk.
The definition
The libyear project describes it as a single number telling you how up to date your dependencies are. Its example: a framework at version 5.0.0 from June 2016 is one libyear behind version 5.1.2 from June 2017. The site argues for simplicity, saying you can explain the calculation in 30 seconds, and lists tools for several ecosystems including NuGet, npm, PyPI, Bundler, Gradle and Maven.
The measure is cheap to compute because it only needs release dates for the version you run and the latest version.
What it tells you
| Signal | Meaning |
|---|---|
| Total libyears rising | Upgrade debt is growing faster than you pay it |
| One dependency with a huge value | A neglected corner, possibly abandoned |
| Many small values | Normal drift, probably fine |
| Falling after a cleanup | The cleanup worked |
The trend matters more than the number. A dashboard line that climbs for six months tells you the upgrade routine has stopped.
What it does not tell you
Age is not vulnerability. A year old library with no known flaws is less urgent than a one month old release that fixes a critical flaw you are exposed to. Two things the libyear cannot see:
- Whether a known vulnerability exists in your version.
- Whether the vulnerable code is reachable from your application.
It can also mislead in the other direction. A dependency that has not released in years may be finished and stable, or abandoned. The date alone cannot say which. Look at maintainer activity and open issues before deciding.
How to use it well
- Compute it per service and per ecosystem, not one global figure.
- Chart it monthly, and write the owner on the chart.
- Set a soft ceiling, for example per service, and discuss any service that exceeds it at planning.
- Break out the top five contributors. Usually a few packages account for most of the number.
- Pair it with vulnerability data. Sort the top contributors by whether they carry known advisories, and fix those first.
- Review the outliers for abandonment and plan replacements.
Avoid turning it into a target for every team. If a team is judged on the number, they will upgrade easy packages to lower it, and leave the hard, risky ones alone.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory lists versions, which is the raw material for any freshness measure.
Quick check
Does a high libyear mean I am vulnerable?
Not necessarily. It measures age, not exposure. Check advisories and reachability separately.
How often should I measure it?
Monthly is enough to see a trend without creating noise.
Safeguard builds a dependency inventory and adds vulnerability and reachability context, which is the part a freshness number leaves out. Start with the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
