I’ve explored, in shallow depth, a lot of the domain map of cybersecurity (see here). I’ve looked at the domains overviewed in Security+ (physical security, cloud security, frameworks and standards, risk management, security policy, etc.), as well as domains I have learned about on my own or in school, such as cryptography, security engineering, red-teaming, network infrastructure, SIEMs, incident response, etc. Security is a huge space, which I think not a lot of people understand. When I say I study cybersecurity, the vast majority of peoples’ minds go to hacking. If I’m lucky, they will think about defending, too. However, it never really gets much deeper than that. What I’ve learned from my brief foray into the world of security is that there is a lot going on behind the scenes that not many people (except for those who work in the space) really know about. One of those things is DevSecOps.

What is DevSecOps?

Your guess is as good as mine. On a real note, I have a limited understanding of DevSecOps because I’ve never actually done it. My answer to “what is DevSecOps” could actually be quite wrong, and in that case, maybe I’m not fit to work in the DevSecOps space. But assuming that my knowledge is correct, or at leat based in fact and on the right track, I see it as (in simple terms) the following:

1. A team effort: DevSecOps is, as DevOps is, a team effort between multiple groups. DevOps is, of course, the collaboration between developers and operations! DevSecOps adds one more little caveat (a very small caveat [this is sarcasm]): security.
2. A way to ensure that software that is being developed is safe, secure, and effective, using CI/CD to automate the deployment/testing/security checks of said software.

There’s more stuff to it, but from a high level, that is how I see DevSecOps.

Why DevSecOps?

I started my career in the computer science space as a web developer. I can personally guarantee you that I created a nonzero amount of security flaws in the software I created for the company I worked for. And guess what? It was not at all my fault. I will explain why that is, and what leads me to believe that I am not alone in my experience.

I don’t trust developers, and for good reason.

I do not trust developers. Having started as a developer, I know what it feels like to be in an actual business scenario. This is not creating a chat bot for your CS101 class. This is a fast-paced environment where your work has a specific time limit. You need to write your code, make sure it works, and run it by other people – all before the deadline. Security is simply not a priority in a sprint. That’s how it is, and that will not change. It should not be the developer’s problem to ensure that there are zero security flaws in their code. The developer already has enough problems to deal with. Instead, it should be up to a team effort, where people who know development, infrastructure, operations, and security can set up pipelines and procedures to ensure that the developer is being supported with useful automations while also teaching them to write code that is secure. Well! That’s where I want to step in!

My turn!

I have a development background, security background, and somewhat (not much) of an operations background. The math checks out for me to explore a field that takes knowledge in development, security, and operations! In reality, I have a small dilemma that has led me to this path:

1. I don’t want to stray from the development side,
2. I want to stay in the security space, and
3. I love infrastructure/configuration/efficiency/…

DevSecOps would give me – I think – a nice melting pot of three domains that I am highly interested in. Have I ever really done DevSecOps? Absolutely not. However, later on in my career, when I am more experienced in these three areas, I hope to jump in to the DevSecOps world.