There was a 3rd vulnerability found in log4j, requiring yet another patch. More eyes lead to more bugs. Surely there are thousands more open source vulnerabilities in under-the-radar-yet-frequently-used libraries maintained by one person in Iowa.
There will always be insecure third-party code. Like reliable delivery protocols can be built on unreliable protocols, so too can secure systems be built on insecure third-party code
TCP/IP is the quintessential reliable protocol built on an unreliable one. I'll admit, we're not there yet. Virtual machines and containers gave us more granular security boundaries. Zero trust limits blast radius inside the firewall.
The log4j exploit requires unrestricted outbound traffic. Again, we're not there yet – few organizations have outbound whitelists for every service, and in many cases, we don't have the right architecture to isolate certain restrict different parts of the same process (e.g. first-party application code should be able to reach out to the internet, but third-party libraries like loggers should not).
Even further up the stack are reactive measures. AWS is alerting users of possible log4shell exploits on their infrastructure, and has an aggregate view of how the vulnerabilities is being exploited.
This model makes the most economic sense to me. Software will increasingly rely on other software, often from unknown and untrusted third parties. Even if these developers are working in good faith, like the log4j developers, there will be bugs. It's hard enough for developers to write secure code themselves.
The way that we run code should reflect the trust we have in it.