DevSecOps has become one of the hottest buzzwords in the DevOps ecosystem over the past couple of years. In the abstract, it’s easy to understand what DevSecOps means and why people care about it: It’s a strategy that extends DevOps efficiencies to software security.

But when you sit down and actually start implementing DevSecOps, things can get trickier. There is no switch that you can flip to achieve DevSecOps. Nor is there a specific tool you can acquire, or even a particular process to follow.

Instead, implementing DevSecOps requires you to perform a broad evaluation of your existing IT resources and DevOps processes, then build a holistic strategy that integrates stronger security into all of them. (you can dig deeper into the transformation from DevOps to DevSecOps in the following webinar)

Let’s take a look at how to do that by walking through the main considerations that the typical organization must address in order to achieve DevSecOps.

What is DevSecOps?

Basically, DevSecOps is DevOps with security built-in, right from the start. It means building security into requirements, into the design, the code, and the deployment stages — in short, into your entire DevOps pipeline.

Older security practices tend to slow down development teams and when the time to market is getting shorter every year, software development teams had to find a way to speed up their software development process without compromising on security. This is how DevSecOps started. 

The ultimate goal is to bridge between security teams and developers while ensuring fast, safe delivery of code. Silo thinking is replaced with communication between different teams and shared responsibility of application security. 

How To Translate Theory into Practice?

How do you translate those goals into practice? Which specific security processes can you automate and integrate into the rest of your CI/CD pipeline, and how can you do it?

Let’s explore those questions and look for some answers, based on the current state of DevSecOps tools and practices.

Step #1: Vulnerability Scanning

Scanning your code for vulnerabilities is a basic first step for securing your products. And integrating vulnerability scanning into your CI/CD process is an obvious place to start for implementing DevSecOps.

What this means is ensuring that code is checked for vulnerabilities at every major stage of the delivery pipeline – from the time it is written to when it is deployed into production. To achieve this level of integration, you’ll need to ensure that the parties responsible for these various stages of the pipeline have the training and tools they need to detect vulnerabilities in your code.

The relevant technologies are SAST for detecting vulnerabilities in your proprietary code and SCA tools for detecting open source components with known vulnerabilities. Many SAST and SCA vendors offer integration to CI servers, build tools, repositories and some also integration to IDEs to help developers find issues as early as possible.

Step #2: Runtime protection

Runtime protection is another critical security process that should be integrated across the CI/CD pipeline as part of a DevSecOps strategy.

Runtime protection means securing software against threats that can arise when your application starts running. Although discussions about runtime security have traditionally centered on securing software only once it is in production, runtime threats can exist during earlier stages of the pipeline, too – and even if they don’t, thinking about runtime security early in the delivery process helps ensure that when you do deploy, you’ve already mitigated runtime threats. Both of these reasons are why runtime security should be integrated across the CI/CD pipeline, and not limited to production environments.

The specific tools and strategies that you use for runtime detection will vary depending on your specific needs. At a minimum, however, you’ll want to ensure that you are monitoring your application for unusual behavior that could signal a breach. Just as important, you should be aware of which environment variables or configuration settings could create security vulnerabilities in runtime, and have a process in place for identifying those risks.

Step #3: Your Cloud Service Provider

Another important strategy for integrating security into your application delivery process is to take advantage of the security features offered by your cloud service provider. Many of these tools are positioned at the deployment and post-deployment end of your DevOps chain, and thus resemble more traditional after-the-fact security services. But they still serve an important function as part of your application’s outer defenses — and because they are part of the cloud infrastructure, they are generally easy to automate and systematize.

Note that your CSP’s security features may not be enabled by default, and they may need some configuration, so you may need to take active steps in order to make the best use of them.

Step #4: Standards and Policies

Setting standards and policies for security is largely a hands-on job. You can scan your source code and infrastructure for vulnerabilities, but the process of deciding what your security priorities should be and how they should be implemented still requires serious thought on the part of human beings. The same is true of building in security standards at the design and code levels.

The implementation of the General Data Protection Regulation (GDPR) on the part of the EU makes it even more important for security standards to be clearly formulated and put into place at the level of design.

Building such standards in at the operational level, on the other hand, can be automated to a large extent, by using orchestration tool/service mesh features such as RBAC to enforce policies with a high degree of granularity. The design of role-based access policies should be given as much attention as the design of security standards in your application source code — and they should both be regarded as high-priority tasks.

Step #5: Container and Service Management

Container orchestration tools such as Kubernetes have become a near-necessity when it comes to deploying large, container-based applications. Service meshes, which can work with orchestration tools and manage such things as service discovery and access, as well as the relationship between users, container-based applications, and external services, are becoming increasingly important in their own right.

Tools such as these are a key element of DevSecOps at the deployment level. They act as highly scalable layers of insulation between containers and the outside world (so that users and would-be attackers can only access services concealed behind proxies, for example, rather than individual containers), and they can take care of such tasks as authentication, authorization, and encryption. And they are designed for automation from the ground up.

Even more than with CSP security tools, however, you need to be aware of the security features that orchestration tools and service meshes provide, and you need to enable (if necessary) and configure them. Kubernetes’ role-based access configuration (RBAC), for example, should be a key element of DevSecOps under most circumstances, but it is not enabled by default.

The Bottom Line

There are other important aspects of DevSecOps that should factor into your implementation strategy such as monitoring, log analysis, and alerting. Many of these, however, are standard elements of software and Internet security overall, so I haven’t focused on them in this post. Instead, I’ve centered discussion on how DevSecOps can fully integrate application development, infrastructure management, and other DevOps activities which have not been traditionally associated with security.

And maybe that is the bottom line: when security becomes fully integrated with the CI/CD pipeline, DevOps and DevSecOps become the same thing, and that in turn becomes simply “the way we do software.”

Source: resources.whitesourcesoftware