Day job · sanitized
Cloud security, at scale
Case studies from cloud security work at a Fortune 500 insurer. Sanitized: no employer name, and no environment details beyond the tool names.
- 1,100+
- GCP projects governed
- 46
- controls mapped
- 8
- service entries triaged
- minutes
- exposure window, was hours
Container supply chain
Unapproved, unhardened images were making their way toward production, with no gate to stop them. I coordinated between vendors and internal teams and stood up a formal image approval process, so images are vetted before they can ship rather than caught afterward. The gap got closed at the source instead of being patched downstream every time it recurred.
Cloud asset governance
Every cell below is one GCP project that existed with no reliable link to the business application it belonged to. Not a rounding error, not a backlog: this is the estate. A finding on any one of them had nowhere to route, because nothing recorded who owned it.
The eight lighter cells are Technical Service entries that did not exist and had to be created before their projects had anything to point at. This is the least glamorous work I have ever done and it is the reason the timeline further down reads two days instead of three weeks: a finding cannot route to an owner that was never written down.
SOAR proof of concept
A cloud vulnerability alert arrives knowing almost nothing: something is wrong, somewhere, in a project named after a number. Everything that makes it actionable — who owns it, how bad it is, whether we already know — is research a human does before the real work starts. So I evaluated no-code automation platforms (Torq, Tines) and built workflows that do the research on arrival, then took the results to leadership with an adoption roadmap.
Fire one and watch the right-hand side. The graph is the boring half; the argument is the payload getting fatter at every hop.
what it cost
the alert, as it travels
Both runs end with the identical payload, deliberately. The workflow does nothing an analyst couldn't do by hand — it does it in seconds, at 3am, for every alert, without getting bored, and it never mistypes the project id. Note the second step: it can only resolve an owner because of the mapping work above it. Automation cannot look up a fact nobody wrote down. Illustrative timings and a redacted resource; the shape of the workflow is the real one.
Prevention over reaction
CSPM findings (Wiz) told us what was already misconfigured, which is useful but always after the fact. I turned recurring findings into GCP Organization Policy constraints that block the risky configurations before they can be created, and automated the weekly metrics reporting that used to take hours down to minutes. Less cleanup, fewer bad configs reaching the environment at all.
Two levers decide how much a single bad config costs you. Try to deploy one and watch the exposure window change.
One fixed three-week scale for every scenario, so the bars are actually comparable instead of each being rescaled to look the same size. Timings are illustrative; the mechanics are real. The constraint evaluates at creation, which is why the prevented case has no bar at all rather than a short one.
what it demonstrates
Cloud governance at scale, security automation, and a bias toward prevention: closing gaps at the source and turning findings into policy instead of an endless ticket queue.