Independent offensive security
I test web applications, APIs and cloud infrastructure like an attacker would — then turn the evidence into fixes your engineers can ship.
Ways to work together
Scope and fee are agreed before testing begins. Every engagement ends with evidence, practical remediation and one retest window.
Can one user reach another user’s data or actions?
Manual testing across identity, authorisation, sessions and business logic — beyond the routes a scanner already knows.
Reproducible findings · coverage map · retest
What is online that your team no longer remembers owning?
A focused review of domains, infrastructure and exposed services, with ownership evidence separated from scanner noise.
Verified asset map · prioritised exposures
How far can one leaked build token travel?
Privilege paths across cloud identity, trust policies, CI/CD and network controls, paired with the change that breaks each path.
Privilege map · evidence · fix paths
Would your team see a real attack chain unfold?
Objective-led testing against an agreed target, built for teams that already have detection capability and want to exercise it.
Attack narrative · detection gaps · replay
How the work moves
The useful finding is rarely one isolated bug. It is the path between a forgotten asset, a weak identity decision and an authorisation check that never ran.
Assets and trust boundaries
Identity and state
Authorisation and logic
Weak signals into impact
Evidence without excess
Example chain
Three forgettable weaknesses. One production account takeover.
Forgotten host
Same trust boundary
Loose redirect
OAuth client
Token accepted
Production app
Each control can look low-risk on its own. The report explains the full path, demonstrates the impact safely and identifies the smallest change that breaks the chain.
The thing you keep
A finding is only useful when the right person understands it and the team knows exactly where to start. No scanner export. No mystery score with no decision behind it.
Finding / 03
Evidence confirmed
Access control
What happens
An authenticated user can request an object owned by another tenant by changing its identifier. The API verifies the session, but does not bind the object to the caller’s tenant.
Fix direction
Enforce tenant ownership in the data query, then add a negative authorisation test for every object route.
Before testing
Scope + written rules
During testing
Criticals shared at once
At test close
Draft + team walkthrough
After fixes
Retest + closure note
Operating boundaries
Good testing should create useful evidence, not operational surprises. The stop conditions and data boundaries are part of the scope, not fine print added later.
Start with the system
Send the system, the roles inside it, and the failure you care about most. That is enough to begin a useful scope.