Moving from DevOps to DevSecOps

Who should read this DevSecOps article?

Whether your company produces or consumes software, understanding the best practices when moving from DevOps to DevSecOps is important to you.

If your company does not operate any agile model or even DevOps practices, surely one of your suppliers uses this method in development.

That’s a good reason for you to know more about each of them, and how a development team can improve their practices by adopting agile development methodologies, as we’ll see below.

We also have a video about this subject on our Youtube channel – you can turn on subtitles by clicking the CC icon at the bottom of the video.

DevSecOps & Agile Development

In order to understand this change, we first have to explain what the two models, DevOps and DevSecOps are. Let’s try to do it as simple as possible.

DevOps models have emerged with the goal to provide greater agility for development teams, who now assume operational activities throughout the process.

This made it possible to integrate two steps that previously took a much longer time, which often led to delays.

With the fostering of DevOps practices, development teams began delivering products faster and faster. This may have been one of the factors that led to increasing demands on the speed of product delivery, creating a circle of requests.

Agile Development and Application Security risks

Within this process, much has been done in performance improvements for development teams.

However, when you speed up a process without being prepared for it, something is lost.

In this case, what was lost was the focus on application security.

As it should be, DevOps processes focus on delivering products in the given time required by the market, which is great from a productivity point of view.

However, this speed of delivery becomes a problem if it becomes more important than preserving the security of a product.

We know that there are some tests being done in this process, but often they generate more work and consume much more project resources.

How DevSecOps was defined  

O termo DevOpsSec foi primeiramente analisado pelo Garnet no ano de 2012.  Na época, o termo era escrito desta forma mesmo, com “Sec” depois de “DevOps”, pois o pensamento inicial era apenas acrescentar segurança a um processo já existente.

The term DevOpsSec was first analyzed by Gartner in 2012. Back then, the term was written just like this, because the idea was to add Security to DevOps an existing process. 

At that time, Gartner pointed out to development teams the necessity of a posture change to be able to introduce the best practices of security in a development model already implemented.

Researchers from Gartner have defined DevOpsSec as a process that would go beyond producing software: it is all about cultural change within development teams.

This cultural change aimed to firstly introduce the security concept to all development processes, reducing test friction in the project.

It is notable that in projects whose main focus is not safety, testing is usually performed in the last step. This was one of the points of improvement pointed out by Gartner.

The correcting of this point led to the creation of a development process where security was seen as a key component of the entire coding creation process. In this context, the greater the automation in the process, the more effective it can be.

How to go from DevOps to DevSecOps

Now that we have a sense of what each of the two methodologies is, we can think a little more about the evolution of these models.

To summarize DevSecOps, it would basically be a culture change within development teams, which look to security in all aspects of development.

Thus, it would enable the team to identify vulnerabilities or even the possibility of a vulnerability in the early stages of development.

If we consider this thought as the starting point of a change, it is essential to consider building an automated DevSecOps process with a very strict security mentality by the developer.

The big challenge is to introduce a radical change in thinking into the development process. It is necessary to give everyone involved the clear message that security is one of the most important components of application development, and it must be designed to enable the necessary checks.

At this point you may be asking yourself, “okay, but how do I implement DevSecOps in my process?”

We understand that when asking this question, the company already has a DevOps framework with a considerable degree of maturity, and its teams already understand that the change needs to come from within the process.

So let’s talk about what we can do in the next topic.

Adapting to the Shift Left Model

Since our goal is to rely on security from the early stages of a development process, it is only natural that one of the first steps is to evaluate your process. You must do an exercise to move the security focus to the left of the development pipeline.

But what does it mean exactly? Looking at the beginning of security-focused development means that we are looking to anticipate potential software issues that may appear.

Thus, as we begin the development journey, one of the first things to keep in mind is that the responsibility for software security should not be placed just on development teams. This responsibility must be shared with all process participants.

Fostering Continuous Automation

When talking about continuous automation, it is important to understand that it consists of using tools and techniques that can ensure continuous code integration. This process, along with continuous delivery, enables development teams to focus on other important activities.

In this article on structuring practices and tools for DevOps and DevSecOps, Gartner helps us to better understand how automation and constant code checking are critical to good security approach planning.

Automation, when placed in the development process from day one, is a strong ally for reducing or even eliminating the constant conflict between security and development teams.

In this other article, we talked about it and how a Security Champion can help, even within an automated process.

Automated processes can help as they enable development teams to work on code that has had problems in a short time, not on 3 or more sprints ahead. This is important as it avoids unnecessary decay on teams.

This thought can lead to more efficiency and control for everyone involved in the development and security process of an application.

Introducing Governance in the Development Process

Governance and development teams often disagree on how the process will ensure code security.

Orchestration tools can be introduced to help resolve this conflict.

In addition, introducing criteria can help governance and DevOps work together by ensuring that when delivering the code it has gone through a structured process, reducing the possibility of failures.

As we all know, performing full code security testing is much more complicated and expensive than solving it early in the development process.

With this in mind, governance becomes an important factor in processes. This makes it possible to track the events that deserve attention throughout the development process so that security teams can audit, monitor and guide progress throughout the life cycle.

Using microservices and containers when moving from DevOps to DevSecOps

In a world where we see applications built by microservices and containers, it’s impossible to not talking about them.

We need to notice that while recognizing that there are great advantages to using microservices and containers, they also bring us new challenges.

We can’t ignore that the proliferation of these points in a structure, and the easiness in which they can be created, also increases the attack surface, and thus the risks.

With this in mind, it is natural that one of the recommendations is to ensure that these new services and containers are brought into the validation process as much as the codes.

In this other article, we talked about containers and some recommendations on how to keep them safe.

Finally, when thinking about microservice and container security, it is important to emphasize that an organized and defined hardening process must be implemented.

This security validation process should always be accompanied by constant monitoring to ensure that any anomalies are identified.

Threat Modeling in Software Creation when moving from DevOps to DevSecOps

Taking a break from the models discussed above, threat modeling is basically all manual.

It is a longer process, focused on complex structures and designed to meet more agile development models. Although more exhaustive, it is certainly worth all the time and effort spent in the process.

If we consider the modern application design, the challenge becomes even greater. We may be dealing with hundreds of APIs today, as well as virtual systems distributed on-premise and in the cloud.

Looking at this scenario, we see that this complexity can make the view of the application structure quite confusing.

However, this is precisely the strength of threat modeling. By designing the architecture and the application system, it is possible to identify much more clearly and prematurely the possible threats that the software may suffer.

This makes it easier to work on solutions that will strengthen application security.

Therefore, it is undeniable that the visualization of the structure obtained through threat modeling is a benefit of this practice, but we also understand that there is a high degree of complexity to implement a modeling process for each created application.

However, the use of this type of methodology is important to ensure security throughout the development pipeline and, consequently, the safe development of applications on an ongoing basis.

Moving from DevOps to DevSecOps: a constant evolution

It’s obvious that we can’t synthesize all-important content of DevSecOps in only one article.

However, we focused on points that we believe to be fundamental to improve and evolve from DevOps to DevSecOps.

It’s important to emphasize that, as the other topics within the subject AppSec, the list hereby presented can not be seen as definite or even unique in a constant-evolving universe, that adheres to changes quicker each time 

Therefore, in this article, we are looking at transmitting the vision that is necessary to assess and to search for constant improvements of processes, searching to ensure that results are safer each time.

So, we can conclude that by following the guidelines in this article, you pave an increasingly solid path towards keeping your applications secure within the model and agile development, and specially aligned with the best practices in the market.