AP

DevSecOps • Cloud security • Compliance

Security guardrails that let startups ship.

7+ years owning security and compliance in DevSecOps roles. I take backlogs of critical findings to zero, carry SOC 2 programs through to the final report, and remove seven figures of cloud spend, by building the permission boundaries, pre-merge checks and operating processes that make it stick.

Discuss a role or engagement See the work

Open to full-time, fractional, advisory, and startup security leadership opportunities.

~1,950 critical and high findings closed in two weeks Measured in Datadog
45 → 95% SOC 2 readiness within six months Measured in Drata
$85K / mo secrets platform savings after hosting costs Vault on AKS
$1M+ cloud and tooling spend removed Across two environments

01 • Selected work

What I accomplished, how it was measured, and what I did.

Every entry follows the same shape: the outcome, the measure, the work. Client names and sensitive implementation details are omitted.

01 — Secrets infrastructure · AKS

One source of truth for secrets, $85K cheaper every month.

Cut secrets-platform spend by $85,000 a month, measured after hosting costs, by consolidating Azure DevOps, GitHub, Azure Key Vault and Vault Enterprise into self-hosted Vault on AKS, with Terraform-managed identities, private endpoints, New Relic alerting and tested restores.

$85Ksaved monthly, after hosting costs
Read the case study

The consolidation

Secrets were spread across Azure DevOps, GitHub, Azure Key Vault, and HashiCorp Vault Enterprise. I migrated them into self-hosted Vault as a single source of truth and integrated all services with the new platform.

Identity and network controls

I used dedicated service principals managed through Terraform for authentication, with private endpoints restricting network access to the platform.

Monitoring and detection

Audit events were sent to New Relic. I configured monitoring and alerts for unauthenticated access attempts, unused secrets, and unused identities.

Backups and recovery

Regular backups were stored in Azure Blob Storage accessed through a private endpoint. We tested restoration from multiple backups to verify recovery.

The result

The migration consolidated secrets and service integrations on one platform, with monitoring and tested recovery. Savings were $85,000 per month after hosting costs.

02 — Security program · Kojo

Took Kojo from 45% to 95% SOC 2 readiness in six months.

Raised SOC 2 readiness from 45% to 95% within six months and carried the audit through to a final Type II report in August 2026, measured in Drata and by the issued report, by building the technical controls, device compliance, evidence processes and training as the sole internal security owner.

45 → 95%Drata readiness, six months
Read the case study

My ownership

I joined in late September 2025 and owned the security program, partnering with engineering, IT stakeholders, and independent auditors. I implemented fixes directly and escalated changes requiring product or engineering ownership to the responsible managers.

Controls that operated in practice

I built infrastructure controls and automation to detect changes to them, updated policies to reflect actual practices, completed device enrollment in MDM, enforced device compliance, strengthened AWS least-privilege access, and implemented security training for users.

Evidence and remediation

I established evidence-collection processes and human code-review requirements, coordinated penetration testing and remediation, and worked with auditors to identify and close gaps before the audit.

The timeline and result

Drata readiness increased from 45% to 95% within six months. This was the platform’s readiness metric, not an auditor-issued compliance score. The Type II observation period ran from January 1 to March 31, 2026, and the final report was issued in August 2026.

03 — Vulnerability remediation

Two weeks from ~1,950 open critical and high findings to zero.

Brought open critical and high-severity findings from roughly 1,950 to zero in two weeks, as shown in Datadog, by personally upgrading dependencies and removing unused code across repositories, grouped into consolidated pull requests with code-owner approval. Eighteen upstream findings without a fixed version were suppressed for 30 days and tracked as exceptions, not fixes.

0 opencritical or high findings after 14 days
Read the case study

The workload

Datadog displayed the backlog as a rounded 1.95k findings, with approximately 480 rated critical and the remainder high. These were not duplicates. Another 26 findings arrived during the final week, so the reported volume is approximate rather than an exact count of code fixes.

My implementation

I personally made the code changes, upgrading dependencies and removing unused code. I grouped fixes into consolidated pull requests by repository and severity, reducing review requests from hundreds to tens per repository while retaining code-owner approval for every change.

Testing and review

I verified feature behavior through local deployments. Claude assisted with running CI tests locally, checking repository code-quality guidelines, and managing Jira tickets. Code owners reviewed and approved the changes before merging.

Time-bound exceptions

Eighteen findings involved upstream libraries without fixed versions. These were suppressed for 30 days and required monthly reassessment. They were tracked as exceptions, not counted as code fixes.

The verified outcome

After the changes, Datadog showed zero open critical or high-severity findings. That dashboard state included the 18 temporary suppressions; it does not mean every finding had an available patch or that the systems were free of vulnerabilities.

04 — Software delivery security

Risk review became a required merge check.

Stopped high and critical-risk changes from merging through the normal workflow, enforced as a required CI status check, by building a review bot that classifies each change’s risk and assesses the guardrails it touches. Warnings notify the reviewer; destructive permission requests are blocked and code owners are notified.

RequiredCI status check on every merge
Read the case study

The enforcement

