If you are even remotely associated with the security or the software development world, you would have heard the term - DevSecOps or just DevOps. If not, you are surely living under a rock!! DevOps is one of the hottest trends in the software development world now. In this article, we will, however, focus on DevSecOps. Is it an extension of DevOps? We will learn and explore the details in this blog post. Grab yourself some popcorn and get ready to understand what DevSecOps is all about.
Understanding and appreciating DevSecOps is like reaching a summit. You cannot reach the top until you start from the bottom and learn all about slowly and steadily. This post involves certain terms which are commonly used in software development. In case you feel unsure about the meaning of a particular term, just Google it.
The software has become an integral part of our lives. From power grids to smartphones, all aspects of our lives revolve around software. But how do you develop software? Well, if you want to develop software, you go to a software developer, give him your requirements, after which he starts designing it. Post the design, he implements in a computer language, then tests it if it works fine and post that delivers it to you. This is what is lovingly called the Waterfall Model. Step by step methodology of implementing software. This is how most of the software which is being used in the world currently have been built. Over time, complexity and security requirements have changed rapidly.
New methodologies have come up to address a lot of concerns - Spiral Model, Iterative Model, Agile Methodology, etc. One of such methodologies is DevOps which we will be discussing here.
DevOps is the brainchild of the “born on the web” companies. These companies needed a new strategy which did not involve large timelines ( of years or even months) to push new updates or requirements to the customers. Companies such as Netflix, Amazon push multiple code changes throughout the day. DevOps is focused on removing the latency that has existed for years around software development.
This needs to be understood in more detail through some examples. The first example we can consider is Netflix. If you have noticed some of the finer details while logging into Netflix, you would notice that Netflix updates the thumbnails of all the shows almost on a minimum of a daily basis. Do you think it pushes such updates on a manual basis for every thumbnail of every show it hosts? Such code changes are possible only through automation. This also brings us to two terms that need mention here - continuous integration and continuous delivery, also known as CI/CD. The focus is continuously delivering high-quality code to customers. Coming back to the example above, we need to test the code before deployment. Continuous delivery is all about integrating the various code and using test automation to move it directly to production.
Are you wondering as to when will the discussion shift to DevSecOps? It's time to begin that now.
During the above discussion, you would have noticed that we have not discussed security in the software development process. Well, that has been the case in the world of software development too.
“Security has been bolted afterward and never thought as something to be built with the software from scratch”
DevSecOps aims to change that approach. It intends to bridge that gap between security and agility by building security into the DevOps cycle and making security an integral part of the process. DevOps isn’t just about development and operations teams. If you want to take full advantage of the agility and responsiveness of a DevOps approach, IT security must also play an integrated role in the full life cycle of your apps. Why? In the past, the role of security was isolated to a specific team in the final stage of development. That wasn’t as problematic when development cycles lasted months or even years, but those days are over. Effective DevOps ensures rapid and frequent development cycles (sometimes weeks or days), but outdated security practices can undo even the most efficient DevOps initiatives.
Now, in the collaborative framework of DevOps, security is a shared responsibility integrated from end to end. It’s a mindset that is so important, it led some to coin the term “DevSecOps” to emphasize the need to build a secure foundation into DevOps initiatives.
DevSecOps means thinking about application and infrastructure security from the start. It also means automating some security gates to keep the DevOps workflow from slowing down. Selecting the right tools to continuously integrate security can help meet your security goals, but effective DevOps security requires more than new tools—it builds on the cultural changes of DevOps to integrate the work of security teams sooner rather than later.
Imagine a car that is built. The mechanical engineers can either think about the brakes at the design stage or after the car has been built. You can understand the differences both these approaches will bring to the functioning of the brakes. In the first case, engineers will think about various aspects such as the load of the car, tyres, design of the car, impact of wind, etc. In the second case, the engineers will have no choice but to fit whatever is available or can be done as patch work.
Security has always been a patchwork approach. If the DevSecOps wishes to change that what new does it bring to the table.
There are 5 principles for DevSecOps:
- Automate Security In
- Integrate to fail quickly
- No false alarms
- Build security champions
- Keep operational visibility.
An example will help us better understand all such steps. Google is bringing a new product called “Stadia” which is being dubbed as “Netflix of Games”. Let’s try to apply if Google applied DevSecOps to this new product development, how would they have proceeded in adhering to the aforementioned principles.
When a team of experts would have been formed, a security champion and a privacy champion would have been a part of the team. Security experts bring their expertise in security practices on the table at every step of the software development process. They would have also integrated security right into the design of the product. Multiple code changes at multiple times need to be tested before being ruled out. Developing Stadia would require millions of lines of code written and changed throughout the day. Such changes before being deployed would have passed through automated security tools. Nobody likes a false alarm. More the number of false alarms less would be the adoption of such a technology. Hence, they would have built a mechanism to catch the right set of errors so as to deliver secure code. In the end, having operational visibility over the complete process by the security teams would have resulted in a better product.
In a nutshell, the simple premise of DevSecOps is that everyone in the software development life cycle is responsible for security, in essence bringing operations and development together with security functions. DevSecOps aims to embed security in every part of the development process. It is about trying to automate core security tasks by embedding security controls and processes early in the DevOps workflow (rather than being bolted on at the end).
There are however a lot of questions that still remain unanswered in our minds. If the CEO accepts the security to be a part of his DevOps cycle, how can he direct his teams to implement it? The answer you are looking for is automation. Enhanced automation throughout the software delivery pipeline eliminates mistakes and reduces attacks and downtime. For teams looking to integrate security into their DevOps framework, the process can be completed seamlessly using the right DevSecOps tools and processes.
The benefits are simple: More automation from the start reduces the chance of mis-administration and mistakes, which often leads to downtime or attacks. This automation also reduces the need for security architects to manually configure security consoles.
If you have followed the entire discussion till now, that's great. The biggest question still remains unanswered - Is it so easy to bring about the change required in the organization? If not, how can we do it? The answer is not so simple. There is no magic masala that can act as a tastemaker here and bring about a complete change in your food menu. The way forward can be to demonstrate the benefits by starting to implement DevSecOps in small projects and measuring the benefits. Most organizations release patches on a weekday to fix vulnerabilities. These vulnerabilities take time to fix. Can you reduce the time to fix a vulnerability found when using dynamic analysis in production from X number of days to X/2 number of days using DevSecOps? If we can quantify such visible changes to our customers and management alike, it will result in a sea change in the attitude. The high cost of fixing vulnerabilities later on or risk of data breaches can further act as a catalyst in the adoption of DevSecOps.
What is your understanding of DevSecOps? Share your thoughts in the comments section below.
