Source Code Review (SCR)

A source code review is a security examination of the code behind an application, done at a set point in time. Automated tools scan the whole codebase, then our reviewers check every result and read the riskiest parts line by line. You find out which security flaws are built into the software itself, before customers or attackers find them in the live system.

Why look at the code at all?

Testing a running application, as a penetration test does, shows what an attacker can reach from the outside. Reading the code shows why a weakness exists and where else the same mistake has been repeated. Some problems, such as a password written directly into the code or a hidden shortcut left by a developer, are close to impossible to spot from outside. The two approaches complement each other.

When organizations commission a review

  • Before releasing a new or heavily changed application.
  • When a regulator or customer asks for a code-level security assessment, which is common in banking, fintech and government.
  • When buying or taking over software built by someone else, including due diligence in a merger or acquisition.

If you would rather have code review as an ongoing part of development, see our secure code review for development teams.

The review, step by step

We agree the scope first: languages, frameworks, the modules that matter most (login, payments, personal data), and access to the correct version of the code and its design documents.

Automated tools then scan everything. Static analysis (SAST) looks for insecure coding patterns. Software composition analysis (SCA) lists the open-source libraries in use and flags any with known weaknesses.

Raw tool output contains many false alarms. Our reviewers check every automated finding and confirm whether it can really be exploited in your context. They then read the high-risk modules by hand, concentrating on login, access control, input handling, encryption and business logic, which is where tools are weakest.

Each confirmed issue is written up with the file and line number, a description, a severity rating and a recommended fix. Once your developers have made their changes, we review the fixes.

Problems we commonly find

  • Unchecked user input that leads to SQL injection, cross-site scripting (XSS), buffer overflows and other injection flaws.
  • Weak login logic, passwords stored unsafely, or missing permission checks.
  • Session handling that lets an attacker take over or fix a user’s session.
  • Outdated encryption, keys written into the code, or encryption applied incorrectly.
  • Error messages that leak sensitive data, or missing logs that an incident investigation would need.
  • Memory errors such as leaks, dangling pointers and buffer overflows in languages like C and C++.
  • Race conditions in code that runs several tasks at the same time.
  • Logic errors that can be abused, such as a way to skip a payment step.
  • Third-party libraries with known weaknesses.

What you receive

  • An executive summary of code-level risk for management.
  • A technical report with confirmed findings, code references, CVSS scores and fix guidance.
  • A dependency report listing vulnerable third-party components.
  • A follow-up review confirming the fixes.

Reviews tend to surface general quality problems as well, and developers learn a lot from concrete examples in their own code. Many standards and regulations require or recommend secure code review, so the report doubles as compliance evidence.

For the technical team: findings are assessed against OWASP ASVS, the OWASP Top 10, the CWE Top 25 (a list of the most dangerous types of software weakness) and the SEI CERT Secure Coding Standards. We follow the OWASP Code Review Guide and rate severity with CVSS.

Request a source code review proposal to scope your codebase.