DevSecOps · Security integration
Security checks that stop a release, not report on it
We place each security check where it changes what reaches production. Dependency and code scans run on every merge request, image scans before promotion, and DAST in UAT. A penetration test precedes release, and every finding goes to a named owner.
The problem
Where this usually breaks down
Scans that only produce reports
A scanner that runs beside the pipeline produces a report, and the release goes ahead while someone reads it. Nothing it finds can stop the change it describes.
Findings nobody is accountable for
Dependency alerts, code findings and image vulnerabilities land in one shared dashboard. Each needs a different team’s judgement, so without routing they are skimmed and then ignored.
Secrets scattered across tools
Tokens and passwords sit in pipeline credentials, values files and old commits. Each copy is another place to rotate after an incident, and another place an attacker can read.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
SCA and SAST on every merge request
Software composition analysis checks dependencies and licences, and static application security testing checks the code, on every merge request. Both fail the pipeline above agreed thresholds and send their findings to the security team’s queue.
A quality gate that is enforced
The SonarQube quality gate runs alongside the security scans and blocks a merge when new code falls below the agreed rules. QA owns the gate definition, so changing a threshold is a decision, not a quiet edit.
Image scanning before promotion
Each image is scanned after it is built and before anything promotes it from the registry. Base images come from an approved set, so a vulnerable layer is fixed once rather than in every service.
DAST in UAT, penetration testing before release
Dynamic application security testing runs against the application deployed in UAT, alongside automation and performance tests. Production waits for security sign-off after a penetration test, together with approval from the developer lead and QA lead.
Every finding routed to one owner
A failed gate opens a Jira ticket for the team that owns it and notifies that team in Microsoft Teams. Development, QA and security each see their own findings in the queue they already work from.
Secrets issued from HashiCorp Vault
Pipelines and workloads receive secrets from HashiCorp Vault at the moment they need them. Nothing sensitive is stored in the repository or the pipeline definition, and rotation happens in one place.
Reference architecture
The architecture as it was delivered
Figures from published engagements, reproduced unchanged. Open any figure full size, or read the write-up it comes from.
- Read the write-up: Security gates inside every pipeline, not after them
Figure 1 — End-to-end pipeline: every stage is a gate, and a failed check becomes a ticket for the owning team rather than a report at the end.
Open full-size image: Figure 1 — End-to-end pipeline: every stage is a gate, and a failed check becomes a ticket for the owning team rather than a report at the end.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
A security gate register
Each security gate with its tool, threshold, owning team and the named people who may approve an exception, reviewed whenever a gate changes.
Scanner configuration in your pipelines
The SCA, SAST, image scan and DAST stages as code in your shared pipeline library, with rule sets and suppressions versioned beside them.
Finding routing and triage guides
The Jira projects and Microsoft Teams channels each gate reports to, and a short triage guide per finding type for the team that receives it.
Vault policies and a secret inventory
HashiCorp Vault policies for pipelines and workloads, an inventory of the secrets taken out of repositories, and a rotation runbook.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Assess the current controls
We review which security checks exist today, where they run, who reads the results and what happens to a finding. Secrets in repositories and pipeline settings are inventoried in the same pass.
02
Place each control and owner
Together with your security and QA leads, we decide where each check belongs, what threshold fails it, who owns the result and who may approve an exception.
03
Start gates in report mode
New gates run in report mode on one service first, so thresholds are tuned against real findings. Once the noise is understood, each gate is switched to fail the pipeline.
04
Enforce and hand over
Gates are enforced across the remaining services in batches, and secrets move into HashiCorp Vault. Your teams keep the register, the configuration and the triage guides, and run them without us.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Run in production
- GitLab
- Jenkins
- SonarQube
- HashiCorp Vault
- Jira
- Microsoft Teams
Evidence
Published work behind this service
Each statement below points to a write-up you can read in full, with the architecture and the stack as they were delivered.
For a DevSecOps platform, we placed SCA, SAST, image scanning and DAST as pipeline gates, with QA and security reviewing results and security signing off after a penetration test.
Questions
What teams ask before we start
We already license security scanners. Will you replace them?
Not unless there is a gap. Most organisations own capable tools that run outside the pipeline. We move them inside it as gates, agree thresholds with your security team and route their findings, which usually matters more than the choice of tool.
Will failing builds on security findings stop our teams shipping?
Not if the gates are introduced carefully. Each one starts in report mode, thresholds are tuned against real findings, and only then does it fail the pipeline. A documented exception route covers the rare release that must ship with a known finding.
Who decides whether a finding can be accepted?
The owner named in the gate register, usually your security team for scan results and QA for quality gates. An accepted finding stays open as a ticket with its reason and a review date, so the decision stays visible later.
Does this replace penetration testing?
No. Automated gates catch known classes of issue early and consistently, while a penetration test examines the running system the way an attacker would. We place the penetration test before production sign-off, where its findings still gate the release.
What access do you need to our pipelines and secrets?
Read access to repositories and pipeline configuration for the assessment. For the build, we propose changes as merge requests, and your administrators apply the HashiCorp Vault policies. We never need to hold your production secrets ourselves.
Related services
What teams often need alongside this
CI/CD pipelines with enforced gates
Pipelines that run unit tests, SCA, SAST, quality and image scans in cost order, and send every failed gate to the team that owns it.
Cloud-native DevOps on Kubernetes
One image built per change, Helm charts per service, and a GitOps controller that promotes it from SIT to UAT to PROD on Kubernetes.
Infrastructure as code with Terraform
Terraform modules, a plan reviewed on every merge request, applies only from the pipeline, and drift reported before it becomes an incident.
Next step
Review your pipeline security with us
Tell us which security checks run today and where their findings go. We will suggest which gates to add first and who should own each one.