CitaTechCitaTech

Security & resilience

For teams who would rather find it before someone else does

The problem

Most systems have never been pushed hard on purpose. They work at today's traffic, and nobody knows what happens at ten times that, or what happens when the database is slow, or whether the rate limiter anyone configured actually returns a 429.

The answers usually arrive at the worst possible moment, in production, during the busiest hour of the month.

How we approach it

  1. 01

    We establish where the system actually breaks, with load and stress runs against an environment you control, so capacity is a measured number rather than a guess.

  2. 02

    We check that the protections you believe are configured are configured. Rate limits that trigger, headers that are set, defaults that are not still defaults. This is unglamorous and it is where most of the real findings are.

  3. 03

    We test the application layer for the classes of bug that matter in systems handling money: broken access controls, injection, cross-site issues and mass assignment.

  4. 04

    Then we break dependencies on purpose and watch what happens. Degrading gracefully and recovering cleanly is a feature, and it is one you only find out about by trying.

What you get

  • A capacity report with the numbers at which things degrade
  • Findings ranked by exploitability and blast radius, not by severity label alone
  • Verification that your protections trigger, with the evidence
  • Reproducible test scripts you keep and can re-run after changes
  • A retest after you have fixed things, to confirm the fix

Engagement

Shape
A scoped assessment of systems you own or are authorised to test, with written authorisation agreed first
Duration
Typically 2 to 5 weeks including a retest

Every engagement is scoped and priced after we understand what you need. We will tell you if the work is smaller than you think.

Where we have done this

The suite we built for our own platform

We maintain a defensive resilience suite we run against our own payment infrastructure: capacity and stress runs, rate-limit verification, dependency-failure tests and application-level checks for access control, injection and related classes. We built it because we needed it, and we run it on the systems we are on call for.

Tell us what you are trying to build

If we are the wrong people for it, we will say so and point you somewhere better.

What else we do