Azul made a series of predictions for Java and technology in 2023. One of the predictions is “Security will finally catch up to DevOps to prevent vulnerabilities like Log4j.” Azul Senior Director of Product Management Erik Costlow expands on this prediction and explains why security and DevOps will stop resisting each other and become faster, more agile, and more like DevOps.
When Gene Kim wrote The Phoenix Project with Kevin Behr and George Spafford in 2013, he based it on Eli Goldratt’s classic 1984 business novel The Goal. It’s centered around Goldratt’s concept of the Theory of Constraints – a methodology for identifying the most important limiting factor (the bottleneck or constraint) that stands in the way of achieving a goal.
And if you were to ask DevOps professionals to point out the killer constraint in their development and release cycle, many of them probably would have pointed at Security. Organizations are pushing Security onto DevOps teams to catch issues when they are still small and easier to mitigate. To improve throughput (defined by Goldratt as “the rate at which the system generates money through sales”), Security dragged DevOps into some new methodologies you may have heard of, Security By Design and DevSecOps.
Security By Design
Secure By Design means designing software to be foundationally secure rather than bolting security on at the end. As more developers have become responsible for fixing applications when things go wrong, the Security By Design movement has built momentum. Unfortunately, it has a low ceiling because it involves more work to ensure security when developers really want to develop. Everyone in the process considers security and builds it into the system at every layer and starts with a robust architecture design.
The Security By Design development approach has become mainstream, as it dovetails nicely with the shift left development model. Unfortunately, it has a low adoption ceiling because developers want to build things, and security can be a bottleneck. The way to drive Security By Design is not getting more teams to follow the approach, it’s to make “secure by design” the default and place it lower in the stack. Teams who build on top make fewer insecure decisions.
DevSecOps
Where Security by Design is a process that makes security a critical component of design and development, DevSecOps is an extension of the DevOps philosophy that integrates security into the whole software development process. It is a culture and a set of practices that aim to ensure that security is integrated into all stages of the SDLC, from development to deployment and operations. It emphasizes collaboration, automation, and continuous delivery and improvement to secure the entire application lifecycle.
In the past, DevSecOps was discussed more than it was seen. Many teams agree on the need to integrate security, but fewer took the step to integrate actual security controls into their cycles.
Read the CISO's Guide
Are you ready for the next Log4Shell?
The tension between security and DevOps
DevOps was born as a culture and a set of processes to bring new products to customers faster. Since software engineer Patrick Debois coined the term in 2008, DevOps has become the accepted method of developing and releasing code. Combining development and operations enabled teams to release small units quickly rather than producing large releases with long development times. This method made software not only faster to release but also faster to fix if something went wrong.
In the name of speed, it was all too easy for DevOps to run over security. DevOps was moving fast while security was moving cautiously. Part of this derives from DevOps’ need for clear requirements of what to work on within a sprint and security’s need to look forward and backward at what can or did go wrong. DevOps was the party and security was the parents coming home. When DevOps did its job well, people celebrated new products for customers. When security did its job well, nothing happened.
The DevOps movement was always trying to shift left – fix problems earlier in the development pipeline – so there were no nasty surprises at the end. It was a sound philosophy until December 2021, when everything changed for application security.
Then came Log4j
Log4j is one of the most commonly used libraries for Java applications. When the Log4Shell vulnerability was discovered in the library, companies spent thousands of person hours scrambling to find it and patch it. In the past developers might have seen that as a security issue. But this time developers were pulled away from their work to try to find Log4Shell. In spite of an entire industry having worked to “shift left” for years, not a single security tool knew about this issue. It was only by “shifting right” and applying the context of what ran that teams saw a logging framework could actually run code.
Developers, who were measured on their code output, weren’t producing. Security professionals, who were measured on preventing incidents, had just witnessed the mother lode of incidents. In a July 2022 report, the U.S. Department of Homeland Security’s Cyber Safety Review Board issued a report that said one federal government agency had spent 33,000 hours tracking down Log4Shell.
Here’s where the shift left philosophy created a problem – organizations often found Log4Shell and patched it somewhere in the development pipeline only to have it reintroduced and appear again in production. Suddenly DevOps and security had to work together.
I predict that this is the year that security will operate at the speed of DevOps and DevOps will fully embrace security. This will occur by still shifting security left, but also integrating security into the stack that monitors the operations side. In the DevOps lifecycle, feedback flows from right to left as we learn from production. Secure stacks and security tools need to operate on both the left and the right side to guide clear requirements that DevOps teams can follow. While this movement is born of painful experiences, it will produce safer code built faster and easier to fix when things go bad.
Until next time.
