Take each component version in your SBOM, find the release date of that version and of the newest one, and add up the gaps. The total is your libyear figure, a simple measure of how out of date your dependencies are. Use it as a trend, not a grade.
What a libyear is
The libyear idea comes from research on measuring dependency freshness. Its own description is a single number that tells you how up to date your dependencies are. The example given: Rails 5.0.0 from June 2016 is one libyear behind 5.1.2 from June 2017. A system with a one year old dependency and a three year old one is four libyears old.
The appeal is simplicity. You can explain the calculation in 30 seconds, which matters when you want a team or a manager to track it.
Why an SBOM is a good input
The SBOM already lists exact component versions, which is the first half of the calculation. The second half, the release dates and latest version, comes from the registry for each ecosystem. Tools exist for many ecosystems, including npm, Python, Ruby, Go, Rust, Java and .NET, according to the libyear site.
Steps
- Export the SBOM for the service and keep only direct and runtime components to start.
- For each one, look up the release date of your version and the release date of the latest.
- Subtract and sum.
- Record the total with the SBOM date.
- Repeat monthly.
| Month | Total libyears | Largest single contributor |
|---|---|---|
| September | Record it | Name the package |
| October | Record it | Name the package |
The largest contributor column is the useful one. It tells you where one upgrade buys the most freshness.
How to read the number
- A falling trend means upgrades are keeping pace.
- A rising trend means debt is building, even if nothing is vulnerable today.
- A single huge package usually means a missed major version.
The site's author reports keeping client apps below 10 libyears and rescuing projects over 100 behind. Those are one consultancy's rules of thumb, not a standard, so set your own target.
What libyears miss
Freshness is not security. An old library may have no known flaws, and a new one can ship a bad release. Libyears also treat all packages equally, while a parser at your network edge matters more than a logging helper. Use the number to start conversations, then use advisories and exposure to set priority. A package can also be old because it is finished and stable.
For metrics that tie to action, see SBOM drift metrics worth tracking.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how repeated checks show change over time.
Safeguard's SBOM and dependency scanning supply the version inventory for a metric like this. A free scan lists the components in a repository.
Quick check
Is a lower libyear score always better?
Lower means fresher, not safer. Pair it with advisory and exposure data.
Should I include dev dependencies?
Start with runtime ones. Add dev dependencies later if build tooling is a concern.
Sources
Last reviewed: 19 October 2026.
