Source code audits
Reading the code like an attacker, before they do.
We review the source code of your applications for security flaws: with analysis tools, with help from artificial intelligence and, above all, with people who develop and maintain systems and confirm every finding before reporting it.
- PHP, Python, JS/TS, Java and C#
- Every finding confirmed by a person
- Code handled in the EU
For decision-makers
What a code audit is, in plain language.
A penetration test attacks the application from the outside. An audit reads it from the inside, line by line where it matters, and finds flaws that no external attack would reveal.
- It finds the cause, not just the symptom. Every finding gives the file, the line and the fix.
- It sees what is not exposed. Internal features, permissions and integrations are reviewed too.
- It happens before the problem. It can be done before the application goes live.
- It makes the team stronger. Findings explain the pattern to avoid, not just the case.
From the inside
We read the code, the dependencies and the configuration.
No false alarms
We only report what we have confirmed.
With a fix
Every flaw comes with the way to close it.
With a retest
We confirm that the fix solved the problem.
What we look for
The flaws that most often open the door.
We follow the OWASP Top 10 categories and check the OWASP ASVS requirements that suit each application.
-
Authentication and sessions
Passwords, account recovery, multi-factor authentication and session management.
-
Authorisation
Whether each user can only reach their own data and the functions meant for them.
-
Injection and validation
Outside data that reaches queries, commands or pages without validation.
-
Secrets in the code
Keys, passwords and access credentials left in the code or in its history.
-
Cryptography
Weak algorithms, poorly stored keys and sensitive data left unencrypted.
-
File uploads
Uploaded files that can be executed, overwrite others or exhaust resources.
-
Logging and errors
Errors that reveal internal information and important actions that go unrecorded.
-
Dependencies
Libraries and components with known flaws, as in the PHP2Shell case.
How we work
From tools to people, in six steps.
-
Preparation
Access to the repository, the architecture and the critical flows, agreed with your team.
-
Automated analysis
Static and dependency analysis, to cover all the code and find known flaws.
-
AI-assisted analysis
AI tools follow data from where it enters to sensitive operations and flag candidates.
-
Manual review
Authentication, permissions, payments and personal data reviewed by hand by people who know the patterns.
-
Confirmation
Every candidate is reproduced in a test environment; anything not confirmed stays out of the report.
-
Report and presentation
Findings by severity, with a proposed fix, presented to the technical team and to management.
Illustrative example
One finding, from problem to fix.
Every finding in the report explains what is wrong, where, why it matters and how to fix it. See what a full report looks like.
- A description of the problem, clear for those who code and those who decide.
- The exact location: file, line and affected feature.
- Evidence that the flaw exists, reproduced in a test environment.
- The impact on the service and the data, and severity measured with CVSS 4.0.
- A proposed fix, with the code before and after.
- The retest status, updated when the fix is applied.
// Finding A-03 · Severity: high
// File: orders/view.php, line 18
// Problem: the identifier comes from the request unvalidated
// and nobody checks who owns the record.
$sql = "SELECT * FROM orders WHERE id = " . $_GET['id'];
$order = $db->query($sql)->fetch();
// Fix: a parameterised query and an ownership check.
$stmt = $db->prepare(
'SELECT * FROM orders WHERE id = ? AND customer_id = ?'
);
$stmt->execute([$_GET['id'], $user->id]);
$order = $stmt->fetch();Languages and tools
The technologies we work with every day.
We audit the languages and frameworks we also use to develop and maintain systems.
- PHP, including Laravel, Symfony and WordPress.
- Python, including Django, Flask and FastAPI.
- JavaScript and TypeScript, on the server with Node.js and in web applications.
- Java, including Spring.
- C#, including .NET.
Semgrep
Static analysis of the code, with public rules and our own.
OWASP Dependency-Check
Dependencies with known, published vulnerabilities.
Trivy
Dependencies, containers and configuration files.
AI with human review
Suspicious data paths, always confirmed by a person.
When it makes sense
The right moments for an audit.
-
Before going live
Fixing a flaw before launch costs far less than after it has been exploited.
-
When taking over a system
Before taking on the maintenance of an application built by another supplier.
-
After a major change
A new integration, a new module or a change of framework.
-
In the supply chain
To assess the security of suppliers' software, as NIS2 requires.
What you receive
A report that is useful to those who decide and those who fix.
The audit only ends when the important flaws are closed.
- An executive summary for management, with the level of risk and the priorities.
- A technical report with every finding, its evidence and the proposed fix.
- A presentation meeting with your technical team or your supplier.
- Fixes made by us or by your team, as you prefer.
- A retest and final report with the status of every finding.
Frequently asked questions
About source code audits.
Do you need access to all the code?
We need access to the code of the application being audited and its configuration, ideally to the repository with its history. The history helps find secrets that were deleted from the code but are still stored.
Does our code leave our premises?
Only if you agree. The code is handled in the European Union, through our partners, or on your premises, deleted at the end of the work and never used to train AI models.
How long does an audit take?
It depends on the size and complexity of the application. A medium-sized application usually takes two to three weeks, from access to the code to the report.
Do you audit code built by another supplier?
Yes, with the system owner's authorisation. We can present the findings to the supplier and support them with the fixes, or make the fixes ourselves when the contract and the licence allow it.
Does an audit replace a penetration test?
No, they complement each other. The audit finds flaws in the code; the penetration test confirms what an attacker can exploit in the running application, including the server configuration.
Want to know what your code is hiding?
Tell us which application you want audited and we will propose a fixed scope and price.