Security checks in the pipeline, tuned to real risk
A security review at the end of delivery comes too late to change much and turns into a queue. Scans and policy checks on every change give fast feedback, provided each gate blocks real risk.
The traditional security review at the end of delivery has two failure modes: it is too late to change anything cheaply, and it is a queue. Shifting security left means moving those checks into the pipeline, where they run on every change, give feedback in minutes, and block nothing that was not going to be a problem anyway.
Scan the things that actually break
- Dependencies, for known vulnerabilities and license issues.
- Infrastructure code, for misconfiguration before it is deployed.
- Secrets, so a leaked credential never reaches the default branch.
- Block on commit, not just on merge — by merge it is already in history.
Policy as code, checked in the pipeline
Infrastructure misconfiguration is the category most cheaply caught before deployment. A policy-as-code scanner runs against the plan and fails the build on a violation:
# Fail the pipeline if the Terraform plan violates policy.
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
conftest test plan.json --policy ./policyTune for signal or lose the room
A scanner that reports two hundred findings, most of them irrelevant, trains the team to ignore all of them. Start with a small set of high-confidence rules that block, keep the rest as advisory, and earn the right to add more. A gate is only as valuable as it is trusted.
Done this way, security stops being the thing that happens to a release at the end and becomes a property the pipeline maintains continuously — faster for the team, and stronger for the organisation.
NinetyX DevSecOps Practice
DevSecOps & Delivery
Engineers who put security and quality checks inside the delivery pipeline as gates. They write about keeping releases fast while every control stays in the path.
Where to next
Put the security checks inside your pipeline
We set up CI/CD pipelines where scans, policy checks and release evidence run as gates on every change, defined in your repositories and owned by your team.
See the DevSecOps servicesRelated articles
A slow pipeline is one engineers route around
When builds are slow, flaky or hard to read, engineers merge around them and the controls go with them. Run the pipeline as a production system: fast first, then correct, with failures anyone can read.
NinetyX DevSecOps Practice · · 2 min read
Landing zones that make the secure path the easy one
A landing zone is the governed environment every new workload is deployed into. Enforce it with policy rather than review and version all of it, and teams will build on it instead of around it.
NinetyX Cloud Practice · · 2 min read
Laying out a Microsoft Fabric lakehouse for analytics
Fabric puts the lake, the warehouse and Power BI on one storage layer. That only simplifies things if medallion layers, workspace ownership and Direct Lake models are settled before the first load.
NinetyX Data & AI Practice · · 3 min read