By the time you know it matters, it's too late. And if it's not too late, you don't have enough data to know which of the thousands of packages you depend on should be forked and which shouldn't.
You're missing the point of a supply chain risk assessment. Yes, you can fork a project to maintain it yourself. But, for an organization to do this, they need to allocate resources, e.g. time and money. This is part of the risk you are assessing for in a supply chain risk assessment.
The risk quintuples with no lock files. And the number of maintainers is often not as important as the number of other users who are also putting eyes on the code
Just forking the code doesn't get you very far. Few of those products have what we would call reproducible builds so good luck trying to create a working release image if you don't have access to the contractor's infrastructure and tooling.