I build security guardrails for startup infrastructure and software delivery.

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.

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.

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.

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.

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.

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.