Use five lifecycle statuses in a dependency inventory: supported, security only, extended, end of life and unknown. They map to what a project actually promises, they sort cleanly in a report, and they stop the word "supported" from hiding the difference between a fix and a courtesy.
Why one flag is not enough
Many inventories carry a yes or no column called "supported". That loses the detail reviewers care about. Look at how real projects describe themselves:
- Angular's release page describes an active phase of 12 months with regular updates, followed by a long-term phase of 12 months where only critical fixes and security patches ship.
- Rails' maintenance page separates bug fixes from security issues, with security fixes continuing after bug fixes stop.
- PHP's page defines active support, security fixes only, and end of life as three separate states.
- Oracle's Java roadmap separates Premier, Extended and Sustaining Support.
Four projects, four vocabularies, one common need: a status you can sort and filter. A small shared set of labels solves that.
The five statuses
| Status | Definition | Typical example |
|---|---|---|
| Supported | The maintainer ships bug and security fixes | Current Angular active release |
| Security only | Only security or critical fixes ship | A PHP branch past active support |
| Extended | Fixes continue under a separate arrangement, often paid or limited | A runtime under a vendor extended plan |
| End of life | The maintainer states no more fixes | A framework version removed from the supported table |
| Unknown | You could not find a stated policy or date | A small library with no policy page |
Add a sixth field alongside them: the end date for the current status, if one is stated.
Rules that keep the labels honest
- Status comes from a source you can cite. Store the page and the check date next to the label.
- Extended needs evidence. Mark a row Extended only if you can show the contract or enrollment. A web page that offers extended support is not coverage.
- Unknown is allowed, and it expires. Give every Unknown a follow-up date. Unknown is a task, not a resting state.
- Never mark End of life as Supported because a fix exists in git. The Rails maintenance page says that for unsupported series, backports may be published to git but no new versions are released. A fix you must build yourself is not the same as a supported release.
- Record the phase and the end date separately. The status says what is true today. The date says when it changes.
Using the statuses to drive work
Sort by status and exposure. End of life on an internet-facing service goes first. Security only with an end date in 90 days is next. Extended gets a review date before the arrangement ends. Unknown gets a research task. For ordering inside a status, see which end-of-life component to fix first.
Each status also suggests a default decision from upgrade, extend, isolate or retire. Supported needs nothing. End of life needs one of the four.
What not to do
Do not invent a status for every nuance. Ten statuses become impossible to apply consistently. Keep five, and put nuance in a free text note. Do not mix status with risk: an End of life library in a build tool that never ships is a different risk from the same library in a production service. Status is a fact, risk is a judgment.
Try it yourself
Click through it at your own pace, or open it full screen. Scan the component list and imagine a status column with these five values on the right.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces the component list, and its policies and gates can express which statuses your team will accept in a build. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is security only the same as end of life?
No. Security only still ships fixes. End of life does not.
When should I use Unknown?
When you cannot find a stated policy. Set a follow-up date so it does not stay Unknown.
Sources
Last reviewed: 19 October 2026.
