I highly doubt that a process to request approvals for new third-party packages will have the desired effects. I've worked for organizations that have tried to introduce similar processes, and they tend to fail. The approval process rarely fits into the speed and cadence of development, leading to problems like teams not being able to execute on their planned work or bypassing the review process entirely and dropping key aspects of third-party package review and selection.
Especially in agile organizations, when the need or possibility for pulling in a third-party package as a solution arises, the team usually doesn't have a lot of time to make a decision. The work is already in progress and they need a rapid decision to begin to move forward to design, build, and integrate solutions.
The first step is to give the team the knowledge needed to select appropriate packages, considering things like license terms and the overall health of the different options. The health of the package may consider any number of factors, but some that I've seen are things like how responsive the developer is to questions/issues in official support channels, how active the user community is (including third-party channels like Stack Overflow or various forums), the number of open issues and/or time to resolve defects, number of open pull requests, age of pull request, number of committers and who the committers are, frequency of commits, frequency of releases, number of times the package is a dependency, number of downloads (per unit of time, in some cases), number of dependencies, and documentation (readme, contributor documents, funding information).
Unfortunately, no one but you can determine what factors are most important. A big factor are the risks associated with the system that you are developing, along with the tolerance for risk for the developing organization as well as the users and customers. Some contexts are very sensitive to risks, while others are very tolerant.
Snyk and Synopsys have tools that track common open source components and make some health information public. Their ratings and criteria may not be totally appropriate for your organization and you may need to add guidance on how to interpret their data or what to do when components are not in their databases, but this may give you a good starting point to make things easier for the teams looking to include open source components.
Giving the developers doing the work the training and the tools needed to compare options and make informed decisions based on guidelines is important. Taking these tactical decisions away from the team will only slow down the development effort and leave the teams unempowered to make the best design decisions.
Once a package is incorporated, there's also ongoing maintenance. The use of software composition analysis tools can scan your software, find dependencies, and monitor those dependencies. You can be alerted to things like new versions, new vulnerabilities, or packages that no longer appear to be maintained. When these alerts come through, the development team can triage them to apply patches (or other mitigations), defer patches for a later time (if the vulnerability is low risk or there are other mitigations already in place), or identify when it may be time to migrate away from one dependency to another solution.
Depending on your threat model, you may also need to consider other ways to mitigate risks. Even with the appropriate reviews, there are cases of developers yanking their packages from the Internet, purposefully injecting malicious code in new versions, or not adhering to standard versioning schemes and breaking dependent systems. Versioning pinning, standing up mirrors for your dependencies, or building your dependencies from source may mitigate further risks. For open source dependencies, you may also be able to scan the source with your internal vulnerability scanners to further mitigate risks of malicious code.