Source code security review

Catch the flaws that only show up in the code.

Your code is read by hand, following data from where it enters the application to where it is used. Each finding comes with the file and line, how it could be exploited, and a fix your developers can apply.

Discuss my scope

What’s tested

Risk first: login, permissions and business logic, then the rest

What the source code review covers
Starting point	Read-only access to your repositories, or review on a machine you provide
You provide	Repository access, an architecture overview and a developer for questions
We test	Login and sessions authentication · JWT handling Permissions authorization · IDOR · tenant isolation Business logic race conditions · state handling Untrusted input SQL and command injection · path traversal · SSRF · deserialization Secrets and crypto hardcoded keys · weak algorithms Third-party code dependency review · reachability
The goal	Flaws where they’d hurt most, including the ones scanners miss
Based on	OWASP ASVS · CWE Top 25
You get	Critical findingsreported straight away Reportfile and line, how it could be exploited, the fix Readout and retesta call, then one retest of the fixed code

Languages: Java · C# · PHP · Python · Node.js

What a finding looks like

Each finding points to the file and line, explains how it could be exploited and shows the fix, along with the root cause, so the same bug doesn’t reappear elsewhere.

What every report contains →

High CODE-04

Password reset links can be calculated for any account

src/auth/reset.py:42

Impact: Anyone who knows a user’s email address can reset their password and take over the account.
Proof: The reset token is built from the user ID and the current time, so a valid link for any account can be computed from outside.
Fix: Generate the token with a secure random function such as secrets.token_urlsafe, store only its hash, and expire it after first use.

FAQ

What comes with every engagement?

Every review is led by an OSWE-certified reviewer and done by hand. During the review, a shared chat channel and a weekly call keep you up to date, and anything critical is reported straight away. After the report you get a readout call and one retest.
Does our code have to leave our systems?

No. You choose: read-only access to the repository, or the review is done on a machine or environment you provide. Any copy is deleted when the engagement ends.
Code review or penetration test?

A penetration test shows what can be exploited from outside. A code review sees every route, including the ones that are hard to reach from outside. For an application you build yourself, doing both and letting each inform the other covers the most ground.
Is the whole codebase read line by line?

Usually not, and deliberately so: the time goes to the code that handles login, permissions, money and customer data. The report says exactly what was and wasn’t reviewed.
How is this different from a SAST scanner?

A scanner flags patterns, many of them harmless, and misses flaws in logic and permissions. Here every finding is read, confirmed and explained by a person.
How much of our developers’ time does it take?

A short call at the start, answers to questions during the review, and the readout call at the end.
Will the report help with due diligence or a customer’s security review?

Yes. It states what was reviewed, every finding and the retest results, which is what investors’ and customers’ security teams ask to see.
Do you sign an NDA?

Yes, before any details are shared.
What language is the report in?

The report is in English.
Select a question

Get in touch

Tell us what you would like reviewed: the languages and frameworks, roughly how much code, and which parts worry you most.

What happens next

We reply within 24 hours
By email, with a link to book a call with the team.
Intro call
We learn what you need and answer your questions.
Proposal
Scope, timing and price, in writing. Nothing starts before an NDA is signed.

Prefer email? Write to hello@alteasecurity.com