If want an extremely strong mitigating control that you can design into your architecture..... allow internet egress in your production environment only to a list of domains/ips in an allowlist. This or control egress with an explicit proxy.

If vulnerable systems have no path to the internet at large then it's extremely difficult for attackers to know if a system is vulnerable to log4j and even harder to actually use it to exfiltrate data.

Every case is different... but for the log4shell case in particular:

* newer JVM versions protected against the main attack (JNDI), so if you were on any JDK version released in the last couple of years, you wouldn't be vulnerable. * Java serialization filters [1], which are highly recommended to be setup in any Java application, would also have prevented the attacks. * not including large libraries with lots of unused features could have prevented this. In this case, log4j has support for a dozen or so things that should've been opt-in (and I think they are now) but were enabled by default in every installation.

In summary: actually paying attention to possible attacks and ensuring you're defended against them, and reducing the surface area for attacks makes your application much safer.

[1] https://docs.oracle.com/javase/10/core/serialization-filteri...

As an alternative / addition to the other suggestions, maintain an internal artifact store that syncs with upstream stores, but enforce that vulnerable versions aren't present. Block access to the upstream artifact stores so builds have to use the internal one.

Put a dependency check in your builds. Raise build errors when something is bad. Have it build on a regular basis (could be every month)... and then fix things.

https://owasp.org/www-project-dependency-check/

And some examples - https://jeremylong.github.io/DependencyCheck/dependency-chec...

Make sure you have the time to patch/update your applications when security issues are raised.