QA Security Testing

Security tests your QA team runs on every release: authorisation, input handling and the abuse cases from planning, automated where possible.

Book a call →Walk the line

QA takes it over

Pick a step, or let it play. Every line is what someone in the room actually says.

Step 1Collect the cases

Abuse cases from threat models and requirements.

ATALAIAThese twelve abuse cases came out of the threat model.

QANobody gave us these before. We test the happy path.

Leaves the room12 abuse cases from design

Step 2Write them as tests

In your QA framework, owned by QA.

QACase 7: redeem with another user's offer ID. Expect a 403.

ATALAIAExactly. In the framework you use today, no new tool.

Leaves the roomAbuse cases in the QA suite

Step 3Automate the matrix

Every role against every endpoint that matters.

ATALAIAEvery role against every endpoint that matters.

QAViewer can edit offers. That's a fail.

DEVELOPERMissing role check on PATCH. Fixed, rerun it.

Leaves the roomMatrix: 5 roles × 5 endpoints

Step 4Gate the release

Failed security tests stop promotion like any other test.

DEV LEADSo a failed security test stops promotion?

QALike any other failed test. Green now: DEV to QA.

Leaves the roomSecurity tests gate DEV → QA

QA
ATALAIA
DEV LEAD
DEVELOPER

The authorisation matrix

Every role against every endpoint that matters, run on every release. Two cells failed on the first run.

Role	`GET /offers`	`POST /redeem`	`PATCH /offers/:id`	`GET /admin/users`	`DELETE /vouchers/:id`
Anonymous	✓allowed	✕denied	✕denied	✕denied	✕denied
User	✓allowed	✓allowed	✕denied	✕denied	✕denied
Viewer	✓allowed	✕denied	!allowed, should be denied	✕denied	✕denied
Partner admin	✓allowed	✕denied	✓allowed	✕denied	!allowed, should be denied
Support	✓allowed	✕denied	✕denied	✓allowed	✕denied

✓ allowed ✕ denied ! failed: allowed, should be denied

Why it matters

“Exactly. In the framework you use today, no new tool.”
ATALAIA · step 2, Write them as tests

Security testing that only happens once a year in a pentest misses every release in between. QA already tests every release, with the right tools for many of these checks.

What you get

A security test pack in your QA framework
Authorisation matrices tested automatically
DAST tuned for your staging environment
A hand-off from threat model to test case

Typical shape: Two to four weeks to build the pack, then maintained by QA.

Next on the line

Every station reports to the same tower. These are the neighbours.

Station 02 · DesignSecurity Requirements

Non-functional needs and abuse cases

See the station →Station 12 · Release & testPentest

Scoped, manual, retested

See the station →Station 10 · Release & testDeploy Approvals

Who unlocks prod, and with which roles

See the station →

Talk it through

A 30-minute call. No slides, no price list, and a next step either way.

Book a call →Walk every station