How I approach security
What seven years of product security taught me. Most of it I learned the slow way, and it holds whatever the stack or the company.
People, process and systems
Most of the security problems I have seen sat in the seams: a control nobody owned, a process nobody followed, a system nobody had mapped. The work I enjoy most is joining the three, so the secure path is also the easy one.
Fix the cause for the whole class
Every bug points at a gap upstream. I would rather close that gap once, with a pipeline gate, an IAM guardrail or an endpoint baseline, than fix the same bug in ten places. When a whole class of findings stops showing up, that is the win I look for.
The basics come first
Most incidents I have worked on started with something ordinary, like an admin account without MFA, a forgotten test server or a key in a repo. So I get the basics right before anything clever. Exploits now show up within hours of a disclosure, which moves the weight onto the controls that limit damage when something does get through.
Know what you have
- A current inventory of assets and exposure
- Real SBOMs for your code and dependencies
- Logs you can search
- Vendor and SaaS access reviewed
Shrink and harden it
- Unneeded features and services switched off
- Patching that keeps up
- A locked-down dependency chain
- Secure configuration by default
- Secrets out of code, and rotated
Contain it
- Least privilege and few admins
- Phishing-resistant MFA, starting with admins
- Segmentation and zero trust
- Egress filtering
- Critical data encrypted
Detect and recover
- EDR on every endpoint
- Canaries and honey tokens
- Containment approved in advance
- Backups you have restored
- Incident plans you have practiced
Know what is exposed, all the time
Teams ship, change and forget services faster than any spreadsheet can follow, and AI has made that faster still. I keep a live inventory of what faces the internet and test it on a schedule for known vulnerabilities, weak authentication and obvious mistakes. Anything public that is not on the list is a finding in its own right.
Developers are the customers
Security that slows engineers down gets routed around, and I don't blame them. I build paved roads with secure defaults and put policy where the work happens: guidance an engineer, or their coding agent, reads while designing, and hard checks in the pipeline that no prompt can talk its way past. I like small tools that each do one job and compose, the Unix way.
Speed is a security control
An attacker can try an idea in an afternoon. Inside most companies the same fix waits weeks for approvals and change windows. A lot of my work is shortening that path: fixes approved in advance for common cases, containment decided before the incident, and a way to get a new defensive tool through review in days.
Measure it
If I can't measure a control, I can't improve it or defend it in a budget meeting. I watch time to fix by severity, how much of the estate a control covers, how much gets caught before merge, and how many alerts are worth a human's time. Numbers turn security from a cost into a result leadership can see.
Influence without authority
Security is always short of people and money, and in a startup it is often an afterthought until the first bad day. Most of my work gets done through other teams, so I invest in those relationships early: engineering, IT, product, legal and finance. Good security makes yes the easy answer. IT counts too, because the laptop, the identity provider and the SaaS admin console are attack surface.
Logs, provenance and assurance
More code now comes from assistants and agents, and more systems act on their own. I want an agent's actions logged as carefully as a person's, and a clear record of who or what changed something, from where and with whose approval. That record is what lets a team move fast and still answer for it months later.
Depth and judgment stay with people
The further a topic is from what you know, the smarter an AI answer sounds. Knowing the system underneath, the protocol, the cloud account, the code path, is what lets me tell a good answer from a confident wrong one. Tools supply the facts. Which systems matter most, which risks we accept and until when, and what a finding really puts at stake are calls a person makes and stands behind, and anything I put a severity on is reproduced for real first. Describing what done looks like, in a threat model, a test scope or an acceptance line, has become the most valuable part of the job.
Where AI fits
AI turns security engineers back into builders. Work that used to wait for a free week now fits in an afternoon: a working proof of concept for a finding, a small tool for one engagement, a detection or a test drafted and tried the same day. It is a copilot during engagements, a sparring partner for an idea late at night, and the fastest way I know to find my way around an unfamiliar codebase. It reviews our own code before an attacker's model does, takes the first pass at an alert, and drafts the answers to a security questionnaire from our own policies and past answers.
It works when it reads deterministic tool output behind real safeguards, with a person signing off, and the real gain comes from redesigning the process around it.