5 Real-World Applications + Examples of DevSecOps

If you're read our previous article, you should have a pretty good of idea of what DevSecOps means. Here we'll try to explain how this plays out in practice, by covering 5 ways DevSecOps is used in real-world development workflows, along with examples of what this would look like in a typical software team.

1. Static Analysis Security Testing (SAST)

What is it: SAST entails analyzing source code to find vulnerabilities that could make you susceptible to an attack. SAST solutions look at the code without executing it, hence the term 'static'.

An example: In a DevSecOps approach, as soon as the developer pushes code to a repository, an automated SAST tool scans the code informs the developer if any vulnerabilities are found. This could be something like improper error handling, insecure data storage, or other issues. The DevSecOps idea here is that security is 'shifted left' into the developer's workflow, rather than bolted on externally by the security team.

2. Dynamic Analysis Security Testing (DAST)

What is it: Unlike SAST, which looks at the code from the inside out, DAST looks at the application from the outside in. It does this by simulating attacks on a running application and identifying potential vulnerabilities that could be exploited by a malicious actor.

An example: In the DevSecOps model, an automated DAST tool can be triggered each time a new feature is deployed to a staging environment. This ensures that potential vulnerabilities, such as cross-site scripting or SQL injection flaws, are identified and addressed in real-time, prior to the application moving to production.

3. Infrastructure as Code Security

What is it: In a modern DevOps environment, infrastructure is often defined as code using tools like Terraform, CloudFormation, or Ansible. But just like application code, infrastructure code can also contain security vulnerabilities. Tools like Checkov or Terrascan can be used to scan IaC for security issues.

An example: Consider a scenario where a developer is configuring an Amazon RDS database instance using CloudFormation in AWS. In a DevSecOps model, every configuration change triggers an automated security scan. For instance, once the CloudFormation script is pushed to the repository, a scanner can analyze it to identify any issues such as lax access control or unencrypted storage. If the script inadvertently allows unrestricted inbound access to the RDS instance, the scanner would flag this issue and inform the developer. This allows for the immediate resolution of the problem, even before the database is deployed, minimizing the risk of data breaches.

4. Secure Code Review

What is it: Secure code review is a practice where developers' code is systematically inspected for security vulnerabilities. This is typically done before the code is merged into the main codebase. It helps catch potential security issues that could have been missed during initial development.

An example: A developer is writing code that deals with user authentication. The developer mistakenly implements a weak password policy, which puts user data at risk from potential brute force or dictionary attacks. As part of the integrated secure code review process, an automated security tool scans the newly committed code and identifies this weakness. The developer is then immediately notified of the vulnerability, enabling them to enhance the password policy by adding complexity requirements.

5. Container Scanning

It's common to use tools like Docker and Kubernetes for containerization. However, containers can also introduce vulnerabilities. Tools like Clair, Docker Bench, and Aqua Security are used to scan these containers for any known vulnerabilities, misconfigurations, or security policy violations. For instance, if a Docker image is using an outdated version of a library that has known vulnerabilities, these tools are meant to catch that and alert the team.

An example: A developer is creating a new container image for a microservice in a Kubernetes application. The developer inadvertently includes an outdated library with known vulnerabilities in the Dockerfile. When the developer pushes the Dockerfile to the repository, an automated security scanner integrated into the CI/CD pipeline scans the Docker image. The scanner detects the outdated library and immediately flags this issue. The developer is alerted to update the library to a secure version before the image is built and deployed, preventing potential security breaches.

In all of these cases, the goal of DevSecOps is to "shift left" and catch potential security issues as early as possible in the development lifecycle. If it works out as planned, this not only reduces the risk of security breaches but also saves time and resources by catching and fixing issues before they become a major problem.