Inside a DevSecOps CI/CD Pipeline: How Automated Security Checks Protect Every Commit

Introduction

In the previous article, I explored how threat modeling identified the risks facing a vulnerable fintech microservices application.

Those risks influenced every implementation decision that followed.

The next step was translating those security requirements into an automated CI/CD pipeline.

Rather than relying on manual reviews before deployment, every code change automatically triggered a series of security checks designed to identify vulnerabilities as early as possible.

This article walks through that pipeline, explaining what each stage does, why it exists, and how it contributes to building secure software.

Why Security Belongs in CI/CD

Continuous Integration pipelines are often associated with compiling code and running automated tests.

Modern DevSecOps extends that responsibility.

Every commit should also answer an important question:

Is this change introducing new security risks?

Waiting until production to answer that question is expensive.

Automated security checks allow developers to receive immediate feedback while changes are still fresh, reducing both remediation effort and deployment risk.

The Pipeline at a Glance

The GitHub Actions workflow consists of multiple security stages.

Each stage focuses on a different attack surface.

The pipeline includes:

• GitLeaks
• SonarQube
• Trivy
• Checkov
• OWASP ZAP
• Security Gates
• SBOM Generation
• Cosign Image Signing
• Deployment

Figure 1. GitHub Actions workflow executing multiple automated security jobs after a pull request merge.

Stage One: Secret Scanning with GitLeaks

One leaked API key can become a security incident.

Before the application is built, GitLeaks scans the repository for exposed secrets.

Examples include:

• AWS credentials
• API keys
• JWT signing secrets
• Database passwords
• SSH private keys

If sensitive information reaches a public repository, removing it later does not eliminate the risk because Git history preserves previous commits.

Detecting secrets before deployment prevents those mistakes from becoming incidents.

Stage Two: Static Application Security Testing

Once secrets are checked, SonarQube analyzes the source code itself.

Unlike Dynamic Application Security Testing, SAST does not execute the application.

Instead, it examines the source code for insecure patterns.

Examples include:

• SQL Injection
• Weak cryptography
• Hardcoded credentials
• Unsafe functions
• Security hotspots

The goal is simple.

Help developers fix vulnerabilities while they are still writing code instead of after deployment.

Figure 2. SonarQube identifying security hotspots and code quality issues during the CI pipeline.

Stage Three: Dependency and Container Scanning

Applications rarely consist entirely of custom code.

Open source libraries become part of the application's attack surface.

Trivy scans:

• Python dependencies
• Operating system packages
• Container images

The scanner compares installed components against known CVEs.

If vulnerable packages are discovered, they can be updated before deployment instead of becoming production vulnerabilities.

Stage Four: Infrastructure as Code Scanning

Application code is only one part of the deployment. Infrastructure can introduce security risks long before the application starts.

Checkov analyzes Infrastructure as Code configurations for issues such as:

• Public cloud resources
• Missing encryption
• Excessive IAM permissions
• Weak network configurations

This prevents infrastructure vulnerabilities from being deployed alongside secure application code.

Stage Five: Dynamic Application Security Testing

Static analysis identifies problems within source code. Some vulnerabilities only appear when the application is running.

OWASP ZAP performs Dynamic Application Security Testing against the deployed application.

Examples include:

• Cross Site Scripting
• Missing security headers
• Session management weaknesses
• Authentication issues

Combining static and dynamic testing provides broader coverage than either technique alone.

Figure 3. OWASP ZAP security scan highlighting application findings during automated testing.

Security Gates

Running scanners is only part of the solution.

The pipeline also decides whether deployment should continue.

Security gates evaluate scan results before images are pushed to the container registry.

Critical vulnerabilities stop the pipeline.

Lower severity findings generate warnings for developer review. This transforms security from passive reporting into active enforcement.

Software Supply Chain Security

Passing security scans does not guarantee software integrity. The pipeline therefore performs additional supply chain checks.

SBOM Generation

An SBOM creates a complete inventory of software components included in the application.

When new vulnerabilities are published, the SBOM makes it easier to determine whether the application is affected.

Image Signing with Cosign

Before deployment, container images are digitally signed.

This allows deployment systems to verify that images are authentic and have not been modified after they were built. These controls strengthen trust throughout the software delivery process.

Figure 4. SBOM generation and successful container image signing before deployment.

Deploying with Confidence

Only after every security stage completes successfully does the pipeline proceed with deployment.

Container images are pushed to Amazon Elastic Container Registry before being deployed to Amazon Elastic Kubernetes Service.

This approach reduces the likelihood of vulnerable software reaching production while giving developers immediate feedback whenever problems are introduced.

Lessons Learned

Implementing this pipeline reinforced several important lessons. Security is most effective when it is automated.

No single scanner provides complete protection. Different tools address different categories of risk.

Most importantly, CI/CD pipelines should not simply automate deployment. They should automate confidence. Every successful pipeline execution should increase trust that the software is ready for production.

Conclusion

A DevSecOps pipeline is more than a sequence of security scanners.

It is a collection of automated controls working together to reduce risk before software reaches production.

Threat modeling identified the risks.

The CI/CD pipeline implemented the controls.

Runtime monitoring validates those controls after deployment.

Together, they demonstrate that security is not a single stage within software development.

It is an ongoing process embedded throughout the entire lifecycle.

Resources

• Part 1: Shift Left, Verify Right: Building Security That Doesn't Slow Down Development
• Part 2: Implementing "Shift Left, Verify Right" in a Vulnerable FinTech Microservices Application
• Part 3: Threat Modeling a FinTech Microservices Application: Where DevSecOps Really Begins
• GitHub Repository: https://github.com/Lhilove/SecureFlow-DevSecOps