What is DevSecOps?

Have you interviewed for technology jobs lately? It’s an enlightening experience.

Most juniors that come into an interview have recently finished a degree in IT, whether it’s security, architecture or engineering. Class was mostly what they expected: data structures, some programming, low-level process cost calculation, building virtual machines, service administration, how a datacenter works, data recovery, maybe some security as red-team and blue-team…

Or maybe you’re not that junior anymore, but you’ve been sitting in your current position too long, looking at an unchanging Zabbix panel for a day too long, and you need some fresh career choices? turns out, times have changed. Times have changed a lot.

Exploring uncharted territory

So the first thing you may notice by scavenging LinkedIn is that sysadmins are out of style. You don’t want a systems administrator anymore, or at least not someone who’s only a sysadmin. That’s separated from the development team, what’s called a “silo”, and “silos” are so last-gen. Now, DevOps is in!

In this search for something new, you’ve probably come across the word DevOps. We’ve talked about it in the Geko blog before, but here’s the gist of it: DevOps is essentially a philosophy, a way of working in your team, that makes those “silos” merge together and make development and environment management a lot more agile and fast-moving. No more patch Tuesdays, no more “deploying on Fridays” panic!

Now if you’re like most cases that either try to break into an IT field or want a new challenge, you might find yourself wanting to follow the security path. It’s a growing field, there’s plenty of work, entails exciting experiences every day… seems like it’s all positive! (as long as your client listens to your recommendations, of course), but pretty quickly you notice that cybersecurity is one of the fastest moving fields in the industry. It needs to keep up with changing in all of the IT aspects of a company. You’re in charge of protecting every asset around, whatever it happens to do.

What do these two fields have in common anyway?

If you follow that lead and give the thought a spin, there’s a conclusion you may come to pretty fast: DevOps and security are a very good match! integrating everything for automated checks can take work out of your hands, defining security requirements in every part of the process… it just makes sense that if you choose to follow security culture in the entire development process, it will probably take work out of you after the fact.

That thought recently gave way to a new job opening space that integrated security inside the development culture of DevOps, which we named DevSecOps, because the IT industry is about getting work done, not making up fancy names. At least we didn’t let AWS name it so we aren’t stuck with AWS DSO or something… yet.

So, let’s dive into it. DevSecOps, as its easy to recognize name presents, is a culture, a way of working, where we integrate security into the process of DevOps. This is better explained with an example: Imagine you have a pipeline that tests your code before you build and publish it to test if it works as intended: unit testing, code analysis…

Well, you can do something similar with the rest of the environment, like for example analyzing if the infrastructure the code is gonna run on is well configured and has no security problems by analyzing your Terraform declarations for encryption missing in a volume, or an unrestricted security group. If the alert is raised before the infrastructure is built, you don’t have to fix it later!

I like this idea. How do I implement it?

The entire idea can be summarized into a simple concept: Security isn’t a toggle you can click. You don’t apply security efficiently by installing that software the vendor recommended to you. Security is work culture. A continuous process that is better built into your development pipeline, preferably with automated checks that tell your team that something needs changing. No deployment with security holes in your ops team’s watch. But even then, maybe you don’t need ops intervention, since your developer may just get notified of this security flaw that needs fixing before deployment. This entire thought process is about breaking the concept of separated teams and making departments more connected and cohesive.

Isn’t my infra setup a bit too old-school for this?

Even if your infrastructure seems too legacy to adapt into the DevOps way of working, DevSecOps could be important. Uploading some Ansible playbooks to GitHub? Maybe pass them through a security analysis module when they get pushed out as a pre-commit hook. Built your own docker images for some specific task? Maybe you want to give them a spin through an image analyzer like Snyk or docker scan (did you know Docker had its own vulnerability analyzer? I didn’t!). Are you moving some infrastructure into terraform code? Bridgecrew integrates into pretty much any provider to alert you of that slip of “allow 22/tcp from 0.0.0.0/0”.

Any small step is a big move towards making work easier for your developers in the long run in avoiding technical debt and lifting load from your ops and admin team from these janitor tasks so they can focus on the really important tasks in your organization. Also worth noticing these tools are far cheaper than an incident response spending. Certainly in money, maybe in public image. I’d gladly take some cheap AWS Security Hub alerts over a GDPR fine.

I’m in, let’s chat.

Are you new to all this and you want to learn? Do you want to bring your DevOps knowledge to a new challenging ground? Here at Geko we’re always looking for talent from any expertise level.

Have you been thinking about getting up to speed on your infrastructure security? Well, maybe you should. And we at Geko Cloud could help you with that. At Geko Cloud we are specialists in Internet platforms, cloud infrastructure management and microservices. Contact us without any commitment and we’ll have a chat about stepping up your operations game.

Leave a Reply

Your email address will not be published. Required fields are marked *