Penetration testing

The bugs a scanner walks past.

Business logic flaws, broken access control, and the chained issues that only appear when someone follows the thread. Every engagement is manual, depth-first testing by our testers, with each finding reproduced before it reaches you, rated in the context of your business, and written so a developer can fix it without a follow-up call.

Our testers hold OSCP, CREST Registered Tester (CRT) and CISM certifications.

What gets tested

Web applications: Manual, depth-first testing. Authentication and session flaws, access control and business logic issues, injection and data exposure. Business logic is where scanners stop and this work starts.
APIs: REST and GraphQL tested against broken object level authorisation, mass assignment, rate limiting and token handling weaknesses.
Networks and infrastructure: Internal and external testing across on-premise and hosted environments: exposed services, patching gaps, weak configuration and lateral movement paths.
Cloud: Cloud native applications and infrastructure covering misconfiguration, IAM weakness, storage exposure, serverless and container security across AWS, Azure or GCP.
Ad hoc VAPT: Short, scoped vulnerability assessment and penetration testing for a single release, a new integration or a supplier requirement, without the paperwork of a full engagement.
Red team exercises: Adversary simulation that tests detection and response as well as the technology, replicating realistic attack chains to find gaps in defensive posture. Scoped per engagement.

How an engagement runs

01Scoping call.What matters, what is in scope, what must not be touched. Output is a written scope, rules of engagement and a fixed price.
02Authorisation.Written authorisation from you, plus any third-party authorisation your hosting provider requires.
03Testing window.Agreed in advance. Anything critical or high reaches you the same working day rather than waiting for the report.
04Report.Every finding reproduced, rated with justification, impact in business terms, fix guidance a developer can act on.
05Debrief.A working session with your engineers, not a slide deck. Questions answered while the detail is fresh.
06Retest.We come back and confirm the fixes worked. Included, not an upsell.

What you receive

A findings report. An executive summary a non-technical reader can act on. A prioritised remediation roadmap. A debrief session. A retest of the fixes.

Who this is for

Teams shipping software who need testing that goes past a scanner. Companies facing a customer security questionnaire, an audit, or a supplier requirement. Organisations in regulated sectors who need findings written in language their board and their auditors both understand.

Testing and triage together

If you also run a bug bounty or disclosure programme, the two fit together: testing finds what the programme has not, and triage keeps the programme producing useful findings between tests.

Managed bug bounty triage

Questions

Who actually does the testing?

Our own testers, working to one scoping, reporting and retest standard. You keep a single point of contact at Secure Threads from the scoping call through to the retest, so nobody new appears halfway through and you are never handed to a third party.

How long does an engagement take, and what does it cost?

Both depend on scope: how many applications, whether testing is authenticated, the size of the network range, and whether a retest is needed. Scope and price are agreed at the scoping call before anything is booked, and the price does not change afterwards unless you change the scope.

What do we get at the end?

A report with every finding reproduced, rated and written up: severity with justification, reproduction steps, business impact and fix guidance a developer can act on. A debrief with your engineering team. A prioritised remediation roadmap. A retest of the fixes.

What happens if you find something critical mid-test?

You hear about it the same working day, not in the report three weeks later. Testing pauses if a finding puts live data or availability at risk, and we agree how to proceed before continuing.

Do you test production or a staging environment?

Either, agreed at scoping. Production testing runs inside an agreed window with rules of engagement in writing, and destructive testing is excluded unless you specifically ask for it in scope.

What do you need from us before testing starts?

Written authorisation, scope and rules of engagement, environment and credentials where the test is authenticated, a named technical contact, and any third-party authorisation your hosting provider requires.