I defined the blocking criteria for a required CI check. High and critical classifications fail the check and prevent merging through the normal workflow. Warnings pass but notify the reviewer; green results pass. Destructive permission requests are blocked and code owners are notified.

The exception path

After identifying a gap in the check, we updated it to accept exceptions requested by repository admins with explicit resource and time restrictions. Ordinary requesters cannot authorize those exceptions. Policy conditions enforce the permission time limit.

The boundary of the control

The required check enforces the classifier’s risk status. It does not independently prove the classifier’s assessment is correct. Human review remains part of the merge process.

05 — Application authorization

Applications lost the schema privileges they never needed.

Separated application data access from schema administration, enforced through distinct RDS grants and identities, by reserving schema changes for a dedicated GitHub Actions identity and splitting the configuration across separate repositories and OpenTofu workspaces. Backups and secondary databases became read-only.

Splitdata access vs. schema changes
Read the case study

The boundary

For RDS, I implemented database grants that allow application identities to read and write primary database data while reserving schema alterations for a dedicated GitHub Actions identity. Access to backups and secondary databases was limited to read-only.

The implementation

The configurations are managed in separate repositories and OpenTofu workspaces to reduce accidental changes across that boundary. Schema changes run through the delivery workflow so their history can be tracked.

My role

I originally implemented these permission changes myself. I now use Claude Cowork to automate changes, with human review required before merging. Related reviews caught application access that could write secrets when only read access was needed, and database credentials embedded in application code before production.

The result

Application data access and schema administration use separate identities and privileges. Database grants enforce the RDS query and schema boundary; AWS permissions govern infrastructure access.

06 — Incident access

Incident access scoped to one queue, for a limited time.

Unblocked a stuck-queue incident without granting standing delete rights, recorded as a documented, policy-enforced time limit on a single queue, by having the administrator scope their bypass authority to the affected resource instead of widening permanent access.

1 queuetime-boxed by policy conditions
Read the case study

The response

An administrator used their bypass authority to enable the incident action. The permission was scoped exclusively to the affected queue and limited in time through policy conditions, rather than becoming permanent access.

The audit record

The event was documented for auditability. This was a separate incident from the repository-admin exception path described in the CI case study.

The wider practice

My AWS IAM work includes risk classification and periodic permission reviews for indirect escalation paths. I use account-level SCPs to restrict sensitive AWS actions and privileged access across environments that include RDS and DynamoDB.

07 — Cloud efficiency

Seven figures of cloud and tooling spend removed.

Reduced cloud and tooling costs by more than $1M across two environments, by rightsizing, restructuring infrastructure, automating operations and choosing open-source replacements where they fit, without trading away security or reliability.

$1M+across two environments

02 • How I work

Security should create guardrails that help teams ship, not gates that make them wait.

  1. 01

    Automate the controls

    Permission boundaries, pre-merge risk checks and drift detection enforce the policy, so it holds without a review queue.

  2. 02

    Make ownership clear

    I fix what I can fix directly. Changes that need product or engineering ownership go to the responsible managers, not a ticket backlog.

  3. 03

    Embed champions

    Security champions across the business carry the program further than one owner can, and keep it running when priorities shift.

  4. 04

    Keep human judgment

    A required check enforces a classifier’s verdict; it does not prove it right. Human review stays in the merge path where it matters.

03 • Ways I can help

One owner across the seams.

For startups that need governance and implementation to move as one system, whether that is a full-time hire, a fractional lead or a focused engagement.

01

Security program and compliance foundations

Security strategy, control design, risk management, SOC 2, PCI DSS, and ISO 27001 readiness and program ownership, audit coordination, customer assurance, incident response, and security champion programs.

02

AI security and governance

Authorization boundaries, interaction logging, monitoring, human review points, AI tool governance, and controls based on NIST AI RMF and the OWASP LLM Top 10.

03

Cloud and platform security

Secure AWS and Azure architecture, Kubernetes, Terraform, identity, networking, DevSecOps, CI/CD security, secrets management, and production guardrails.

04

IT systems, identity, and device management

SSO and IAM, device management, endpoint protection, SaaS administration, access reviews, and automated onboarding and offboarding.

05

Vulnerability management and security automation

Risk-based prioritization, remediation workflows, dependency automation, secure code review, detection engineering, and human-reviewed agentic workflows.

04 • Writing

Field notes from building the function.

Practical writing about security leadership, cloud infrastructure, AI governance, automation, and the decisions behind the systems.

Read all articles
  1. · 3 min readType 1 or Type 2? The SOC 2 Decision Nobody Explains Properly
  2. · 4 min readAI Writes Fast. Compliance Moves Slow. Somebody Has to Own the Gap.
  3. · 8 min readBreaking AI Agents: What a Vendor Chatbot Told Me It Shouldn’t Have - Part 01: Recon

05 • Contact

Your first security leader, or your next security partner.

Hiring a security leader or looking for hands-on help? Let’s talk about your team, your priorities, and what needs to happen next.

For hiring teams

Hands-on security engineering and leadership across cloud infrastructure, software delivery, and compliance, with additional IT management experience.

For founders and teams

Fractional leadership, advisory work, and focused implementation engagements to build your foundations or close a specific gap.

Connect on LinkedIn GitHub