02 / 03
Penetration testing
This covers both traditional formats: if you can share your source, we review it; if you cannot, we work with your architecture documentation and test accounts and get further with far less friction. Either way the method is the same. Scanners, ours and yours, produce the raw inventory. We validate what is actually reachable, chain what chains, and discard what cannot be reproduced, so the report your engineers receive is short enough to be finished.
Two engagement formats
Grey Box and White Box, in the same engagement
Grey Box
The default when source code cannot leave your infrastructure. We work from your architecture documentation, your API specifications and your test accounts, and reach the same class of findings with far less setup friction.
You provide: architecture documentation, API specs, test accounts, and network access to the target.
White Box
When you can share source code. Reviewing the code raises coverage on business logic and trust boundaries, which no amount of black-box testing will reach.
You provide: the same, plus repository access under a mutual NDA.
When this engagement applies
This is for you if
- You need independent evidence before a release, an audit, a tender or an acquisition
- You have findings from your scanners and no reliable sense of which ones matter
- You need a third-party report your customers, insurer or auditor will accept
- You want privilege escalation paths tested alongside the application layer
What is out of scope
- Continuous detection and pipeline gates, which are what our CI/CD and AppGuard work is for
- Implementing the Active Directory or Kubernetes hardening, which belong to those services
- Denial of service, load testing and destructive testing
- Social engineering, which belongs to the red team service
Work and deliverables
What is in scope
- Web, API and external infrastructure attack surface
- Source review where you can share it, authenticated testing where you cannot
- Privilege escalation paths, including Active Directory and cloud IAM
- Cloud and Kubernetes configuration review
- Validation and exploitation of automated findings to separate real exposure from noise
- Business logic abuse and authorisation testing, using the documented architecture as the map
Deliverables
- A written report with an executive summary and a technical section
- Each finding with evidence, reproduction steps, impact and a concrete fix
- Severity rated with CVSS and prioritised with EPSS and business context
- Coverage mapped to OWASP WSTG, OWASP ASVS and MITRE ATT&CK
- A read-out call with the engineering and security teams
- One retest of the fixes, included in the engagement
How we run it
- 01
Scope and reconnaissance
We agree the perimeter, the access we get, the rules and the stop conditions, then map the exposed surface before testing starts.
- 02
Automated sweep
Your scanners and ours run first, to build the complete raw inventory of what is out there without us spending the budget on discovery.
- 03
Validation and exploitation
Findings are verified and chained into real attack paths. What cannot be reproduced does not ship, and what is only theoretical is labelled as such.
- 04
Report and retest
A short report, a read-out with engineering, and a retest of the fixes once they land.
Standards and references
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard
- OWASP API Security Top 10
- PTES
- MITRE ATT&CK
- CVSS v4.0 and EPSS