ProofwrightScenario

Scenario: when an open-source dependency goes dark

A core library's sole maintainer disappears. Manage the CRA risk of unmaintained components without panic.

A core library's sole maintainer disappears. Manage the CRA risk of unmaintained components without panic.

A dependency deep in your product hasn't shipped a release in 14 months. The issue tracker is piling up and its sole maintainer has gone quiet. Under the CRA, an unmaintained component in your product is your problem.

What the SBOM tells you

ComponentVersionLast releaseReachable?
libqux1.4.214 mo agoYes
→ 2 dependentsBoth live

The stewardship decision

You have four honest options — and the CRA expects a deliberate choice, not a drift into "we didn't notice."

OptionWhen it fits
Vendor & monitorLow risk, still functional
Fork & maintainCritical, and you have the skills
ReplaceA maintained equivalent exists
Sponsor the maintainerViable project, needs support

The recorded position

You fork and pin, assign an internal owner, and log the decision with its rationale. If a vulnerability lands in that component tomorrow, you already own the response — and can show you managed the risk on purpose.

The CRA doesn't ban unmaintained dependencies. It expects you to know you have them and to have a plan.

Proofwright surfaces the stale, reachable components before they surface you.

this is Proofwright

It's live.

See the real thing at Proofwright.