Start a conversation

Practice 05 — Penetration Testing

Your browser was patched in hours. Your CI runner was not.

In October 2026 eight certificate authority private keys turned out to be integers below 256. Browsers blocked them the same day. Published testing found curl and Node connecting to the compromised chains without a word. That gap is where we look.

What sets the estimate
  • Asset type
  • Endpoints or screens
  • Authenticated roles
  • Environments
  • Retest window

Scoped on the call, quoted in days, in writing.

Scope a penetration test

A short call to understand your targets and timing, and to explain how we scope a test. Nothing begins before it is signed.

Times in

Loading available times…

Why teams call

You already suspect at least one of these.

  • You cannot list every trust store your builds depend on.
  • A provisioning script somewhere pipes a URL straight into a shell.
  • Your last test was scoped to the application and stopped at the login page.
  • Self-hosted runners have network reach nobody has questioned.
  • Developer machines install packages your lockfiles never see.
What you get

The deliverables.

Targets

  • Web applications and APIs, authenticated and multi-tenant
  • External perimeter and internal network
  • Cloud infrastructure, in depth — shared with practice 01
  • Build and release infrastructure, including runners and self-hosted agents

Supply chain and client trust

  • Trust-store inventory across containers, CI runners, language runtimes and vendored CA bundles
  • What your tooling verifies on egress: TLS, revocation, transparency — and what it checks nowhere
  • Dependency acquisition paths no lockfile covers: first install, npx, curl piped to a shell
  • Typosquat and rogue-package exposure, including packages aimed at AI coding assistants
How it runs

Rules of engagement

Targets, windows, escalation contacts and hard limits agreed in writing. Nothing is touched before that document is signed by someone entitled to sign it.

Test

Manual testing against the agreed scope, logged and attributable throughout, with anything genuinely dangerous flagged to you before it is pushed further.

Report and retest

Findings with reproduction steps, a register with named owners, and a retest of the fixes once your team has made them.

Questions

Before you
book the call.

How is this different from an automated scan?

Scanners find the findings that are easy to describe. The value here is chained issues and the trust assumptions nobody encoded — which is why the supply chain and client-trust work is a standing part of scope rather than an upsell.

What authorisation do you need?

Written authorisation from someone entitled to give it, naming the targets and the window. Where you do not own the infrastructure — a cloud provider, a SaaS platform — their rules apply too, and we will tell you what they require.

Will you take production down?

The rules of engagement set hard limits, and denial of service is excluded by default. Where a finding could only be proven by something disruptive, we describe it and ask rather than proving it.

Do you provide a report for our customers or auditors?

Yes. A findings register with reproduction detail for your engineers, and a summary suitable for sharing externally without handing a reader a working exploit.

How long does a test take?

Most engagements run three to six weeks including the retest, depending on scope. The scoping call exists to give you a real number rather than a range.

Next step

Scope a penetration test.

Thirty minutes, no obligation. We will tell you what is worth doing, including when the answer is less than you expected.

Choose a timehello@srdalabs.com