Testes de Segurança em QA

Testes de segurança que a sua equipa de QA corre em cada lançamento: autorização, tratamento de inputs e os casos de abuso do planeamento, automatizados sempre que possível.

Marcar uma chamada →Percorrer a linha

O QA assume

Escolha um passo, ou deixe correr. Cada fala é o que alguém na sala diz de facto.

Passo 1Reunir os casos

Casos de abuso dos threat models e dos requisitos.

ATALAIAEstes doze casos de abuso saíram do threat model.

QANunca ninguém nos deu isto. Testamos o caminho feliz.

Sai da sala12 casos de abuso do desenho

Passo 2Escrevê-los como testes

No seu framework de QA, geridos pelo QA.

QACaso 7: resgatar com o ID de oferta de outro utilizador. Esperado: 403.

ATALAIAExatamente. No framework que já usam, sem ferramenta nova.

Sai da salaCasos de abuso na suite de QA

Passo 3Automatizar a matriz

Cada função contra cada endpoint que importa.

ATALAIACada função contra cada endpoint que importa.

QAO Viewer consegue editar ofertas. Isso é uma falha.

PROGRAMADORFaltava a verificação de função no PATCH. Corrigido, corram de novo.

Sai da salaMatriz: 5 funções × 5 endpoints

Passo 4Travar o lançamento

Testes de segurança falhados travam a promoção como qualquer outro teste.

DEV LEADEntão um teste de segurança falhado trava a promoção?

QAComo qualquer outro teste falhado. Agora a verde: DEV para QA.

Sai da salaTestes de segurança travam DEV → QA

QA
ATALAIA
DEV LEAD
PROGRAMADOR

A matriz de autorização

Cada função contra cada endpoint que importa, em cada lançamento. Duas células falharam na primeira execução.

Função	`GET /offers`	`POST /redeem`	`PATCH /offers/:id`	`GET /admin/users`	`DELETE /vouchers/:id`
Anónimo	✓permitido	✕negado	✕negado	✕negado	✕negado
Utilizador	✓permitido	✓permitido	✕negado	✕negado	✕negado
Viewer	✓permitido	✕negado	!permitido, devia ser negado	✕negado	✕negado
Admin do parceiro	✓permitido	✕negado	✓permitido	✕negado	!permitido, devia ser negado
Suporte	✓permitido	✕negado	✕negado	✓permitido	✕negado

✓ permitido ✕ negado ! falhou: permitido, devia ser negado

Porque importa

“Exatamente. No framework que já usam, sem ferramenta nova.”
ATALAIA · passo 2, Escrevê-los como testes

Testes de segurança que só acontecem uma vez por ano num pentest falham todos os lançamentos pelo meio. O QA já testa cada lançamento, com as ferramentas certas para muitas destas verificações.

O que recebe

Um pacote de testes de segurança no seu framework de QA
Matrizes de autorização testadas automaticamente
DAST afinado para o seu ambiente de staging
Uma passagem do threat model para o caso de teste

Formato típico: duas a quatro semanas para construir o pacote, depois mantido pelo QA.

A seguir na linha

Todas as estações reportam à mesma torre. Estas são as vizinhas.

Estação 02 · DesignRequisitos de Segurança

Requisitos não funcionais e casos de abuso

Ver a estação →Estação 12 · Release e testePentest

Com âmbito, manual, retestado

Ver a estação →Estação 10 · Release e testesAprovações de Deploy

Quem desbloqueia prod, e com que papéis

Ver a estação →

Vamos conversar

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.

Marcar uma chamada →Percorra cada estação