“`html
Background
I started in security as a penetration tester. That meant spending my days finding ways into systems, writing up the findings, and handing them to teams who then had to figure out what to actually do about it. It was useful work, but I kept noticing the same problem: the gap between “here’s the vulnerability” and “here’s how you fix it at the engineering level, in your specific stack, without breaking your release schedule” was where most security programs fell apart. That pulled me into AppSec engineering, where I was on the other side — embedded in development processes, building tooling, and trying to make security something teams could actually act on.
From there I moved into a security engineering manager role at a fintech company, which I held for four years. Managing a security engineering function inside a financial services organization teaches you things no certification does. You learn that the hardest part of application security is rarely the technical problem — it’s the organizational one. Prioritization fights, developer adoption, alert fatigue, the slow erosion of program quality when security gets treated as a compliance checkbox. I ran into all of it, and I learned what actually moves the needle versus what looks good in a board presentation.
I went independent because I wanted to write the security resource I kept looking for and not finding. Almost everything out there is either vendor content dressed up as education or high-level strategy written for people who aren’t doing the technical work. I built BuildSecOps for the engineers and practitioners who are the ones actually doing it.
What I Cover on BuildSecOps
Every post on this site is written with one question in mind: can a security engineer or security-conscious developer use this in their next sprint? Not eventually — next sprint. That means real code examples in real languages and frameworks, specific tool recommendations with honest notes on setup complexity, and postmortem-style breakdowns of actual breaches when the documentation is public. I reference CVE records, NIST publications, and OWASP resources by name because that’s how practitioners work. I’m opinionated about tooling — I’ll tell you what I’d actually use and why, not give you a vendor-neutral list of options that helps no one. And I cover the organizational and process side of security alongside the technical, because that’s where programs fail in practice.
What I won’t write: threat hype with no actionable takeaway, content hedged so carefully it recommends nothing, or summaries aimed at executives who want a slide deck. If you can’t read code, some of this will be a rough ride. That’s intentional.
Credentials & Experience
- 13 years in application security
- Started career as a penetration tester
- Worked as an AppSec engineer, embedded in software development processes and security tooling
- Four years as a security engineering manager at a fintech company
- Independent security writer and consultant, focused on DevSecOps and AppSec implementation
Get in Touch
If you have a question about something I’ve covered, found an error worth correcting, or want to talk about consulting work, I’m reachable through the contact page. I read everything that comes in.
“`