White box
A pentest tests your application from the outside, as an attacker would. A code audit looks at it from the inside, with the code in front of it, and that is where what cannot be seen from the outside appears: a credential hidden between the lines, a missing validation, a logic branch that almost no one ever runs. We read your code to find the flaws at their source, combining the sweep of a tool with the judgement of someone who knows how to read between the lines.
Static analysis, without running your application or touching production. Across Spain.
Why
Attacking an application from the outside only uncovers what the attacker can reach. Reading the code sees everything, even the paths that almost never run, and gets to the root of the problem.
An external attack only walks what it finds. The audit follows every flow in the code, including the ones that rarely run.
It does not stop at the symptom: it points to the exact line and the reason for the flaw, to fix it properly and not with a patch.
The analysis is static: the code is read, not run. Zero impact on your environments and your real data.
Secrets written into the code, broken business logic, insecure dead code. Things that are invisible from the outside.
What we find
We look for both the classic security flaws and the bad development practices that, sooner or later, end up as a hole. These are the fronts where they appear most.
Passwords, API keys and tokens written directly into the code, one of the most common and most avoidable leaks.
Inputs that reach a query or a command unfiltered, the root of SQL injection and of many other problems.
Permission and authentication checks done badly, which let a user get where they should not.
Obsolete algorithms, poorly managed keys or encryption applied where it does not belong, giving a false sense of security.
Third party libraries with known flaws, the software supply chain flank, through composition analysis.
Errors in how your application works that no tool detects, because they only show up by understanding what it should do.
How
Neither machine alone nor hands alone. The two layers need each other: one covers the ground, the other gives it meaning.
With static analysis (SAST) we sweep through all your code quickly, without leaving a corner, and with composition analysis we review your dependencies for vulnerable versions. That is the breadth: covering all the ground in little time.
Then an expert reviews the findings by hand: discarding the false positives that every tool produces, confirming what really matters and understanding your business logic to find what no machine sees alone. That is the depth.
What you take away
Not a dump of warnings from a tool, but confirmed findings, prioritized and with the fix alongside.
Each problem with the exact line, the reason and its severity, already filtered of false positives.
The credentials and keys that live in the code, to get them out of there and change them as soon as possible.
The third party libraries with known flaws and which version it is best to move up to.
Alongside each finding, how to correct it, so your team does not have to investigate from scratch.
The findings ordered by risk, so you start with what can really cost you dearly.
The proof that you review the security of your software, useful for the CRA and for your certification.
When
A flaw costs little to fix when it has just been written, and a lot when it is already in production. That is why a code audit pays off more the earlier it comes in.
Reviewing the code before launch avoids going live with a hole that is then much more expensive to close.
Every big change can introduce a new flaw. Reviewing what changes keeps the bar high without redoing everything.
Within a DevSecOps approach, the analysis enters your continuous integration and reviews the code on every change, with immediate feedback.
When the Cyber Resilience Act or a standard asks you for secure development, this is the evidence that you really do it.
Fits with
The code audit is half the picture of your software security, the inside half. The other half is provided by application pentesting, which attacks the application once it is running: white box and black box together cover everything from the code to its real behaviour. It is also a key piece of the secure development required by the Cyber Resilience Act, and what it finds can feed into the continuous monitoring of Sondriva, our SOC, once your application is already in production.
Questions
It means reviewing your application code from the inside, looking for security flaws at their source instead of testing the application once it is running. Reading the code reveals things that are invisible from the outside: a hidden credential, poor validation, a code path that almost never runs. This is what is known as a white box audit.
In the point of view. A pentest attacks the application from the outside, like an attacker, without seeing the code: that is black box. A code audit looks from the inside, with the code in front of it: that is white box. The pentest tells you what can be exploited; the audit tells you why and where the cause lies. They are complementary, and together they cover everything from the code to its execution.
We use static analysis (SAST) to sweep through all the code quickly and miss nothing, but we do not stop there. A tool flags many false positives and does not understand your business logic. That is why an expert reviews the findings by hand: discarding the noise, confirming what really matters and finding what no tool sees on its own.
Secrets and credentials written into the code itself, injection flaws and poor input validation, errors in access control and authentication, misused cryptography, third party dependencies with known vulnerabilities and business logic flaws. And, above all, the root cause of each one, so it gets fixed properly.
Yes, we need the code, and that is why we handle it with the utmost confidentiality and under agreement. The reassuring part is that the analysis is static: we read the code, we do not run it, so there is no impact on your production environments or your real data.
Yes. Today much of any application is third party code, and that is where software composition analysis comes in: we review your dependencies and libraries for versions with known vulnerabilities. This is where a significant part of software supply chain problems slip through.
Yes, and it is the most cost effective way to do it. Integrating the analysis into your continuous integration pipeline, within a DevSecOps approach, lets you review the code on every important change and give the team feedback as soon as possible. It is cheaper to fix a flaw as soon as it is written than to discover it in production.
We work with the most common languages and frameworks in web, API and mobile applications, and we adapt the tools to your specific stack. Tell us what your software is built on and we confirm the scope before we start, with no surprises.
It helps with both. The Cyber Resilience Act requires products with digital elements to be developed securely, and ISO 27001 includes secure development controls. A code audit is the evidence that you review the security of your software and that you act on what comes up, not just that you say so.
Shall we talk?
Tell us what your software is built on and what you want to secure, and we will propose how to audit your code and make it safer from the inside.
Get in touch