Pruebas de seguridad en QA

Pruebas de seguridad que tu equipo de QA ejecuta en cada release: autorización, gestión de entradas y los casos de abuso de la planificación, automatizadas cuando se pueda.

Reservar una llamada →Recorre la línea

QA se hace cargo

Elige un paso o déjalo correr. Cada línea es lo que alguien dice de verdad en la sala.

Paso 1Recoge los casos

Casos de abuso a partir de threat models y requisitos.

ATALAIAEstos doce casos de abuso salieron del threat model.

QANadie nos daba esto antes. Probamos el camino feliz.

Sale de la sala12 abuse cases desde el diseño

Paso 2Escríbelos como tests

En tu framework de QA, a cargo de QA.

QACaso 7: redeem con el ID de oferta de otro usuario. Se espera un 403.

ATALAIAExacto. En el framework que usáis hoy, sin herramientas nuevas.

Sale de la salaAbuse cases en la suite de QA

Paso 3Automatiza la matriz

Cada rol contra cada endpoint que importa.

ATALAIACada rol contra cada endpoint importante.

QAUn viewer puede editar ofertas. Eso es un fallo.

DESARROLLADORFalta la comprobación de rol en PATCH. Corregido, vuelve a lanzarlo.

Sale de la salaMatriz: 5 roles × 5 endpoints

Paso 4Pon un gate al release

Los tests de seguridad fallidos detienen la promoción como cualquier otro test.

DEV LEAD¿O sea que un test de seguridad fallido detiene la promoción?

QAComo cualquier otro test fallido. Ahora en verde: de DEV a QA.

Sale de la salaLos tests de seguridad son el gate de DEV → QA

QA
ATALAIA
DEV LEAD
DESARROLLADOR

La matriz de autorización

Cada rol contra cada endpoint que importa, en cada release. Dos celdas fallaron en la primera ejecución.

Rol	`GET /offers`	`POST /redeem`	`PATCH /offers/:id`	`GET /admin/users`	`DELETE /vouchers/:id`
Anónimo	✓permitido	✕denegado	✕denegado	✕denegado	✕denegado
Usuario	✓permitido	✓permitido	✕denegado	✕denegado	✕denegado
Viewer	✓permitido	✕denegado	!permitido, debería denegarse	✕denegado	✕denegado
Partner admin	✓permitido	✕denegado	✓permitido	✕denegado	!permitido, debería denegarse
Soporte	✓permitido	✕denegado	✕denegado	✓permitido	✕denegado

✓ permitido ✕ denegado ! fallo: permitido, debería estar denegado

Por qué importa

“Exacto. En el framework que usas hoy, sin herramienta nueva.”
ATALAIA · paso 2, Escríbelos como tests

Las pruebas de seguridad que solo se hacen una vez al año en un pentest se dejan fuera todas las releases intermedias. QA ya prueba cada release, con las herramientas adecuadas para muchas de estas comprobaciones.

Qué recibes

Un pack de tests de seguridad en tu framework de QA
Matrices de autorización probadas automáticamente
DAST ajustado a tu entorno de staging
Un traspaso del threat model al caso de prueba

Formato típico: De dos a cuatro semanas para montar el pack, y después lo mantiene QA.

Siguiente en la línea

Todas las estaciones informan a la misma torre. Estas son las vecinas.

Estación 02 · DiseñoRequisitos de seguridad

Necesidades no funcionales y casos de abuso

Ver la estación →Estación 12 · Release y pruebasPentest

Acotado, manual, retestado

Ver la estación →Estación 10 · Release y pruebasDeploy Approvals

Quién desbloquea prod y con qué roles

Ver la estación →

Habladlo

Una llamada de 30 minutos. Sin diapositivas, sin lista de precios y con un siguiente paso en cualquier caso.

Reservar una llamada →Recorre todas las estaciones