On Monday the world learned about “LogJam”, a remote code execution vulnerability in the (then) current version of Log4j, 2.14.1. Since then, Log4j 2.15.0 has been released which mostly solves the bug, but another (although somewhat less serious) security vulnerability was also found and fixed in Log4j 2.16.0.

Java is used everywhere on the Internet, so this is a pretty serious problem. Companies world-wide have been scrambling to upgrade their dependencies. In an ideal world, this is as easy as bumping the dependency version, hitting the “merge” button in your Git web interface, and letting your CI/CD pipeline handle the rest.

But of course many of us are not living in that ideal world.

Whether you use Java or Log4j or not, I want you take a moment and consider:

• Imagine that tomorrow you were to learn of a remote code execution vulnerability in a third-party library you use.
• Imagine the entire world of hackers knows about the security bug, and is actively looking for systems to exploit.
• Imagine that you’re already using the latest version, so the mitigation is literally as simple as pulling in the new, bug-free dependency version and releasing.

How long would it take you to deploy this urgent security fix?

A good answer would be “20 minutes or less.”

If you answered more than an hour or two, you have need to do some serious process improvements.

If your answer is “Normally a few days, but we can rush things in a pinch”, then you really need to take a step back and get your software delivery process under control.

I’ve seen many reasons for long release processes:

• Long, manual testing process
• Regulatory requirements
• Complex coordination required
• The system is complicated to automate
• Many, many more

However, I’ve never met such an obstacle that couldn’t be turned into a speed bump instead of a barrier with the right approach.

What’s preventing you from releasing on demand, in 20 minutes or less, at any moment? Send me an email and let me know.