DEVOPSdigest

When Billy Joel wrote, "the good old days weren't always good, and tomorrow ain't as bad as it seems," it sometimes feels like he was talking about application security. Spending time with our customers has been illuminating both in how much has changed as they have moved to the cloud, and how much has stayed the same. I think the single most profound struggle and opportunity in application security is the relationship between developers and security.

For the most part, security professionals see developers as unreliable children running with scissors. Conversely, developers see security professionals as antiquated whistleblowers who focus solely on their own job security. Developers, on the one hand, try to ignore or bypass security controls as much as possible. On the other hand, security tries to avoid the actual application while securing it; they will put a Web Application Firewall (WAF) in front of it, some endpoint security or RASP technology below it, and maybe a database firewall behind it.

The good old days definitely aren't all that good in this context. The move to cloud-native spotlights this, both because developers are empowered AND expected to move faster. As well, developers' scissors are getting sharper, with more control over security configuration, and fewer control points between them and production. The sec/dev divide has been a problem for years, but it's pretty much an untenable solution in cloud-native.

This begs the question: how do we make tomorrow better? Let's look at both sides of the equation, starting with security.

Security

First, security needs to understand applications. In a world where applications comprise code, API, and configuration, security can't work blindly without knowing what the code wants to do.

Second, security needs to automate everything. This might not be immediately obvious, but the most valuable aspect of cloud-native development is feature velocity. Developers can deploy new functionality to customers in a matter of hours. The last thing security should be doing is slowing this process down. The only way you can do more security, more frequently, much faster, is if you rely on automation to make the most of your decisions, while you handle the policies and the exceptions.

Third, security needs a combination of guard-rails and paved roads. Security always loves guardrails — such as IAM or endpoint policy enforcement — and in a world where developers own more and move faster, guardrails are ever more important. At the same time, security needs to recognize that guardrails usually get in the way, and developers are primed to surmount obstacles. So guardrails should be your last line of defense, and like in Disneyland, you should pretty much never see them unless you do something stupid. Rather, security should focus on providing developers with paved roads — easy design patterns and tools that make security the path of least resistance.

Developers

Now that we've looked at the security side, what about developers? How does their role change in this new world?

Developers need to recognize that with great power comes great responsibility. Moving at the speed of cloud-native will require them to make time and place for security in their processes.

First, developers and DevOps engineers should encourage security to enable security assurance within the pipeline. Rather than resist security assurance, developers should encourage and embrace processes that will highlight security issues early and in context, where they can be remediated with little cost.

Next, developers should find ways to communicate with security around what their code does and needs. The better security can understand the needs of the application, the more quickly they can empower the developer while still minimizing attack surfaces.

Finally, developers should embrace tools and processes that help them get more for less. Tools that generate least privilege IAM roles, and processes that ensure the use of the latest and greatest patched libraries, for example, can provide a huge boost in security without taxing developers heavily in precious time.

Finding Balance

The key insight I have come to realize is that the balance has shifted — in both directions. Developers have more security responsibility than ever before, and security has the inherent need to understand application code and behavior in ways they might be able to avoid in the past. Achieving equilibrium in the cloud-native world requires both sides to have much more empathy and understanding of the challenges and limitations of the other's world.

At the same time, we need to resist the urge to just make it the other guy's problem. Security needs to own responsibility to ensure the products are deployed and operated securely. Developers need to own the responsibility to have tools, education, and processes in place to meet their security goals.

What gives me cause for optimism is that, more than ever before, we all have a clear shared goal, and if we shed some of our baggage and embrace rather than resist, we might just make things a whole lot better tomorrow.