For desktop software, library, SDK and developer-tool vendors working with C, C++ or Java and components that handle untrusted input.
When introducing a parser, protocol, library or important native component.
What we examine
- Define target components, operating environment, build requirements and trust boundaries.
- Examine relevant code, input processing and application behavior.
- Use code review, dynamic testing or targeted fuzzing as agreed for the target.
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
What kinds of desktop projects are relevant?
Applications, libraries and components with clear security questions, especially around untrusted input. Share the language, operating system and build requirements so we can confirm fit.
Is fuzzing part of the assessment?
It can be included when suitable for the target. We agree the feasibility work, campaign and artifacts separately rather than assuming every application needs the same approach.
What public work supports this offer?
My public work includes CVE-2024-26855 and CVE-2025-37858 in the Linux kernel, with fixes accepted upstream. Those records show specific native-code investigation and remediation work.
Useful lessons from security research
- After React2Shell: three security boundaries every server component review needs
- The 2026 Axios attack: why a clean dependency tree cannot clear a build runner
- CVE-2024-26855: when a missing attribute becomes a NULL dereference