Hardening from within
A blackbox pentest shows you what an attacker can find from the outside. A whitebox analysis shows you what they’d find if they already had access to the code — and that’s usually a lot more.
Having access to the source code during a security review changes what I can find. I can trace data flows end-to-end, understand the architecture as designed (not just as observed from the outside), and spot issues that no amount of external probing would uncover.
The engagement starts with a kickoff workshop (remote or on-site) with your development team. I’ll walk through a detailed question list — shaped by my experience as both a developer and pentester — covering the security-relevant aspects of your architecture. This conversation often surfaces concerns that the team already had but didn’t know how to prioritize.
From there, the source code and configuration go through a semi-automated and manual analysis covering:
- Vulnerabilities in software architecture
- Vulnerabilities in critical business functions, like payment etc.
- Vulnerabilities in used components and dependencies
- Vulnerabilities in exposed and consumed communication interfaces
- Vulnerabilities in authentication and authorization
- Vulnerabilities in configuration management
- Vulnerabilities in session or token management
- Vulnerabilities in encryption and digital trust handling
- Vulnerabilities in logging and monitoring capabilities
- Vulnerabilities in error handling
- Vulnerabilities in transfer and storage of sensitive data
The advantage of whitebox over blackbox becomes especially clear in areas like authentication logic, encryption implementation, and error handling — where the actual code behavior can differ significantly from what the API surface suggests.
For data-flow relevant vulnerabilities, I perform a source-to-sink analysis — tracing user-controlled input through the code to where it gets used (the “sink”). This keeps false positives in the final report to a minimum, so you’re not spending your time dismissing noise.
Detailed reporting
The resulting report of the found security issues includes detailed descriptions of the findings (along with all evidence collected) and mitigation advice to remediate each issue and tips to further harden your application. To better distribute the individual findings towards the relevant parties, I categorize all findings by function (business, architecture, development, operations) to which the finding applies.
After sending the report, an on-site or remote debriefing meeting will be arranged to further discuss the report and any potential questions along with the team members assigned to remediate the findings.
This process can optionally be followed by a second check of remediated findings, which leads to an updated report.
Prerequisites
All checks and tests can be executed remotely as well as on-site at your office location. As prerequisites, the following input is required to start the whitebox analysis:
- Build-ready sourcecode including dependencies and build scripts
- Configuration settings of a production-like environment regarding the application
- When containerization is used: Images as well as their creation declarations (Dockerfile or similar)