How a security sprint works

Most security testing is sold as an event: a scan runs, a report lands, a box gets ticked. We run it as a loop instead, because the report is the least valuable part. This is how a SealSec security sprint actually works, and why it is shaped the way it is.

1. Inventory

Before we attack anything, we map what exists. Not just the main web app, but the API, the mobile clients, the cloud accounts, the identity provider, the forgotten staging box with a public IP. Attackers do not respect your architecture diagram; they find the thing you forgot. So the first job is to make sure the scope matches reality, and to name the high-value targets explicitly, usually tenant isolation and authentication.

2. Test

This is manual work, guided by a methodology like the OWASP Web Security Testing Guide but driven by judgment. Scanners are good at the known and the mechanical; they are useless at the interesting bugs, the authorization check that is missing on one endpoint, the object ID that is trusted without verifying ownership, the workflow that can be run out of order. We spend our time where a real attacker would: logged in, as one tenant, trying to reach another.

3. Triage

A raw list of findings is not useful. We rank by real-world impact on your specific product, not by scanner severity. A "medium" that exposes another customer's data outranks a "high" that requires physical access to a machine nobody can reach. Every finding comes with enough reproduction detail that your engineers can fix it without a second meeting.

4. Verify

Here is the part most testing skips. When you have fixed something, we retest it. A finding is closed when someone has confirmed the fix works, not when a ticket moves to "done." This is also where regressions get caught, and as our regreSSHion advisory argues, a fix that is not tested is a fix that can quietly come undone.

Why a loop, not a line

The four steps feed back into each other. What we learn in testing sharpens the next inventory. What we verify becomes a regression test. The goal is not a certificate to show procurement, though a recent test does answer a lot of a security questionnaire. The goal is that your product gets measurably harder to attack, and stays that way.

If that is the kind of testing you want, a discovery call is where we start: we scope it together before anyone touches a keyboard.