What is DevSecOps? When you have been in IT for any time, you have probably heard the terminology DevOps, and it is a mashup of IT operations and software development. How do you define this, and what does it contribute to the party?

Table of Content:

  1. What is DevSecOps, and how does it differ from DevOps?
  2. Getting started with DevSecOps.

What is DevSecOps, and how does it differ from DevOps?

The definition of DevSecOps:

In a nutshell, DevSecOps involves building great applications and empowering people to understand that security is the responsibility of all. It implements the lessons that we have learned about running, deploying, and building apps over the last 40 years of research and practice. Then builds in the idea that security should not be a checkbox nor a step at the end of the process. That has been tried before; we have tried that for the past 40 years. This way of doing things has proven to be expensive and error-prone. The system broke, and instead, DevSecOps has begun folding in security throughout the process. Thus, when you consider DevSecOps, it is impossible to call it a fad. It is not something that was chosen from a varying methodology. It represents the evolution that has occurred due to our lessons.

How Fuzz Testing can improve Application Security Testing:

The application security testing process ought to be evolving. When you look at the history behind DevSecOps, you can understand its issues and its attempts to fix them. This all started back in 1976 with the IEEE conference and a paper on software engineering. This paper was key in ingraining the idea that security ought to be viewed as a checkbox at the end of the process. It is crucial that you consider what that proposal meant and how it was fixed. Before, we used to mainly consider software security and the waterfall method. The 1976 paper led to this, and it has five varying steps. We can highlight them below:

  1. The first step entails going out and gathering a bunch of requirements. You should consider what the goal you are trying to achieve is?
  2. The next step is the design phase. This is the point at which you consider the varying components; how do we start dividing it up into teams and break it up, among other things.
  3. The third stage is the implementation phase. Here you involve all the developers who are developing the app, and of course, this is because you will be expected to double-check the work their work, you will place in a verification step. This means that initially if you want to verify, ensure that the implementation meets the requirements and understand what happens over time as security evolves. As security starts to be thrown in, it is important to verify that it is safe, and then you can safely enter the maintenance phase.

The Challenges of the Waterfall Method.

There are at least three big problems. Firstly, the waterfall method is very linear and does not follow how the world works. It is crucial to remember that we learn things as we start to implement and deploy the applications. It is important to establish a feedback cycle. Currently, we consider the development component as a cycle, and it is imperative that we have four separate steps involved:

  • Planning - it is similar to the requirements phase. Here you are expected to code.
  • Build - then, you are going to build the software. The build phase is very crucial. This was not included in the old phrase, and it was discovered that software just got more and more complicated. It is key to integrate one development team with another prior to the finished application product.
  • Testing - there was a realization that the verification stage did not involve just verifying requirements; it also means determining how well it works.

Finally, we have a test phase. This realization is that verification is not just verifying the requirements; it tests how well the app works. So when we think about development, we are attempting to make it a fast-moving cycle where you can revisit the planning phase, you can go back through code, build, test, and then, of course, we're going to have various software releases. So we're going to release it.

The second thing Waterfall didn't think about is how you go about operating the software. If you ask professionals in IT how you build the software, it makes a big difference in the security and just the speed at which you build great ops. So DevOps decided to add this idea of there's the operation cycle.

You're talking about IT, and there are a couple of different steps here. We have a configuration step--again, it will operate in a circle. There is going to be a deployment step. There is an operations phase. This is so that after you have deployed everything, you get to sit there, and it will be doing what it does. Then we have added an observability component to the process. You can, for instance, log what is going on and understand how your users are interacting with it. This is where you place the tracker for people who hate trackers, right?

So this is what happened with DevOps. What DevSecOps does is take this idea that security is everyone's responsibility. When you talk about DevSecOps, security will be part of this whole cycle. In a nutshell, we started with this idea that security is last, and that wasn't the only problem here--there are three. The first one was a linear process. We're going to make it a cycle.

The second option is to figure out how to maintain the software if deployed--that is, the operation side. On the other hand, the security side was, it's going to be everyone's responsibility. As I said, this will be a tight loop where we will take lessons as we have deployed it as we're operating it. That's going to be feedback to the planning phase. This is how we have evolved over the last 40 years.

So DevSecOps is simply not a fad. It is not something that you choose over some other methodology. It's taking all those lessons we learned and putting them into one great framework.

Additional great topics on software testing:

https://www.parasoft.com/blog/what-is-service-virtualization

https://www.parasoft.com/solutions/unit-testing

https://www.parasoft.com/solutions/static-code-analysis

https://www.parasoft.com/solutions/misra

https://www.parasoft.com/solutions/iso-26262

https://www.parasoft.com/solutions/devsecops

Getting started with DevSecOps

I think out there today, there are a lot of varying tools people can choose from, and sometimes people get confused, and this is attributed to: Well, I thought this tool found all the vulnerabilities present. Why do I need this additional one? And it is really about putting several tools that are appropriate for various phases.

Let us go back and examine that DevSecOps is also a mindset. It is about the processes and the people, not just the tools you've got to invest in those first two components, as well. Tools--think of them as an enabler so that as we go through this cycle, you can start thinking about the sort of tools you would put in.

Firstly you would think of when we think about the planning stage, and people have started building program tracking and issue tracking systems, things like JIRA, for instance, where you can be fast about coming up with this set of requirements. Utilizing JIRA templates for tasks can further streamline this process, making it easier to manage tasks and track project progress efficiently.

Anchor: JIRA templates for tasks

It is also something your development team can look at. It's not separate; for example, the business unit team does it. We observe those coming in here, and this is also a great place to start thinking about the security architecture and the sorts of things you want to secure. Where is your data? Where is your attack surface? And so on. And the coding step--of course, when you are looking at DevSecOps, you want to have revision control. The reason behind this is that you want people to be checking in code; as the changes come in. Making it possible for you to start adding in processes such as peer review so that you know, if you wrote code, at times as the author, you do not see the blind spots. Therefore, someone else, when they check-in, reviews it and makes sure it is safe, secure, and appropriately coded. It makes sense that the build step has gotten a lot of attention in DevSecOps.

We have this because detection often puts hooks into the build step. After all, this is the first place that all the code that's been written gets integrated. So there are a couple of things people do here. One of the things that are helped DevSecOps is the idea of reproducible deployments. That does not sound anything like security, so let me explain.

When you observe the old days, back when I was first writing software, you had development, and they had come up with maybe a package that you had to go in and install on a completely different system and that this system had one set up and this one had a varying setup. Well, that is just asking for security problems, right? Tools like Docker have become popular during development, and we can test both--a development platform and how it will be operated and make sure those are consistent and that we have put in all best practices.

The second set of devices that people hook into the build system is a set of application security testing tools. We want to look at the different types that get in here and what they do. There are two different sets of tools that people get at a high level. In my mind, if you look at the Gartner group, they have magic quadrants and so on.

The tools that find known vulnerabilities and those that find unknown vulnerabilities are two different sets of tools. A known vulnerability is something I am building, and I am using an open-source component, and there's been a vulnerability found. How do I ensure that I am accurately following and tracking that latest dependency? The big tool that people use here is software component analysis.

It's kind of a funny story that Equifax got hacked, and one of the reasons they were vulnerable is they're running a vulnerable version of the patchy struts. Apache realized that vulnerability and fixed it nine weeks before the hack. So if they had been running software component analysis, they would have had nine weeks lead time to find that issue and fix it. Think of it as checking your library and making sure it is up-to-date.