How to Address the Log4j Security Issue with DevOps

The recently discovered vulnerability involving the Apache Log4j logging utility — a security issue that can be exploited to give unauthorized users access to some IT resources — has been a wake-up call for developers. At least, I hope it has been. Incidents such as this can provide valuable lessons and catalyze improvements to software asset management. 

Log4j is pervasive, and it creates a potential target for cyberattacks nearly anywhere it exists. Without a strong asset management program, however, it may not be easy to find and fix all those places. Remediation is complex; it requires scanning codes for libraries that match Log4j naming conventions, hunting down applications, figuring out what steps cloud providers are taking to address the vulnerability in their systems and more.

Organizations that effectively manage their software footprints are in a much better position to address this vulnerability and others like it. With proper governance over development, organizations can reduce their technical debt and mitigate risk at the same time.

Everything that developers use to build applications imposes a certain amount of technical debt. Best practices call for paying down that debt with the necessary patching and code maintenance. The Log4j situation is an example of the havoc that can arise when developers and operations teams get behind on this important work. 

From top to bottom, DevOps teams should track all the components that go into an application. If an organization lacks the resources to properly manage an application, it should carefully consider whether to use that application. By the same token, if an organization’s IT leaders decide to discontinue the use of an existing application, the organization should get rid of that app — not right away, necessarily, but the IT team should at least come up with a plan to sunset it. 

Log4j has given many teams more visibility into the strengths and weaknesses of their software asset management programs. If you’re using Log4j, you should be able to see how many applications are referencing it, so you can determine what was deployed and form a game plan to fix vulnerabilities related to Log4j wherever they exist. If you lack that visibility, you should consider a plan to achieve it.

Another outcome of the Log4j situation, I hope, is that organizations will look more closely at the tools employees need to do their jobs. That’s part of building a healthy development culture. DevOps leaders should ensure that before an employee brings a new code library on board, it has been vetted and approved.

It’s understandable that DevOps professionals want to work with the latest and greatest tools, but this desire needs to be balanced with due diligence. In addition to establishing appropriate processes, organizations may use tools that improve software intake. Repository managers such as Artifactory, for example, can help by making sure everyone pulls from approved releases.

Asset management requires balancing productivity and risk mitigation. Start by making a plan to talk about how you manage your footprint. Don’t overlook scale: Developers won’t want to fill out endless spreadsheets, so make sure your plans are realistic. 

Even if your organization has the Log4j issue under control, you can use this occasion as a prompt to revisit and refine your software asset management strategy. In the end, DevOps-enabled cultures are the ones that will be able to react most quickly to these kinds of weaknesses.

Story by Jeremy Guthrie, a DevOps, Orchestration and Automation Technical Architect and a leader within CDW's Managed Services organization. Jeremy works to balance evolving customers' IT strategies with compliance and business objectives. In his 21 years with the company, Jeremy has worked in network and system administration, application architecture, services creation, operations efficiency and automation.