- Security is a review stage near the end, so every significant change turns into a negotiation.
- The pipeline works, but nobody can say which image was deployed from which commit, or whether it was scanned.
- A policy platform exists and the teams route around it, because it slows delivery down more than it protects it.
- Secrets are handled differently in every repository, and one of those ways is a spreadsheet.
Service
Secure delivery and DevSecOps uplift
I move the security controls into the delivery path, so a normal change passes without a meeting and an unusual one fails loudly.
When teams call
The situation this fits
Security work usually arrives as a date or an audit finding.
How the work runs
Three phases, overlapping
The first phase is reading. Most of the delay in this work comes from fixing things nobody needed fixed.
-
01
Map the actual path
I trace what happens between a commit and a running system: which pipeline builds it, who can approve what, where secrets enter, and which controls fire when. The written result usually shows two or three choke points and a set of checks nobody knew existed.
-
02
Move the controls left
Policy becomes code with tests, admission control enforces what matters, and supply-chain checks run where the artefact is built rather than after it is deployed. The goal is that a normal change passes without anyone signing anything.
-
03
Prove it under change
I ship a real change through the new path while you watch, including the unglamorous parts: rollback, an exception that has to be granted, and what happens when a check blocks a deployment.
Deliverables
What you are left with
Things that keep working when I am not in the room.
- A policy bundle with tests, in OPA and Rego, wired into the pipeline and the cluster.
- Supply-chain checks at build time: image hashes, vulnerability scans, and a bill of materials stored next to the code.
- Secret handling that fits your constraints, whether that is Vault, age with SSH keys, or something in between.
- Admission and policy enforcement in the cluster, with an exception process that does not require a ticket queue.
- An authorisation model where that is the gap: policy decision points, enforcement points, and decision logging.
- A runbook for the failure modes: what to do when a control blocks a release, and who can override it.
Engagement shapes
Three ways to bring it in
An audit finding reads better as a fixed piece of work than as an open-ended programme.
Short assessment
Two to three weeks. I read the pipelines and the cluster, then deliver a written account of where the controls sit and what to fix first.
Delivery-flow uplift
Part-time over two to four months. I build the pipeline, policy and supply-chain changes with your platform team, one slice at a time.
Rescue
Full-time through a stalled programme. A policy platform or delivery pipeline that has stopped moving, with a date that matters.
Evidence
What it looks like in practice
One anonymized reference from recent work.
Case study
Insurance: a global authorization platform for 320,000 users
Questions
Before a first conversation
The three questions I get asked first.
Do we need an OPA platform to work with you?
No. The useful part is the discipline: controls that live in code, get tested, and fail loudly. If your gap is Kubernetes admission policy, that is Kyverno or OPA; if it is secrets, it may be neither.
Will this slow delivery down?
The first version usually does, for a few weeks. The target state is the opposite: normal changes pass without manual approval because the checks run automatically and the exceptions are explicit.
Can you work with a platform that is already half-built?
Most engagements start that way. I would rather finish and stabilise what exists than replace it, and the assessment says plainly which parts are worth keeping.
Start the conversation
Describe the delivery path as it works today
A short note with the context, the constraint and the timing is enough for me to say whether this is the right engagement.