Web Security

I work against public, verifiable standards rather than a proprietary methodology. The references are the OWASP Web Security Testing Guide for conducting tests, the Application Security Verification Standard for application security requirements, and the OWASP Top 10 as the baseline for classifying risk categories.

The practical benefit is that the scope of what was verified can be stated and compared: you can see which checks were performed and which were not, instead of receiving an untraceable overall verdict.

Tests run in black box mode, with no prior information, grey box, with credentials and partial knowledge of the system, or white box, with access to the source code. The mode materially changes what can be found for the same time spent: black box reproduces the external attacker's viewpoint, white box finds considerably more but requires you to open the repository.

The scope covered includes web applications, REST and GraphQL APIs, mobile applications and internet-facing infrastructure.

For static code analysis I use SonarQube and Trivy, the latter also for scanning container images and dependencies. For secret scanning I use gitleaks, the most direct way to find credentials that ended up in repository history and were never really removed.

For dynamic analysis I use OWASP ZAP against the running application. Automated tools are the starting point, not the result: they cover known ground quickly and free up time for manual verification, which is where application logic flaws are found.

The deliverable is what clients decide on, so it is defined explicitly. You receive a non-technical executive summary, readable by whoever has to authorise remediation spending without knowing the implementation detail.

Alongside it comes the technical report, where every finding is accompanied by a reproducible proof of concept, a CWE classification and a CVSS score. A vulnerability that cannot be reproduced is not a demonstrated vulnerability, which is why PoCs are part of the report and not an optional annex.

Then comes a prioritised remediation plan, because the order in which things get fixed matters as much as the list itself. Finally, the retest after fixes is included: verifying that the correction actually closed the issue, and did not open another, is part of the work rather than a second engagement to buy.

On GDPR I handle the technical aspects exclusively: encryption, access control, data handling and retention, operation logging.

The documentation and legal side, from processing records to privacy notices, is not part of the service. The same principle applies: it is a legal competence and belongs with whoever practises it.