What is Dev Sec Ops?

Introduction – What is Dev Sec Ops?

As the world of Cybersecurity starts to become more complex and dynamic to levels never seen before, there is now paramount pressure that is placed upon the IT Security teams across Corporate America to increase their vigilance. It is not just from the standpoint of thwarting off the bad guys that are trying to break in, but it is also trying to predict what future variants could potentially look like down the horizon, so that lines of defenses can be beefed up accordingly.

But now, everybody has a stake in this proposition – all the way from the C-Suite to the administrative assistant. There was one group that has stayed relatively immune from falling under the microscopic eyes of Cybersecurity, but this is now no longer the case.

This group is the software development teams. Since folks started developing software their job has been to develop and compile the source code for the Web application that they have been tasked to create, and ship it off to the customer, under budget and on time.

Because of this, implementing security testing solutions has long been an issue which has remain largely ignored. As a result, Cyber-attackers are finding ways to covertly sneak into the backdoors that are left behind, and stay in for extended periods of time, very often going unnoticed.

Then once they feel comfortable in the environment they have infiltrated, they move in a lateral fashion, deploying malicious payloads along the way which even the traditional antivirus and antimalware packages cannot capture.

Or they could start a data exfiltration process, in which small bits of the PII (Personally Identifying Information) datasets are slowly extracted, once again going unnoticed. Because of recent attacks (most notably that of the Solar Winds hack), software developers are now feeling the heat to make sure that the source code they compile is secure in every aspect possible.

Thus, this is where the acronym “DevSecOps” is starting to come into play. It stands for “Development, Security, & Operations.” The primary goal of this is to introduce and deploy automated security mechanisms into the entire lifecycle of the software development process.

If security was ever a concern in the past, it was done at the very end, in a very haphazard fashion. One of the primary goals of DevSecOps is to introduce it at every level of development, so that each software module is thoroughly tested before moving onto the next one. Thus, the cascading effect of un-remediated vulnerabilities and gaps is greatly mitigated.

Another key strength of DevSecOps is that it integrates not only the software development teams, but also the IT Security and Operations teams as well into one cohesive unit. This brings an extra set of eyes to help make sure that the nothing in the security process gets overlooked.

In other words, the siloed approach is now fully eradicated, and it has now become a shared responsibility, which leads credence to the DevSecOps motto: “Software, Sooner, Safer.”

This allows for robust and secure code to be delivered without slowing down the software development cycle. Put another way: “DevSecOps helps enterprises to innovate securely at speed and scale.

How To Implement Security into DevSecOps

It is important to note that implementing a Cybersecurity mindset into your software development process is not something that can be deployed anywhere at any time. It must start early on, preferably even before the application project has even started.

But most importantly, this kind of thinking must be adopted by all the departments in your business. It is not just the IT Security team that has to believe in this framework, every employee must, because everybody has a key stake in keeping your business safe and secure.

But as it relates to DevSecOps, this proactive mindset must be formally acknowledged and embraced in the planning stages of the software development cycle. From there, it then transcends in a lateral fashion until the coding is all done, and the project is ready to hand off to the client. For purposes of this article, a hypothetical software development process can be represented as follows:

  1. Planning
  2. Defining the Requirements
  3. Designing & Prototyping
  4. Development
  5. Testing
  6. Deployment

The above can formally be called the “Secure Software Development Lifecycle,” or “S-SDLC” for short. Each step is reviewed as follows:


In this step, you have been assigned a project, and are in the process of assembling your software development together. This phase of the S-SDLC can be viewed as a macro one, as you are taking a holistic view of the kind of application that will be required and defining the overall objectives of what needs to get done.

But most importantly, you are acknowledging the fact that security is going to be a top issue here, and you are laying down the foundations as to how the system of checks and controls will evolve. But also, you are also figuring the roles that the Operations and IT Security team will play in the S-SDLC.

Defining the Requirements

Obviously in this phase, you are formally defining the needs and wants of the client in the project and mapping out the various software modules that will be needed to meet this objective. But also remember that this is the key stage in which you will formally address the types of security issues that you think could evolve as the development process evolves. It is particularly important that you take your time in this crucial phase, and this is one of the biggest areas in which you will need to involve the IT Security and Ops teams for their input.

