Using DevOps practices, you no longer need to worry about manually testing and finding bugs in your code, which saves a lot of time and allows developers to focus on writing code. However, one aspect that might get overlooked in a DevOps lifecycle is security, and it might often be overlooked during the entire SDLC and is checked only after the product has been built.

Normal DevOps Workflow

Before we look into why traditional security fails with DevOps, let's look at a normal DevOps lifecycle.

In a normal DevOps workflow, you would have a ton of automation for building, testing, and deploying your applications. Around 60% of your work would be automated and you can focus on writing more code and improving your applications.

Developers will write and push their code to GitHub, then a CI pipeline would build and run unit tests on your code to make sure everything is working as expected. If there are some bugs, you would get notified about them and will have to fix the bugs.

Once all the tests have passed, the pipeline would re-deploying the application with your changes in it and update the existing container image.

Now you can configure and monitor your application once it's on the cloud, look out for any potential bugs, and cases that might cause downtimes, etc.

These practices only apply to the application features. At this point, we don't have any automated security tests for our application. The security aspects are being handled manually by a security team.

Traditional Security Downsides

Many things can cause security issues in your applications which can make them vulnerable to attacks. This is a bigger problem if your application has sensitive information about a lot of users. Below are some examples of security issues:

• Outdated libraries: Using outdated frameworks or libraries can make it easier for hackers to steal sensitive data. To combat this, you should use up-to-date versions of frameworks and ensure that they are being maintained.

• Exposed secrets: Secrets refer to passwords, Auth tokens, SSH keys, and other keys which are used to authenticate your application with third-party services. These keys can get exposed if you accidentally push them to your code repository.

• K8s misconfigurations: Misconfiguring your Kubernetes clusters can also lead to security risks. Some examples of Kubernetes misconfigurations include using wrong namespaces, allowing privilege escalation, giving elevated privileges to containers, and more.

• Container Image vulnerability: Your container images themself could have some kind of vulnerabilities. This can be because of using too many unnecessary dependencies which creates bloated images. This can have both security and performance implications.

• Code Vulnerability: When talking about Security, we certainly cannot exclude the vulnerability that the code might have. These can be some logical errors, using incorrect access modifiers, or using an outdated version of the language.

Security Bottlenecks

As we mentioned above, these processes are not automated and are done by a team of security experts. Since this is a manual task, it can take days or even weeks to run security checks and make sure the application is as secure as possible.

This delays application releases, and since it is a manual process, there is a high chance of human error where some vulnerability is overlooked.

Applications are under greater security risk

Today a lot of organizations run their applications using Kubernetes since it has several useful features. Kubernetes uses a microservice architecture in which your application is made up of hundreds or even more APIs.

On top of these APIs, we use many third-party integrations along with Kubernetes to increase its functionalities. If these integrations are outdated, they can be exploited to gain access to your cluster.

This ultimately increases the attack surface where hackers can find and exploit vulnerabilities in your clusters.

Outdated Security Tools

The cloud-native ecosystem is rapidly evolving, with new tools, technologies, and features being released frequently. Kubernetes is also rapidly changing.

This ultimately makes it difficult for security tools to keep up with the rapidly evolving ecosystem. To develop security tools, you would need to first find and encounter a possible vulnerability, run multiple tests then find out how to secure the exposure.

DevSecOps Benefits

This is where DevSecOps comes into the picture. With DevSecOps, security is no longer outside the DevOps scope. Security scannings are included in the CI/CD pipeline which ultimately creates faster and more efficient security scanning.

There are a ton of tools as well which can scan your container images, check for vulnerabilities, and show you exactly what is causing vulnerabilities and potential fixes.

Using DevSecOps also lets you write secure code from the get-go, instead of having to clean it up later which can take a lot of time. This also reduces the overall security risks that are present in a production environment.

How DevSecOps Works

As mentioned above, security scanning is included in your CI/CD pipelines, but there are also a few other steps to take into account. In your pipeline, you would be using a security policy such as the NSA or you could build your custom policy.

We also use an external secret manager. This means that you would no longer be pushing your secrets into your code repository. The secrets will be stored in a secure external environment, which can be accessed in your production and testing environments.

At the heart of any DevOps workflow lies containers. This means that securing these containers is now more critical than ever before. There are several good practices you can use in different phases of the container lifecycle. I recently gave a talk at DevSecCon about container security. Check it out and learn more about it.

In many scenarios, securing your Kubernetes clusters would often be all about implementing the best practices within your cluster configuration. However, with the tremendous customization options that k8s provides, this can be challenging, to say the least. Moreover, there is always a possibility of human error.

In this aspect, integrating security testing into your CI/CD pipeline reduces the risk of vulnerability. There are several tools that you can easily integrate within your existing pipelines, and have them detect vulnerabilities. These tools will usually highlight any security threats that exist either in your code, containers or your cluster configuration files.

Tools and learning resources

Now that we understand what exactly is DevSecOps, and how the entire process helps speed up the development lifecycle, let's list out a bunch of tools to integrate within our existing pipelines to secure various aspects of the overall SDLC

Tools

• SonarQube - Code security analysis

• Snyk - Helps you secure almost all aspects of your pipeline

• Falco - Runtime security tool

• GitLab - The CI/CD features provided by GitLab have some amazing features for DevSecOps

• AquaSec - Multiple tools covering various security aspects of the SDLC

• ArmoSec - Almost everything related to Kubernetes security

• Sysdig - Provides insights about various runtimes

• Clair - Provides a static analysis of vulnerabilities in application containers

• Calico - Provides features to secure your networks

These are just a few of many tools out there which are useful for security. You can find many more tools in lists such as Kubetools or the CNCF Landscape under the security and compliance section.

If you want to go into a lot more depth around DevSecOps, I recommend checking out Micheal Cade's 90 days of DevSecOps repository. I personally consider it a goldmine of amazing knowledge.