Services / 05

Code & architecture review

“We need a second pair of eyes.”

I read your source code for flaws an attacker could use, and review your design for weak security controls. You get findings that point at the exact file and line, with suggested fixes, and a threat model your team can keep using.

Secure code review · Threat modeling · Architecture review

Who it’s for

  • Before a release A critical feature is about to ship: authentication, payments, permissions. I review it before customers use it.
  • Alongside a pentest The white-box case. I test the running application with the source code in hand, so I can follow a finding from the request to the line that causes it.
  • Before an acquisition or an investment Due diligence on the code and the design of a product you’re about to buy or fund.
  • Consultancies I take code review as a subcontractor and can deliver under your brand.

What I test

I review code in Java/Kotlin, C#/.NET, Python, PHP, JavaScript/TypeScript, Go, Rust, C and C++.

  • Authentication and access control Who can log in, who can see or change what, and where the code lets someone go further than intended.
  • Injection and unsafe deserialization Where untrusted input reaches a query, a command, an interpreter or a deserializer.
  • Memory corruption In the languages where it applies.
  • Design of the security controls I review the architecture for weaknesses in the controls meant to protect it.
  • Threat modeling A workshop with your team to map data flows and trust boundaries, using STRIDE and attack trees.

The review is manual and threat-led. I start from what an attacker wants and follow the data through the code. Static analysis (Semgrep, CodeQL) supports the reading, and I triage its results by hand.

References: OWASP ASVS · CWE Top 25 · OWASP Code Review Guide

How it runs

  1. Scoping & authorization

    What’s in scope: the whole repository or the parts that matter, the features, the languages. Dates and limits too, and whether AI tools may be used on your code. You can refuse. Signed rules of engagement before I start, and a quote after scoping.

  2. Testing

    I read the code by hand, starting from the threat model. When the threat modeling workshop is part of the scope, I run it with your team. Critical findings reach you as soon as I find them.

  3. Report & debrief

    Each finding with its file and line, its impact and a suggested fix, ranked by risk. Then a call with your team.

  4. Retest

    Once the fixes ship, I check them and update the report.

What you get

  • Findings tied to the code Each one points at the exact file and line.
  • Suggested fixes in code Patches or snippets, so your developers can see what I mean.
  • A threat model A document your team keeps and updates.
  • Design recommendations Ranked by risk.
  • A debrief and a retest A call with your team, then an updated report once the fixes ship. The report is in French or English, as you prefer.

No public case study for this service yet. See selected work.

Questions

Code review or pentest?

A pentest attacks the running application. A code review reads the source and the design. They find different things. They also work together: that’s the white-box case, where I test the application with the code in hand. If you’re not sure which one you need, tell me what you’re about to release and we decide at scoping.

How is our code protected?

Your code and the evidence stay encrypted during the engagement and are deleted 90 days after the final report. Some of my work is AI-assisted. I use local models by default, and cloud models only with your written agreement. Whether AI tools may be used on your code is agreed at scoping, and you can refuse.

Do you fix the code?

I suggest fixes in code, as patches or snippets in the report. Implementing them is up to your team.

Whole repository or only a part?

Either. We agree the scope at the start: the whole repository, or only the parts that matter, such as authentication or payments. I send a quote after scoping.

Talk about your project

I reply within two working days. Tell me which application or feature, the main languages, and whether this is before a release, alongside a pentest or for due diligence. I work remotely by default, and on-site anywhere in France when needed.