Say that you detect unmaintained and end of life components, assign each a plan of action, and record the decision. The usual options are upgrade, replace, isolate, fork and maintain, or accept the risk for a stated period with a named owner.
What the framework expects
NIST SP 800-218 task PW.4.4 gives two examples that map directly onto this question. One is to ensure each component is still actively maintained and has not reached end of life. The other is to determine a plan of action for each component that is no longer maintained or will not be available in the near future. A good customer answer mirrors those two sentences with your own process.
How to detect the problem
- Read the maintainer's own statements: archived repositories, deprecation notices and published support schedules.
- Check the release cadence. A long gap with open advisories is a signal, not proof.
- Track runtime and framework versions against the vendor's published support dates.
- Use an automated scorecard or health check as one input. OpenSSF Scorecard, for example, runs automated checks and returns a score out of 10 for each check on an open source project.
No signal is perfect. A quiet project may be finished and stable, and a busy one may be abandoned in spirit.
The five options
| Option | Use when | Main cost |
|---|---|---|
| Upgrade | A supported successor line exists | Test and compatibility work |
| Replace | A maintained alternative is available | Migration effort |
| Isolate | Replacement is slow and exposure is limited | Needs controls you must keep |
| Fork and maintain | The code is vital and small enough | You own the security work |
| Accept with a date | Risk is low and reviewed | Must be revisited |
Whatever you pick, write down who decided and when the decision expires.
Reply template
We track the maintenance status of components in each release. When one becomes unmaintained or reaches end of life, we assign a plan: upgrade, replace, isolate or, rarely, maintain a fork. Accepted risks are time limited and reviewed. We can share the policy section and a redacted example.
If the customer's own product depends on the same component, offer to tell them early. That is the point where trust is built or lost.
Related reading: abandoned open source project risks and deprecation policy for third party components.
Make the decision log useful
Keep a simple log with the component, the date you noticed the status change, the option chosen, the owner and the review date. Customers who ask about end of life often ask to see how you handled a past case, and a log makes that a five minute answer.
Revisit accepted risks on their review dates. If the component has since gained a known exploited vulnerability, the earlier decision no longer stands and the log should say what replaced it.
Quick check
Is a project with no commits for a year automatically end of life?
No. Check open advisories, maintainer statements and whether the code has a stable scope before deciding.
Is forking a safe fallback?
It transfers the security work to you. Do it when the component is small, critical and you have owners for it.
Sources
Last reviewed: 19 October 2026.
