Security gates inside every pipeline, not after them

This practice has been delivered across engagements in banking, financial services, manufacturing and retail. Each engagement started from the same request: release more often without letting security and quality review fall behind, and give teams one automated path for provisioning infrastructure and deploying applications, rather than a path that differs from team to team.

The work runs in three parts: an assessment of the current delivery process, the design of a DevSecOps process that places each control deliberately, and the implementation of that process as working pipelines. SonarQube for code quality, Katalon for automated testing, Terraform for infrastructure as code, and Kubernetes manifests with Helm for complex deployments are common to the engagements.

Pipelines were shipping faster than security review could keep up with. Scanning that happens after a build is a report; scanning that happens during one is a gate, and only the second changes what reaches production. Findings delivered at the end of a release also arrive at the point where they are most expensive to fix and easiest to waive.

The decision was where each control should live and who should own its result. A failed dependency scan, a failed quality gate and an image vulnerability each need a different team's judgement. A pipeline that reports every failure to everyone ends up owned by no one, so routing mattered as much as scanning. The branching model also had to give vendor teams their own development line without splitting the release history on main.

A developer lead initialises each project in GitLab and approves every merge request. Changes on the develop, release and hotfix branches trigger the SIT and UAT pipelines. Continuous integration runs in a fixed order: unit tests, software composition analysis (SCA), static application security testing (SAST), a SonarQube quality scan, the image build, a push to the container registry and an image scan. Cheaper checks run first, so an expensive build is never spent on code that fails a unit test.

Every gate that fails raises a Jira ticket and sends email and Microsoft Teams notifications to the team that owns the check, whether that is development, QA or security. In the quality and security check lane, the QA team reviews the quality gates alongside manual and automation testing, and the security team reviews the SCA, SAST, DAST and image-scan results.

Continuous deployment follows GitOps. For SIT, Jenkins triggers Argo CD, which releases the new image to Google Kubernetes Engine (GKE). UAT adds a QA approval before the Argo CD release, followed by automation testing with Katalon, performance testing with JMeter and dynamic application security testing (DAST) against the running application. Secrets are issued from HashiCorp Vault rather than stored in the repository or the pipeline definition.

Production is deliberately slower. The developer lead triggers the pipeline, and the release needs approval from the developer lead, the QA lead and the security team, whose sign-off follows a penetration test. The image already tested in UAT is retagged rather than rebuilt, approved for release and deployed by Argo CD to GKE, so what reaches production is the same artefact that passed every earlier gate.

The platform is designed to let teams release more often without letting security and quality review fall behind. Because checks run inside the pipeline and every failure reaches its owner as a ticket, it aims to improve development velocity and code quality while strengthening security, and to give teams faster and more reliable releases than a review held at the end.

The intent is a fully automated delivery path, from merge request to a GitOps-managed production cluster, that supports rapid iteration and continuous improvement. It is designed to let development teams concentrate on delivering value, with the security and quality evidence for each release produced by the pipeline itself rather than assembled afterwards.