What the engagement covers
Most teams can name their security tools. Far fewer can say who owns which control
The tooling is rarely the hard part. The hard part is deciding, before the first sprint, which role signs off a container image before it reaches production — developer, platform engineer or cluster operator. That is the argument this work settles.
Policy gates in the pipeline
Automated OPA and Conftest checks on Terraform plans, Kubernetes manifests and container images, so a non-compliant change fails the build rather than the audit.
Image scanning and provenance
Trivy, Snyk and registry scanning wired into the build, with a documented path for what happens when something fails at two in the morning.
Identity and secrets
Least-privilege IAM, managed identities, and secret handling pulled out of application code into Vault, Key Vault or Secrets Manager.
Control ownership model
A written map of controls to roles, built for the three audiences who each assume someone else has it covered: developers, platform engineers and cluster operators.
Compliance boundaries
Designed for estates where the security review decides whether the workload ships at all — banking, insurance and healthcare being the usual three.
Audit evidence
The artifacts a reviewer asks for, generated by the pipeline rather than assembled by hand the week before.
- Microsoft Azure
- Amazon Web Services
- Red Hat OpenShift
- Kubernetes
- Docker
- Jenkins
Where this shows up in the work
Three of the twenty-one were built security-first, where the posture was the requirement rather than an afterthought.
Common questions
We already have scanning tools. What would you add?
Usually ownership rather than tooling. Scanners produce findings; what is normally missing is who triages them, what threshold blocks a release, and which role has authority to accept a risk. That decision set is the deliverable.
Will this slow our releases down?
It should not, and if it does the gates are in the wrong place. Policy checks belong on the plan and the manifest, where they run in seconds, not on a human review queue. The aim is that a non-compliant change never reaches the queue.
Do you work inside regulated environments?
Yes. Most of this work has been for estates inside a compliance boundary — banking and insurance most often, and one healthcare platform where the data could not leave the building.
Can you work with our existing pipeline?
Azure DevOps, GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines and OpenShift Pipelines are all in scope. Replacing a working pipeline is rarely the right first move.
Other things I'm brought in for
Most engagements touch more than one of these.
Bring me the control nobody owns.
Thirty minutes is usually enough to tell whether your problem is tooling, ownership, or a gate in the wrong place.