Security Portfolio
I build security into software
I’m an application and product security engineer with principal-level software engineering depth. I help teams turn risk into secure architecture, delivery guardrails, observable controls, and production-quality fixes.
This portfolio is organized around the security outcomes I am best equipped to lead.
Selected writing
Application and product security
A Practical Risk Model for Authorization shows how I frame subjects, actions, resources, negative tests, policy ownership, and resource-level enforcement as one engineering system.
Secure delivery and cloud security
Defining the Security Outcome for Software Supply Chain Security connects reviewed source, isolated builds, artifact verification, provenance, deployment policy, and incident evidence.
Threat detection and response
Defining the Security Outcome for Detection Engineering treats detections as production code with hypotheses, data contracts, tests, response ownership, and lifecycle decisions.
Security leadership
How I Would Lead a Security Engineering Team explains how I would align security analysts and developers around outcomes, decision rights, reusable systems, meaningful measures, and team growth.
My security engineering pillars
1. Application and product security
- Authentication, authorization, and session security
- Threat modeling, abuse cases, and trust-boundary analysis
- Secure architecture and security-focused code review
- Application-security verification and vulnerability remediation
- Ruby on Rails and API security
I treat an application-security review as a decision-making process. The output should be an explicit security behavior, an implementable design, a named owner, and verification evidence—not a generic list of concerns.
Explore application and product security writing.
2. Secure delivery and cloud security
- Secure SDLC and DevSecOps operating models
- CI/CD, SAST, DAST, SCA, secrets, and IaC guardrails
- Software supply-chain security, SBOMs, and build provenance
- AWS identity, network, data, and logging controls
- Security automation and secure platform paved roads
The strongest controls fit the delivery system teams already use. I focus on secure defaults, fast and specific feedback, accountable exceptions, and evidence that remains useful in production.
Explore secure delivery and cloud security writing.
3. Threat detection and response
- Threat research and hypothesis-driven hunting
- Detection engineering and security telemetry
- SIEM and network detection architecture
- Incident and forensic readiness
- Product security incident response
Detection and response experience sharpens product-security decisions. It changes which events applications emit, how identities and assets are correlated, how controls fail, and whether responders can contain exposure when assumptions break.
Explore threat detection and response writing.
How I lead the work
My default operating loop is:
- Frame the security decision. Identify the asset, plausible abuse path, consequence, constraints, and accountable owner.
- Design the control. Make trust, privilege, failure behavior, and tradeoffs explicit.
- Build the paved road. Turn recurring requirements into shared components, templates, policy, tests, and delivery feedback.
- Operate with evidence. Measure coverage, effectiveness, speed, sustainability, exceptions, and control health.
- Improve the system. Convert incidents, recurring findings, and team friction into architecture, guardrail, and capability improvements.
That loop is how I use software engineering as a force multiplier for cybersecurity. It also provides a common working model for security analysts, developers, product owners, and platform teams.
Roles aligned with this work
- Principal Application Security Engineer
- Principal Product Security Engineer
- Application or Product Security Architect
- Security Engineering Lead
- Secure Software Engineering Lead
- DevSecOps or Cloud Application Security Engineer
For credentials, professional history, and contact information, see About.