Skip to content

End-of-Life and Maintainer Activity Check

Maintenance-health diagnostic — instantiates Substrate Lineage Risk Audit

Assesses whether an inherited substrate is still alive — within its support window and actively maintained upstream — so a component everyone assumes is cared-for isn't quietly abandoned.

A dependency can be flawless today and still be dying — its support window closing, its maintainers gone quiet. End-of-Life and Maintainer Activity Check takes a point-in-time reading of a substrate's liveness: is it inside its published support window, and is anyone actually home upstream? It reads two signals nothing in the code reveals — the lifecycle signal (end-of-life dates, supported-version policy) and the maintainer-activity signal (release cadence, recent commits, issue responsiveness, how many hands are on it). Its defining move is that it evaluates human and lifecycle health rather than code contents, catching the one risk no scanner flags because nothing is broken yet: the slow expiry of support.

Example

A fintech service inherited a stack pinned to a language runtime approaching its vendor end-of-support date, and it leans on a niche open-source library for currency rounding. The check pulls the runtime's published end-of-life calendar and inspects the library's repository: last release roughly two years ago, open security issues unanswered, a single maintainer long inactive. It reports two support states — runtime "sunsetting in ≈7 months," library "effectively abandoned." Neither shows up in any test; the code runs fine today. But both are unowned upstream, and that reframes them from "working dependency" to "risk with a clock on it" — the kind of finding that has to arrive well before the clock runs out to be actionable.

How it works

  • Read the support state. For each inherited substrate, pull published end-of-life / end-of-support dates and supported-version policy.
  • Read the maintainer signal. Inspect release cadence, recent commit activity, issue and pull-request responsiveness, and the number of active maintainers.
  • Classify liveness. Mark each substrate supported, nearing end-of-life, or abandoned.
  • Flag the stewardship gap. Where no active maintainer exists upstream, raise it — an unmaintained substrate forces the question of who owns it now.

Tuning parameters

  • Activity window — how far back "recently maintained" looks; short windows over-flag quiet-but-finished projects, long ones miss recent death.
  • Support-source authority — vendor end-of-life calendars versus community heuristics; authoritative dates are crisp, inferred ones fuzzy.
  • Abandonment threshold — how quiet a project must be before it's called abandoned; stricter catches decay early, looser reduces false alarms.
  • Bus-factor sensitivity — whether a single-maintainer project is flagged on that basis alone, regardless of recent activity.
  • Check cadence — a one-shot reading at intake versus a periodic re-check as the clocks advance.

When it helps, and when it misleads

Its strength is catching the risk no vulnerability scanner sees, because nothing has failed: a substrate whose support is quietly expiring or whose upstream has gone dark.

Its weakness is that liveness signals are noisy. A stable, "finished" library can look abandoned, while a busy repository can still be unresponsive on security specifically. And any point-in-time reading goes stale — today's supported runtime is next year's end-of-life.[1] The classic misuses are treating a single recent commit as proof of health, and using a green check to defer a migration indefinitely. The discipline is to distinguish "quiet because finished" from "quiet because abandoned," and to re-run the check as the clock moves rather than trusting one snapshot forever.

How it implements the components

End-of-Life and Maintainer Activity Check fills the freshness-and-stewardship slice of the archetype — the part that reads whether the substrate is still alive and cared-for:

  • substrate_freshness_and_support_state — its core output: a supported / nearing-end-of-life / abandoned reading for each inherited substrate.
  • substrate_stewardship_owner — it reads whether an active upstream steward exists and flags the gap when one doesn't, forcing the question of internal ownership.

It does not continuously watch for new advisories against these substrates — that live subscription is Upstream Advisory Monitor's job — and it does not enumerate the substrates to check in the first place; that inventory comes from Dependency Tree Static Analysis and Software Bill of Materials with Lineage.

Notes

Freshness is a moving property, and this check is a snapshot of it — so it pairs naturally with Upstream Advisory Monitor for the continuous view. A one-time pass at intake silently expires: the substrate that was supported when you adopted it crosses its end-of-life date on a schedule the check has to be re-run to catch.

References

[1] The "bus factor" is the number of key maintainers a project would have to lose before it stalls. A low bus factor — often a single maintainer — is a maintenance-risk signal independent of recent activity, which is why maintainer count, not just last-commit date, belongs in this check. ↩