Cloud & DevOps Security Engineer
Policy-as-code across two clouds
I author and maintain CSPM, infrastructure-as-code, and secret-detection policies in Wiz across AWS and GCP. When the security architecture team defines a requirement, I write the Rego that enforces it, on AWS and GCP resources alike. Resource tagging compliance is one example, but the scope is whatever the standard calls for.
Policies ship with inputs that should pass and inputs that should fail. When a false positive does land, the end user is encouraged to go through the exception route while we work out whether the policy itself needs adjusting.
Secure pipeline templates
I build and maintain reusable Harness CI/CD pipeline templates with SBOM generation, Wiz IaC scanning, and secrets detection embedded as step groups. Teams adopt a template and pass in their own values instead of reimplementing the controls, so a fix or a new check propagates centrally rather than needing dozens of coordinated pull requests.
This is the part that genuinely shifts security left. When scanning lives inside the build, nobody has to remember it, and nobody has to be talked into it.
Compliance you can actually see
I track enterprise-wide pipeline compliance across hundreds of teams through a centralized dashboard, surfacing non-compliant implementations and driving remediation. Coverage that is assumed is not coverage. Without a number in front of you, "most teams scan their builds" is just a guess with no actual confirmation.
Escalation point and reviews
I serve as cloud security subject matter expert and primary escalation point for pipeline and security issues, supporting AWS IAM architecture reviews and security guardrail adoption across the organization. Most of this work is translation: explaining to a delivery team why a control exists, and explaining back to security why a control as written will not survive contact with a real pipeline.
Self-service IAM at scale
I build security guardrails directly into the platforms engineering teams already use. That means Harness CI/CD templates with secrets scanning and SBOM generation built in, and Wiz and Checkov policies that catch misconfigurations, including overly permissive IAM, before they reach production. Central review of every change does not scale across an enterprise, and when security becomes the bottleneck, teams find ways around it. Putting the guardrails in the tooling means the easy option is also the correct one.
Getting controls into production
I author the CAB documentation for security control implementations, through both standard and normal change paths, along with the business justifications and stakeholder communications behind each promotion from beta to production. In a regulated financial data environment that paperwork is not optional, but it is also genuinely useful: it forces a named owner, a rollback path, and a clear statement of what changes for whom.
Rollouts run detection before enforcement. False positives surface while they are still cheap, and the blast radius of a bad rule stays small. A control that breaks builds erodes trust faster than it reduces risk, and you only get to spend that trust once.
Exception automation in design
I am scoping an event-driven integration between a GRC platform's REST API and webhooks and our scanner exceptions repository, so an approved exception becomes an ignore rule without a manual pull request. The exception's identifier, scope, and expiry carry through as metadata.
The expiry is the part that matters most. A suppression with no end date is how a temporary exception silently becomes permanent policy, and today the records drift apart often enough that engineers get alerted about risk the business already formally accepted.