Audit & Assessment Service

Source Code Review

We read your application's source code and look for security weaknesses in it — missing permission checks, unsafe handling of user input, passwords left in the code, outdated libraries and flawed logic. Because we see the code rather than only the running application, we find things that testing from outside cannot reach, and every finding points at the exact file and line to change.

Progress 0% 0 of 0 answered 0 mandatory pending

Before you start

We read your source code and look for security weaknesses in it. This is different from testing a running application — we see the logic behind the screens, including code paths that are hard to reach from outside.
Please do not paste passwords, API keys or tokens into this form. Repository access is arranged separately through a secure channel.
Fields marked * are needed before we can begin. Anything you are unsure of can be settled on the scoping call — pick "Not sure" and move on.

1 Assessment Details

Mandatory

Organization name *

Who can we contact about the code? *

Ideally a developer or lead who can answer "is this intentional?" quickly. It saves a lot of time on both sides.

When would you like the review to start? *

What do you need? *

Full code review Specific parts only Scan + verification Re-review only

What does the application do, and which part matters most? *

If you only had budget to review one part properly, which part would you pick? That is what we want to know here.

How often should this be carried out? *

One time only Every major release Every quarter Annually

Please note: the estimate in section 7 covers one round of review. How often it repeats is agreed when the scope is finalised.

2 The Codebase

Decides the timeline

This section decides the estimate. Rough numbers are fine.

Numbers *

Scope

Applications or repositories to review

Developers working on it

Size

Approximate total lines of codeexcluding libraries you did not write

Guide

Small service or microserviceroughly5k – 20k lines

Mid-size web applicationroughly50k – 150k lines

Large platformroughly300k+ lines

An estimate is fine — your development team can get an exact figure from the repository in a minute. Do not count libraries and packages you did not write; those are checked separately as dependencies, and counting them would inflate the estimate for no benefit.

Which languages is it written in? * Affects the estimate

Each language needs different tools, so one extra language adds about a day. Tick "Something else" for anything not listed and name it below.

Which other languages?

Which frameworks or platforms does it use?

Frameworks decide which protections you get for free and which you have to write yourself. Knowing them tells us where to look hardest.

Which repositories are in scope? *

We only review what is listed here. Repository links and access details are shared separately, not in this form.

3 How the Application Is Used

Mandatory

The same weakness can be critical or harmless depending on who can reach it. This tells us how to rate what we find.

Is the application reachable from the internet? *

Yes No, internal only Partly

What kind of data does the application handle? *

This decides how serious a finding is, so an approximate answer is fine. Anything unusual can go in the notes below.

4 Standards and Report

Mandatory

Is there anything we must NOT review? *

How should the report be written? *

Findings with fixes Full checklist Not sure

Findings with fixes gives each issue with the file, the line and a suggested fix — what developers want. Full checklist is longer and suits an auditor.

Anything specific you want us to look at?

5 How We Review

Nothing here needs an answer — it is what you are buying.

How the assessment runs

Before reading anything in detail we work out how the application is put together and which parts handle logins, permissions, money and personal data. Static analysis tools then run across the whole codebase, along with checks on your libraries and a scan of the commit history for passwords and keys. Tools produce a great many results and most are wrong, so every one is checked against the code by hand — you get confirmed findings, not raw tool output. The important code is then read line by line. Each finding names the exact file and line, with a suggested fix.

What we look for

Places where data from a user reaches a database query or a system command unsafely. Login and permission code — particularly checks that were never written, which tools cannot detect. Passwords and keys left in the source or in the commit history, including ones deleted later, which stay in the history and usually still work. Outdated libraries with known vulnerabilities. Weak encryption. And business logic: steps that can be skipped, amounts that can be changed, processes that can be run twice.

What we will not do

We read code; we do not attack a running system. That makes this different from a penetration test, and the two work best together — a code review finds weaknesses that are unreachable from outside and names the exact line to change, while a penetration test shows what someone could actually do with your application once it is running. Your code is treated as confidential, held only for as long as the review needs it, restricted to the reviewers on your engagement, and securely deleted afterwards on request. We never reuse it or put it into any tool that would retain it.

6 How We Rate Findings

Severity	What it means
Critical	Code that would let an attacker run their own commands on your server, read the whole database, or log in as any user. Fix before the next release.
High	Code that would let an attacker take over an account, reach data belonging to someone else, or bypass a permission check.
Medium	A real weakness, but it needs certain conditions — a valid login, an unusual sequence of steps, or something else to go wrong first.
Low	Limited impact on its own, but worth fixing. Often something that makes a future mistake more likely.
Informational	Code quality or hardening advice with no direct security impact.

Severity considers whether the code is reachable from the internet, whether a login is needed first, how sensitive the data involved is, and what an attacker would gain. A weakness in code nobody can reach is rated lower than the same weakness on your login page. Every finding gives the file, the line and the code itself, so there is no guesswork about what to change. After the re-review each finding is marked Closed, Open, Partially Fixed, Risk Accepted or Not Retested.

7 Timeline Estimate

These fill in automatically from your answers in section 3. You can change them here if you need to.

Timeline inputs

Applications or repositories

Total lines of code

Languagescounted from section 3

People working on it at once

Re-reviews after fixes

Each application includes the time to set up the build and understand the architecture before reading anything. One language is included; each extra one needs a different toolchain. One re-review is included as standard.

Estimated duration 0 working days

Code review0

Reporting0

Re-review0

Subject to final scope review, code access and resource confirmation. The final timeline is confirmed after the complete scope has been reviewed and understood.

Save and Export Response

Your answers stay in this browser until you export or clear them.