This may be a bit oversimplified, but a search of metacpan for UUID returns 355 results. If I was maintaining code against a module upstream that seemed unresponsive to security threats, I'd consider a PR to that module and, failing that, a PR to the code using it to retarget against another module.

One thing to remember with any of these systems is not to either stay stuck on old versions past their usefulness nor blindly update to the latest versions without looking. People get into the habit of not updating, which keeps you from getting fixes. Other people get in the habit of updating in automation without reviewing the changes, which allows supply chain attacks. If you're using a CVE-tracking system like Mitre, they'll tend to tell you in which versions a vulnerability was fixed. The module's changelog should mention the CVE and that it was addressed, too.

If you do want to do your own security review of every piece of code you use, more power to you. I wish you the best. Yet most developers are not security experts and many security experts are not software developers. There are certain overlapping skills one needs to do a thorough and reliable security review of code. Checking against a single known vulnerability disclosure is a bit easier, but not everyone is ready to do that. I would suggest most developers trust the disclosure/correction/reported correction cycle of systems like the CVE reporting sites, complete with CVSS. If you can show a known vulnerability and can show it hasn't been addressed, move on to different dependencies if you can.

In some cases it's possible to look at the CVSS breakdown, look at how your code is used, inspect how your code uses the dependency, and determine a way to acceptably mitigate risks in unpatched dependencies. That, again, is neither purely development nor purely security knowledge.

Your core concern appears to be that developing software which faces an unknown public is not easy to do securely. To that, I can only say that you're absolutely correct. It is not a simple process to assemble multiple pieces from multiple internal and external parties, do some integration around them, deploy them to public-facing systems, and have a reasonably secure system. There are ways to make it easier, but not to make it easy. Many of the ways to make it easier do not make it less expensive. Such is life.