Shifting Security to the Left
Code and code development processes have changed a lot in the last 10 years. We now have wonders like containers, CI/CD, DevOps, chaos monkeys and companies deploying code in production on an hourly basis. We can spin up services faster than we can blink.
And yet, despite all this agility, we are still stuck with security solutions of yesterday’s world. It’s becoming more and more apparent that the tools we use for ensuring security cannot run at the same speed as DevOps. The reasons are either because the security tools of today require a lot of manual intervention; or because they take too long to finish; or the deployment form factor is not right; or they do not have the right integrations; or they just do not cover the security challenges we face today.
The old world says: first build it and then we’ll figure out how to protect it. But experience has taught us that the best security is the one designed from the ground up.
The challenge of integrating security in DevOps is automation and accuracy. As enterprise software becomes more agile and open source consumption evolves and becomes more complex, there is great potential for human error, sensitive data exposure further leading to compliance violations and misconfiguration. It’s simply out of scope of human ability to manage this evolution error free. Automation of security measurement and enforcement in DevOps process solves these challenges.
The Security Journey of the DevOps Era
It was late last year when my cofounders and I got together and decided to dedicate ourselves to fixing this problem. We bring a mix of Security, Big Data, DevOps and Infrastructure backgrounds and a passion to solve hard problems. Our guiding belief is that for security to be done right for a world where software is the key innovation engine, we have to shift security earlier in the dev-to-deploy cycle.
From the beginning, we wanted to augment our experience in DevOps with understanding the everyday work and challenges of our other DevOps friends. We quickly set up a few interviews. The top three themes we heard were:
- Managing agility and stability
- Alert fatigue
- Robustness of process
Notice that security is not on the list. In fact, none of the people we interviewed mentioned security before we brought it up ourselves. The typical exchange was:
ShiftLeft: Do you manage security too?
DevOps persona: Oh yeah, absolutely. Security is assumed in everything we do.
In other words, security is taken for granted in their day to day work. It is “assumed” to be there. Alas, the number and frequency of breaches tell a different story. DevOps is not to be blamed for this. As the security industry, we have not given our customers the right tools. Think of the code making its way from person to person in an organization. From engineer 1 to engineer 2… from team A to team B… from frontend to backend… from dev to operations… from development to production. In all of these interactions, the weakest link will create the next privacy leak or the next security loophole of your company. But you have no way to see it. There is no visibility. We are flying blind when it comes to security.
To draw an analogy to other DevOpsy things, imagine putting your application in production with no monitoring — and just assuming that everyone coded their piece perfectly and that nothing bad is ever going to happen.
And so we set out on a mission to fix this and came up with a few core principles:
- Minimal human intervention.
- Do not rely on every engineer to be aware of something. Use automated checks to prevent people from doing something wrong.
- Decouple the notions of what the system is (profile) and what the system may or may not do (policy).
- Security at the speed of DevOps. Speed is paramount; if security slows the pace, security will be abandoned.
The Security DNA of Code
The incarnation of the principles above is what we call the Security DNA of code. It is an up-leveled description of your code that allows you to ensure that its “shape” from a security perspective does not change in an unexpected way.
Not every engineer will be aware of all the ramifications of what they code, either because making mistakes is human nature or because there’s just too much code out there to read and understand all of it. And so you generally rely on assumptions. With what we do at ShiftLeft, it is our job to give you visibility into these assumptions and tell you when they are broken. We bring automation and insert security without slowing down DevOps. I will elaborate with a few specific examples of where Security DNA can be immensely beneficial in a future blog post.
