Goodhart's Law applies, so you can't have a set-and-forget certification process. It can be a dynamic process. And just perhaps, we should disincentivize trying to launch new technologies when the institutional knowledge is not there yet. I wonder how many of those security compromises come from bad tradeoffs trying to "keep up with the Joneses" instead of addressing technical debt and knowledge gaps?

The problem is that this is an industry of tinkerers. A lot of projects started out and continue to be maintained by people that do it as a side project. How are you going to police that? People seem to build software as a hobby and sometimes that morphs into a library.

If a tinkering structural engineer designed some new type of, say, a joist, would builders just throw it into a new structure because it's new, or would it need a vetting and review process before becoming a structural dependency? Review doesn't need to happen at the creative level, just at the level where new code gets integrated in some non-trivial, safety-critical deployment. That happens informally now, as people submit issues, pull requests, etc. for projects that they're interested in, but sometimes that is not enough and calls for something more rigorous, like the peer review process in science. Things like the npm left-pad incident clearly show that we're favoring expediency and speed far too much over resiliency. Software now in many places is where architecture was before building codes and fire escapes.