Security in the pipeline. Not a review at the end.
We put the controls where the work already happens — in the pull request and the build — so security stops being the review at the end and starts being a property of the pipeline, on every project we run.
- Where it runs
- Every pull request, every build, every deploy
- Rollout
- Pipeline review → warn-only scanning → staged gates
- Core stack
- Semgrep · Trivy · OWASP ZAP · Vault · OPA
- Evidence
- Scan results, approvals and deployment records, retained automatically
What sits behind the claim
The practices below come as standard, whether the project is a website or an enterprise platform.
- Static analysis on every pull request. Semgrep findings surface as review comments where the developer already is, with project-specific rules for your own conventions — the authorisation helper that must wrap a handler, the raw SQL that must never appear.
- Dependency and container scanning. Trivy checks libraries, base images and infrastructure code on every build, and again on a schedule against what is already deployed, because a CVE disclosed after your last release still applies.
- Dynamic testing against staging. OWASP ZAP scans a running deployment with an authenticated session, catching the session and configuration flaws that source analysis cannot see.
- Secrets kept out of the code. Credentials issued from Vault as short-lived, logged and rotated, with pre-commit and history scanning so they never land in the repository in the first place.
- Least-privilege access. Scoped, short-lived runner credentials, pinned third-party actions, and a build that cannot be pushed to production from an unreviewed branch. Over-broad IAM is the first thing we look for.
- Policy as code. Security and infrastructure rules written as executable policy, so a non-compliant change fails a build instead of being caught in review — or not at all.
- Cloud configuration checks. Infrastructure as code scanned before it is applied, so a public bucket or an open security group fails a plan instead of becoming an exposure.
- An audit trail behind every change. Scan results, approvals, deployment records and secret-issuance logs kept as they happen, which turns an audit from an archaeology project into a query.
How it works in an engagement
Staged so it protects the release without stopping it.
It starts with a pipeline review
A short review establishes where controls are missing and, just as importantly, where existing gates are being routinely bypassed — a scanner nobody reads, a gate everyone knows how to skip. On new work, scanning goes into the pipeline the same week the pipeline is built.
Warn first, then gate
Scanning goes in on a warn-only basis so the team can clear the existing backlog before anything blocks a merge. Gates then tighten stage by stage at agreed severity thresholds, and nothing is bypassable without a recorded exception.
Every finding has an owner
Findings are deduplicated across tools, triaged against your actual exposure, and given an owner and a remediation window. Rules are tuned as the codebase moves, because a scanner that is never tuned becomes noise, and noise is indistinguishable from no control at all.
Security decided at design time
The same thinking goes into what we build. RelayZap handles other organisations' mail, so it is envelope-encrypted at rest, isolated between tenants and self-hosted so credentials never leave the client's infrastructure. Niyantā carries maker-checker controls and automated audit trails.
A vulnerability caught by a pull-request check costs a developer twenty minutes. Found in a client's penetration test, it costs a release cycle.
That is the whole commercial argument for building security into the pipeline rather than reviewing it at the end. The full service — application security, vulnerability management, secure CI/CD and cloud security — is described on the DevSecOps page.
Questions we are asked
What is the difference between this and a penetration test?
A penetration test measures one build on one day. Security in the pipeline changes the process that produced it — checks on every pull request, findings with owners and remediation windows, and a pipeline that will not deploy around them. Most clients need both; only one of them compounds.
Will security scanning slow our releases down?
Not if it is staged. Scanning starts warn-only so the existing backlog can be cleared without blocking anyone, then gates tighten at agreed severity thresholds. Scans run in parallel with the rest of the build.
Does it cover our existing infrastructure, or only new work?
Both. Infrastructure as code is scanned before it is applied, and what is already deployed is re-scanned on a schedule, because configuration drifts and advisories are published after your last release. The first pass on an existing estate usually finds IAM breadth and forgotten open ports.
Does this produce the evidence an ISO 27001 or SOC 2 assessment needs?
Most of it, as a by-product: scan results, approvals, deployment records and secret-issuance logs retained automatically. Pairing it with compliance work is the usual route — the certificate itself is issued by an accredited body, never by us.