Approach / The work behind the words
Understand deeply.
Explain clearly.
My aim is to help teams see the important failure paths, make a defensible decision, and know what to do next. The method should make that possible.
The starting point
Learn how it works.
Then ask how it fails.
A security problem sits inside a working system. There are users, permissions, financial incentives, release pressures, dependencies, and people who need to operate the result. I start by understanding those relationships. A technically correct observation is more useful when it explains whose assets or capabilities are affected and what has to be true for the failure to happen.
That understanding shapes the scope. Sometimes the right work is a technical review; sometimes it is an incident exercise, an architectural decision, or documentation that corrects a dangerous misunderstanding. The point is to choose an engagement that answers the question in front of the team.
Working principles
Judgment should be inspectable.
Context before a checklist.
Establish assets, roles, trust boundaries, and intended behavior. Checklists support coverage, but the system’s actual consequences determine where to go deeper.
Evidence before confidence.
Separate what was observed, what someone else reported, and what is inferred. Make prerequisites and uncertainty explicit. A compelling explanation still needs support.
Consequences before severity labels.
Explain the attack path, affected capability, and realistic impact. A severity rating should help a team decide what to fix, not substitute for that explanation.
Controls before promises.
Prefer a permission boundary, reproducible test, or recovery procedure over a claim that a system is inherently safe. State what a control covers and what it depends on.
Tools with accountability.
Use automation and AI where they help exploration, coverage, and communication. Validate their output. Untrusted material does not gain authority because a tool or model repeated it.
A next step with an owner.
Recommendations should connect to an implementable change, a decision, or a further investigation. Explain what would demonstrate completion and which uncertainty would remain.
An engagement in practice
Make the work legible.
Agree on the question.
Define the system, decision, review boundary, access model, exclusions, timeline, deliverables, and people responsible for technical and commercial approval. Resolve missing inputs before treating the scope as settled.
Follow consequential paths.
Read, test, compare, and ask questions. Keep a record of assumptions and evidence. Raise significant observations while the team can act, and discuss scope changes when the system or available information changes.
Leave a usable record.
Explain findings and tradeoffs in language the decision owner can use. Review agreed fixes or follow-up actions, record the tested version, and make limitations visible to anyone relying on the result later.
When perspectives differ
Disagree with reasons.
An engineer may dispute an impact estimate. A founder may accept a risk because another constraint is more urgent. A writer may find that a product claim is stronger than the evidence supports. These are useful conversations when the premises are explicit.
I aim to state the observation, the prerequisites, the possible consequence, and the reasoning behind the recommendation. If new evidence changes the conclusion, the conclusion should change. If the team accepts a risk, the decision and its owner should be recorded rather than disappearing into an unresolved comment.
Work outside the agreed competence or scope should be identified as such. Some questions need another specialist, additional testing, or legal advice. Saying what remains unknown is part of producing a dependable result.
Trust in the relationship
Confidentiality, independence, and clear claims.
Client source, architecture, customer information, and incident evidence need an agreed handling process. Before access is granted, establish permitted uses, transfer channels, retention, and publication approval. Private work does not automatically become a public case study.
Potential conflicts should be discussed before an engagement is accepted. Commercial interests should not determine which technical findings are reported or whether their impact is understated. An advisory relationship does not buy favorable independent research coverage.
Public writing follows the same standard: cite original material, distinguish facts from analysis, avoid unsupported attribution, and correct meaningful errors. Read the editorial policy for how the research library handles sources and corrections.
Start with your context
What would make this work useful?
Bring the architecture, the change, or the decision you need to make. We can determine the right question and a sensible scope together.
A good place to start
Bring the difficult
security question.
A launch, an architecture decision, a suspicious signal, or something that needs explaining. Let’s define the work it needs.