DEVOPSdigest

Business demands agility — ever-increasing speed to deliver new functionality to the customers and to stay ahead of competitors. DevOps and agile development deliver on this business goal and are being widely adopted across industries. It's also well established that we need to find how to insert security into DevOps to ensure that security does not get left behind.

Which begs the question — Why hasn't this happened? Why haven't we figured out how to insert security into DevOps?

Is it because we don't know who will do this — developers, DevOps, DevSecOps or SecDevOps, security, or someone else?

Or is it because we don't have the right tools? Which needs to come first — people or tech?

Let's look at what happened with DevOps. Prior to it, IT was buying servers, installing them in their data centers, connecting the network, and deploying necessary software. The same folks didn't get up one morning and realized that they needed to move fast. If they had, they would have found a way to do what they were doing faster — perhaps they would have bought a lot more servers so that they could reduce procurement time, hire more people to deploy the servers and perhaps write some scripts to make the deployment predictable and fungible. Would we call this automation — perhaps yes but clearly it would not have allowed us to achieve the agility we can do today.

Instead, the need to move fast, to drive down costs, and achieve predictability spurred technical innovation such as public cloud that removed the need to procure and install servers. Infra-as-code followed to get desired compute, memory and storage wherever and whenever needed by just typing a few keystrokes.

Using the same parallel, we can see why we don't have a good recipe for inserting security into DevOps. We are still using yesterday's security technology and trying to force-fit it into the modern SDLC. Instead of continuing in this cycle, here are the key requirements for inserting security successfully into DevOps:

1. Security has to be application centric(C). Network gets abstracted in the hybrid cloud and the responsibility of infrastructure security falls on the cloud provider.

2. Given each application, each microservice is unique(U), security has to be customized (personalized) for each application.

3. Security (S) has to be fast, fast enough to never slow down DevOps.

4. Security has to be exact(E), for if you are releasing code every day do you really have the time to sift through 200 false positives.

5. Security should have a system of record(R), so that you understand whether you are accruing technical debt or remediating for security bugs from release to release.

6. Security needs to be scalable. With so much software being developed at such a rapid pace, it is not a human scale problem. We need security-as-code to deal with the pace of innovation(I).

7. Business is driven by new functionality(Y), rarely by enhanced security. As a result, security can't be all-or-nothing. E.g., we can't tell developers that you have 10 vulnerabilities and that you need to fix all of them before you release. We have to provide alternatives.

8. Security needs to appeal to developers(D). They are the ones who are leading the movement to agile development and deployment to deliver new revenue-bearing capabilities to your customers. Piss them off at your own peril!

Which gives us the mnemonic: SECURIDY!

By following this mnemonic, organizations can better address the security technologies they're currently using and evaluate them against these requirements to see where they are failing. From there, organizations can make more informed decisions about the solutions they adopt, and ensure that people and technology can work together to ensure security is being seamlessly inserted into DevOps.