3 DevSecOps Practices to Minimize Impact of the Next Log4Shell
Log4Shell was a watershed moment for many organizations. Although security commentators had been warning about the discovery of a vulnerability like it for years, it took much of the IT world by surprise.
A zero-day vulnerability, Log4Shell enables a remote attacker to take control of a device or internet-based application if the device or app runs certain versions of Log4j 2, a popular Java library.
The Log4j 2 library is so ubiquitous that its effects could last for years as threat actors continue to probe for unpatched instances. But moments of crisis also bring opportunities. This one provides a chance to embed application security and vulnerability management deeper and more holistically into the fabric of IT and development practices.
That doesn’t just mean security must “shift left” — testing for security earlier in software development. It requires that teams shift left and shift right — test software already in production for security. Armed with both tactics, developers build more secure applications while operations and security teams ensure software isn’t exposed to any new vulnerabilities in production.
That’s DevSecOps at its best, where development, security and operations teams work together throughout the software development life cycle. To get there, organizations need to combine observability and security in an intelligent, automated manner.
What Log4Shell Taught Us
We all know the Log4Shell story by now. The bug garnered a rare CVSS 10 out of 10 rating on the industry standard Common Vulnerability Scoring System based not just on its ubiquity, but also how relatively easy it is to exploit and leave a wide sweep of systems open to remote code execution attacks. Beyond the vulnerability itself, the global response to the incident speaks volumes about the security and operational challenges organizations face today.
One challenge is the increasing use of third-party open-source code to accelerate software delivery. According to one estimate, global developers last year requested more than 2.2 trillion open source packages from the top four ecosystems: Java, JavaScript, Python and .NET. The same study found that 29% of popular projects contain at least one vulnerability. Finding these vulnerabilities is increasingly challenging as the pace of software development increases, time-to-market pressures surge and application dependencies become more complex.
Another challenge is digital complexity. Research reveals that most organizations run their applications in a multicloud environment, which on average spans five different platforms. The microservices, containers and Kubernetes infrastructure sitting on these clouds create complexity, which many monitoring solutions are ill-equipped to manage. Organizations, therefore, find security teams are overwhelmed by alerts while the real threats sneak in under the radar.
Log4Shell starkly exposed the extent of these challenges. To improve their chances of responding quickly and more effectively to the next major incident, organizations need to be able to rapidly answer three questions:
- Are we affected?
- Which systems are affected?
- Which problems do I need to tackle first?
To gain this kind of insight, they need a more coherent DevSecOps culture. Here are three ways to enhance DevSecOps to increase situational awareness and improve vulnerability response time:
1. Make Security a Shared Responsibility
Security is tough to get right, and it’s made more difficult by market pressures, cloud complexity and the growing prevalence of open source libraries. This has expanded the typical enterprise’s cyberattack surface to many times its size of several years ago. It has also provided more opportunities for potentially critical vulnerabilities to enter the development cycle and then persist into production. Log4Shell is the poster child for that problem. As a result, it’s more important than ever that we pay more than lip service to the concept of security as a shared responsibility within the organization.
“Shared responsibility” is often used to mean greater boardroom buy-in, or in the context of behavioral change among staff, but it’s just as important in IT departments. We need developers to become more skilled in building secure products, but we also need to ensure apps in production continue running securely. Breaking down the silos between developers, operations and security teams will drive true DevSecOps practices. To get there, organizations should unify teams around a centralized platform that gives them visibility and control.
2. Bridge the Runtime Vulnerability Gap
Even organizations with a rigorous and robust security posture that adhere to the latest best practices and industry standards were challenged when Log4Shell appeared. This highlighted a gap in layered security models that needs to be filled: runtime vulnerability management. To do so, organizations need the ability to observe what’s running in production in real time and identify vulnerabilities that can affect customers.
This can be achieved only through the convergence of observability and security so teams have the context needed to understand how their applications map together and what their dependencies are. The intelligence this convergence generates enables teams to prioritize which software they need to patch first based on the potential impact to sensitive data and customer experience. By consolidating observability and security data in a single platform, organizations can create a single source of truth to drive true collaboration between development, operations and security teams.
3. Automate and Integrate to Take the Pressure Off
Today’s development, security and operations teams are stretched to the limit. Complex, highly distributed applications, fast release cycles and an overwhelming volume of common vulnerabilities and exposures (CVEs) make effective manual response almost impossible. Teams can’t patch everything when there are an average of 50 new CVEs logged every single day. They can’t manually test every bit of code before releasing it into production.
That’s why automation must be built into vulnerability management and observability as a key pillar of DevSecOps. Organizations need an approach where they can test the security of code throughout its life cycle, otherwise problems such as Log4Shell will always creep through. By integrating runtime vulnerability management with IT service management solutions, they can help developers and security teams know which tasks to prioritize and which bugs to fix first. Embedding automated security gates into preproduction environments will also ensure that vulnerabilities eliminated in production don’t resurge as developers continue to iterate.
Fortunately, vulnerabilities like Log4Shell haven’t come around often. Nonetheless, the growing use of third-party open source libraries increases the odds of a similar vulnerability emerging in the future. When it strikes, the world will be even more dependent on software, cloud infrastructure will be more complex and, most likely, IT teams will be stretched even thinner.
That’s why it makes sense to act now with an approach that marries observability with vulnerability management. This will help teams automatically address problems before they reach production and prioritize patching production code for anything new that appears thereafter.