For technical leads, product owners and teams changing sensitive functionality, inheriting a codebase or investigating a known finding.
When you need root-cause analysis and a practical fix.
What we examine
- Define the modules, changes, dependencies and relevant data flows.
- Review trust boundaries, permissions and handling of untrusted input.
- Investigate findings in context and discuss fixes that fit the architecture.
A clear start. A useful finish.
Tell me the problem
Share the product, stack, goal and deadline. A short overview is enough to start the conversation.
Agree the engagement
Receive a written scope, deliverables, acceptance criteria, price and schedule before we begin.
Review the work as it develops
For assessments, examine the evidence and priorities. For engineering, review agreed implementation milestones.
Put the result to work
Get a technical walkthrough and useful handoff. Agree any further implementation or verification your team needs.
I investigate down to the cause.
Facebook and Instagram research, 300+ Linux kernel reports and findings investigated, eight patches and two published CVEs. I connect a suspicious behavior to the code, the conditions that trigger it and the impact on your product.
See the kernel findings and fixesQuestions before we begin
Which languages and stacks do you review?
I work with application code including C, C++ and Java, alongside a development background in PHP/Laravel, Vue, Node.js and MySQL. Share your stack and review goals so we can confirm the right scope.
Do you need the entire codebase?
Access depends on the question. A focused review may still need surrounding code, build information or tests to understand permissions, dependencies and data flow.
Can the review focus on a proposed fix?
Yes. We can examine whether an agreed change addresses the original cause and whether it introduces related issues. Implementation work is agreed separately where needed.
Can we begin with one component?
Yes. A bounded review of a critical feature, module or change can be a useful first engagement. The report states those boundaries explicitly.
Useful lessons from security research
- After React2Shell: three security boundaries every server component review needs
- CVE-2024-26855: when a missing attribute becomes a NULL dereference
- CVE-2025-37858: a 64-bit destination cannot fix a narrow shift