This can also be referred to as the security forecasting stage. There will be issues of course that will come up of which your teams did not anticipate here. The goal here is to map out every what-if scenario that you can, so that any items of concern can be addressed quickly and efficiently. To help you in this process, there are various methodologies that are available, and the one that is most widely used is the Open Web Application Security Project, also known as “OWASP.” As its name implies, this is an open-source platform in which the public can get access to the latest Cyber threat variants that are out there, and which are also ranked according to their degree of severity.

The bottom line is that before you can move forward, all the teams must come to a common consensus of the potential vulnerabilities and threats that they need to be on the lookout for as the source code is being developed and compiled.

Design & Prototype

It at this phase that you will start to implement the security controls into the various software modules, paying attention to these top three design philosophies:

1) The Principle of Least Privilege:

This is the minimum rights, privileges, and permissions are established. In other words, end users will gain access to whatever they need to perform their daily job tasks, and nothing more than that. It is important that the source code be flexible and dynamic in this regard, as roles and titles do change among employees.

2) The Principle of Separation of Duties:

With this concept, you are never giving away total, 100% control to just any one employee. Rather, it takes a few individuals to complete one large task, in a sequential fashion, based upon the rights, permissions, and privileges that they have granted. The source code that is being developed needs to have this kind of functionality implemented.

3) The Principle of Minimizing the Attack Surface Area:

This simply means that that the source code which is being designed is clean and robust in nature, and most importantly it is not bloated in nature. For example, software developers like to use APIs (Application Programming Interfaces) to keep up with the timelines that have been established in the Planning phase. But there can become an over-dependence on using more APIs than are necessary in this regard, which will make the overall application larger than what is necessary. What this translates into is that the Cyber-attacker now has a much larger attack surface to penetrate to spread their malicious payloads. But by having the source as “lean and mean” as possible, the attack surface greatly reduces in proportion.


As its name implies, this is the part of the S-SDLC in which the actual source code is compiled. The actual development process does not occur in just one huge chunk, but rather, it is done at the modular level, which was pre-established back in the Planning phase. As technology is rapid advancing at a rapid pace, so are the tools which are used to create the source code. In this regard, automation has become important, not only to keep the project moving along, but also to reduce the number of errors that could occur.

Automation can replace many of the mundane and repetitive tasks that are involved, even when it comes to the security perspective. Some examples of this include the following:

  • Continuous Integration: This is where the software developers submit each iteration of the source code that they have worked on into a central server and is combined into one unit. It is not just a one-time deal, it can occur several times a day, depending upon the scope and magnitude of the development project. From here, automated builds and testing can then take place, to track down any errors and vulnerabilities that exist in a very quick manner.
  • Automated Security Testing: This is where Penetration Testing comes into play. With this, the primary objective is to find and locate any hard-to-find gaps and remediate them quickly. There are many tools out there that can do this, such as Kali Linux or GitLab.
  • Secure Code Repositories: This is especially useful for the storing of API Libraries, as reviewed earlier. Here, automated testing tools can double check that any APIs to be used in the S-SDLC are free from any bugs and are updated with the latest patches and upgrades.


To ensure the greatest level security in a software development project, each software module should be tested thoroughly tested, both from the standpoint of Penetration Testing and Threat Hunting. However, this does not each module should be tested one at a time. This would simply take too much time to accomplish. Rather, the automated tools as described in the last subsection can be used to test these modules simultaneously, or in parallel. In the world of DevSecOps, this is technically known as “shifting left,” because you are starting the testing process at the very beginning stages, rather than waiting until the end.

This is illustrated in the diagram below:


(Source: https://www.testim.io/blog/shift-left-testing/)


This phase where the hand-off of the project to client actually occurs. In an ideal setting, the client should also test their new Web application for any weaknesses or backdoors that could have still been overlooked in the S-SDLC phases. But many times, they will not, because they simply assume all is good and fine. Therefore, a critical aspect of DevSecOps is to conduct one last Penetration Test before the application is released into the production environment. There really is no need to involve any Blue or Purple teams at this stage, simply the Red Team will suffice. Of course, anything out of the ordinary should be fixed on the spot.


Overall, this article has examined what DevSecOps is from a holistic point of view. But keep in mind, as it was reviewed before, there are three distinct groups involved, which to summarize are as follows:

The goal here is to bring in all the assets of these three groups so they work in one harmonious fashion to further enhance the overall Cyber posture of your organization. This in turn will lay the groundwork for creating the mindset security is everybody’s concern, all the way from the C-Suite down to the overnight cleaning crew.

There are many other aspects of DevSecOps, one of which is compliance control implementation. This will be examined in a future article.