Source code analysis

How we work

1. Understand

   Architecture, data flows and threat model. Together with you we identify the security-critical parts of the application and where an attacker would start.

2. Search

   Models and our own tools comb through the entire code base for patterns and variants of known bugs. This makes even large code bases reviewable in reasonable time.

   AI-assisted
3. Manual review

   We read security-critical paths by hand: authentication, permission checks, input handling, cryptography.

4. Verify

   Every finding is proven. Suspicious behaviour and bugs that cannot be exploited directly are marked as such in the report.

   AI-assisted

AI is a tool here, not a replacement. It sorts and suggests. Whether a vulnerability is real and what it means for you is decided by experienced people.

What we look at

A structured analysis is based on the OWASP Web Security Testing Guide (WSTG), the established standard for security testing of web applications. We work through its test areas, from configuration and authentication to authorisation, business logic and APIs, in the code rather than on the running system.

All risks of the OWASP Top 10 are covered:

• A01 Broken Access Control: missing or faulty permission checks, direct access to other users' objects (IDOR), path traversal, CSRF, SSRF

• A02 Security Misconfiguration: insecure defaults, debug modes, security headers and clickjacking, XML parsers (XXE)

• A03 Software Supply Chain Failures: dependencies with known vulnerabilities, the build and deployment pipeline

• A04 Cryptographic Failures: weak algorithms, key management, random numbers, sensitive data in plain text

• A05 Injection: SQL, code, commands, templates, HTTP headers, cross-site scripting

• A06 Insecure Design: threat model, business logic, missing safeguards

• A07 Authentication Failures: login, password storage, password reset, multi-factor, session management

• A08 Software or Data Integrity Failures: insecure deserialisation (unserialize), unverified updates and data

• A09 Security Logging and Alerting Failures: security-relevant events that are not logged, log injection, sensitive data in logs

• A10 Mishandling of Exceptional Conditions: error handling, stack traces and information leakage, checks that fail open instead of closed

To us, the WSTG and the Top 10 are a framework, not a checklist to tick off: the most important findings are made where an application has rules of its own.

Source code analysis and penetration testing

A source code analysis is always more thorough and more complete than a test from the outside. A penetration test only sees what can be reached through the surface of the running application, and only in the states that can be brought about within the time of the project. In the code, every path is open to view: rarely used features, error branches, hidden interfaces and code that only runs under certain conditions. Once we find a vulnerability, we also find every other place with the same flaw.

This is why we usually combine source code analysis with a penetration test. It confirms the findings on the running system, shows what an attacker can actually achieve, and uncovers problems that are not in the code, such as the configuration of servers and infrastructure.

Languages and platforms

Server side Java, PHP, Ruby, Perl, Python and more; client side JavaScript and browser APIs; mobile iOS and Android.

Result

At the end there is always a report. Either brief and to the point, so that as much time as possible goes into the actual analysis, or a detailed report with a description of every vulnerability, a risk assessment and concrete remediation advice. Follow-up questions included.